Panduan / Keamanan informasi

Apa yang dilakukan saat sertifikat TLS kedaluwarsa?

Sertifikat kedaluwarsa dapat menghentikan koneksi yang memvalidasi TLS. Pulihkan sertifikat pada titik layanan yang benar, pertahankan validasi, lalu cari penyebab pembaruan tidak selesai.

Di halaman ini

Pastikan penyebabnya sebelum mengganti konfigurasi

Baca sertifikat yang benar-benar diterima client, lalu perbaiki titik TLS yang gagal. Pesan “koneksi tidak aman” belum tentu disebabkan kedaluwarsa. Nama yang salah, chain tidak lengkap, CA yang tidak dipercaya atau waktu perangkat keliru dapat memberi gejala serupa.

Catat layanan/hostname, port, waktu UTC, client, pesan error dan titik koneksi yang terpengaruh. Periksa apakah kegagalan terjadi pada edge/CDN, origin, API internal atau pihak integrasi. Jangan mengubah jam sistem supaya sertifikat lama diterima; verifikasi sinkronisasi waktu melalui pengelola sistem.

Batasi gangguan sambil menjaga validasi

Tetapkan pemilik pemulihan dan beri informasi gangguan pada pengguna yang terdampak. Bila tersedia jalur pemulihan yang sudah disetujui dan memiliki sertifikat sah, gunakan sesuai prosedur. Jika tidak, hentikan sementara fitur yang gagal secara jelas sambil memulihkannya.

Menonaktifkan validasi sertifikat, menerima semua hostname atau mengalihkan data sensitif ke HTTP bukan langkah pemulihan. Jangan meminta pengguna mengabaikan peringatan browser sebagai cara normal melanjutkan transaksi.

Kedaluwarsa sendiri tidak membuktikan data dicuri atau kunci bocor. Jika ada indikasi penyusupan, tangani sebagai pekerjaan insiden terpisah melalui triase dan respons; penggantian sertifikat saja tidak menyelesaikan kompromi kunci.

Terbitkan, pasang, lalu muat sertifikat yang benar

Periksa akses pemilik domain, CA/profil yang dipakai, proses pembaruan serta kegagalan validasi domain atau deployment. Gunakan jalur penerbitan yang sah untuk lingkungan tersebut. Sertifikat internal tidak otomatis dipercaya oleh client publik, dan sertifikat origin belum tentu sesuai untuk koneksi langsung browser.

Periksa kesesuaian kunci dan sertifikat, identitas SAN serta kebutuhan chain sebelum pemasangan. Lindungi private key selama pemindahan. Jika kunci diduga bocor, koordinasikan penggantian kunci, pencabutan dan peninjauan akses sesuai prosedur; jangan mempertahankan kunci hanya agar pemulihan lebih cepat.

Muat ulang melalui mekanisme layanan yang didukung, dengan pemeriksaan konfigurasi dan pemulihan bila gagal. Cara reload berbeda antara web server, gateway, load balancer dan layanan terkelola; tidak ada satu perintah restart yang tepat untuk semuanya.

Contoh yang dijalankan pada layanan lokal

Paket lab infrastruktur 1.0 menjalankan server Node 24.21.0 dengan OpenSSL 3.6.4 pada 1 Oktober 2026. Nama lab.kompli.invalid, CA lab dan data respons sepenuhnya buatan. Waktu host dan trust store sistem tidak diubah.

Jalankan pada folder output baru; ganti path binary sesuai lingkungan:

LAB_OPENSSL=/path/to/openssl node tls-lab.mjs --out ./tls-output

Hasil sebelum pemulihan: CERT_HAS_EXPIRED. Sertifikat yang disajikan berakhir 30 September 2025. Setelah file diganti, koneksi masih mendapat error yang sama karena server masih memuat sertifikat lama.

Sesudah server memuat sertifikat baru, client yang memercayai CA lab dan meminta nama yang sesuai mendapat 200, penanda TLS_LAB_OK, serial 1001 dan akhir masa berlaku baru. Uji ulang tetap berhasil. Client dengan nama yang salah tetap ditolak dengan ERR_TLS_CERT_ALTNAME_INVALID; validasi tidak dilonggarkan untuk memulihkan koneksi.

Contoh ini menunjukkan kegagalan dan reload pada satu proses Node. Belum menguji ACME, pencabutan, DNS, mTLS, CDN, seluruh replica, client lain atau pemulihan produksi. Sertifikat buatan lab tidak boleh dipakai sebagai sertifikat layanan nyata.

Periksa seluruh jalur yang terdampak

Bandingkan sertifikat pada endpoint dengan hasil penerbitan: nama, penerbit, serial/fingerprint, masa berlaku dan trust. Uji halaman serta alur yang gagal, bukan hanya halaman depan. Periksa replica/titik TLS lainnya sesuai lingkup dan pastikan peringatan berhenti karena hasil nyata, bukan karena dibisukan.

Simpan waktu mulai gangguan, tindakan, pemilik, hasil client dan pekerjaan tersisa. Informasi teknis cukup untuk penelusuran; jangan memasukkan private key atau data pelanggan ke laporan umum.

Cegah kegagalan yang sama

Pisahkan penyebabnya: penerbitan tidak berjalan, challenge gagal, credential otomatisasi berubah, distribusi salah, reload tidak berjalan, atau peringatan tidak ditindaklanjuti. Simpan bukti per tahap dan uji perbaikannya dengan pemilik yang jelas.

Perbarui inventaris sertifikat dan proses pembaruan. Jadwal harus mengikuti masa berlaku dan kemampuan pemulihan; keberhasilan satu pembaruan manual belum membuktikan otomatisasi berikutnya akan berhasil.

Unduh artikel (.md)

Sumber rujukan

  1. RFC 5280 — Internet X.509 Public Key Infrastructure ↗IETF / RFC Editor; masa berlaku dan validasi sertifikat · Masa berlaku sertifikat dan pemeriksaan jalur trust.
  2. RFC 9525 — Service Identity in TLS ↗IETF / RFC Editor; identitas layanan dan sertifikat · Identitas layanan client; kegagalan nama berbeda dari kedaluwarsa.
  3. OpenSSL 3.6 — openssl-x509 ↗Proyek OpenSSL; dokumentasi resmi perintah pemeriksaan sertifikat · Pembacaan notBefore/notAfter, serial dan checkend.
  4. OWASP — Transport Layer Security Cheat Sheet ↗OWASP Foundation; rujukan praktik teknis, bukan hukum Indonesia · Gunakan TLS dan validasi sertifikat; perhatikan konfigurasi koneksi.

Baca naskah lengkap untuk melihat syarat dan pengecualiannya. Sesuaikan dengan layanan dan bidang usaha Anda.

Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

Konsultasikan kebutuhan Anda