# Mengelola sertifikat TLS dan pembaruannya

Sumber diperiksa. Metode: https://kompli.id/metodologi/.

Pembaruan sertifikat selesai setelah layanan menyajikan sertifikat yang benar dan client tetap memvalidasinya. Inventaris, otomatisasi dan pemantauan perlu punya pemilik yang jelas.

URL kanonis: https://kompli.id/panduan/keamanan/mengelola-sertifikat-tls/
Sumber diakses: 2026-10-01
Diperbarui: 2026-10-02
Penulis: Kompli
Sumber diperiksa: 2026-10-02


## Siapa yang memastikan sertifikat diperbarui?

**Tentukan pemilik sertifikat, jalur pembaruan dan cara membuktikan layanan sudah memakai sertifikat baru.** Mengaktifkan HTTPS saat peluncuran belum menyelesaikan pekerjaan pemeliharaan.

TLS melindungi koneksi dan membantu client memeriksa identitas tujuan. Sertifikat memuat informasi seperti penerbit, identitas layanan serta awal dan akhir masa berlaku. Sertifikat yang belum kedaluwarsa tetap dapat gagal karena nama tidak cocok atau rantai kepercayaan tidak sesuai.

## Inventaris mengikuti titik koneksi

Catat nama layanan/hostname, port, lingkungan, tempat TLS diakhiri dan penanggung jawabnya. Satu domain dapat memiliki beberapa jalur: client ke CDN, CDN ke origin, API, integrasi internal atau aplikasi mobile. Sertifikat publik dan CA internal dapat memakai jalur penerbitan serta trust yang berbeda.

Gunakan [inventaris sertifikat TLS](/template/inventaris-sertifikat-tls/). Isinya cukup lokasi terkendali dan pemilik kunci; jangan menyalin private key, token DNS atau kata sandi ke worksheet. Jika penyedia mengelola sertifikat, catat pembagian pekerjaan dan siapa menerima peringatan kegagalan.

## Periksa identitas dan masa berlaku

Contoh membaca file lokal dengan OpenSSL **3.6.4**:

```sh
openssl x509 -in service.pem -noout -issuer -serial -dates -ext subjectAltName
```

Cocokkan *Subject Alternative Name* atau SAN dengan identitas yang akan diperiksa client. `notBefore` dan `notAfter` menjelaskan masa berlaku; catat waktu dengan zona waktunya. Jangan menyamakan hasil baca file dengan sertifikat yang sedang disajikan endpoint.

Untuk pemeriksaan tenggat pada file:

```sh
openssl x509 -in service.pem -noout -checkend 604800
```

Angka tersebut adalah tujuh hari dalam detik, **contoh ambang peringatan**, bukan jadwal pembaruan universal. Exit code nol berarti sertifikat yang diperiksa tidak akan kedaluwarsa dalam interval itu; nonnol perlu ditangani. Perintah ini belum memeriksa seluruh trust, identitas, pencabutan atau keadaan layanan.

## Rencanakan pembaruan dan peringatan

Pisahkan pekerjaan menerbitkan, memasang dan memuat sertifikat. Pada layanan yang mendukung ACME, otomatisasi perlu memiliki izin secukupnya untuk membuktikan kendali domain dan mengirim hasil ke tempat yang benar. *ACME Renewal Information* atau ARI menyediakan jendela pembaruan dari CA jika penerbit dan client mendukungnya; periksa dukungan implementasi, bukan menganggap semua client otomatis memakainya.

Masa berlaku tidak selalu 90 hari. Let’s Encrypt menerbitkan pengumuman perubahan per profil serta tahap penerapannya; periksa profil yang dipakai dan tanggal aktual sertifikat. Jangan mengandalkan interval tetap 60 hari tanpa membandingkannya dengan masa berlaku.

Let’s Encrypt mengumumkan penghentian email pengingat kedaluwarsa pada **4 Juni 2025**. Siapkan pemantauan sendiri dan jalur eskalasi yang diuji. Untuk CA lain, periksa mekanisme pemberitahuannya; jangan menganggap semuanya sama.

Peringatan sebaiknya mencakup pekerjaan pembaruan yang gagal, sertifikat pada endpoint yang mendekati habis, serta perbedaan antara file baru dan layanan yang belum memuatnya. Pilih ambang berdasarkan masa berlaku dan waktu pemulihan yang diperlukan; tujuh hari tidak selalu cukup untuk semua sertifikat.

## Contoh nyata di lab: file baru belum cukup

[Source dan hasil lab infrastruktur 1.0](/unduhan/lab-infrastruktur-v1.zip) memuat eksperimen Node **24.21.0** dan OpenSSL **3.6.4**, dijalankan **1 Oktober 2026**. Server hanya mendengar pada loopback; CA dan kunci dibuat khusus lab. Tidak menjalankan ACME atau penerbitan sertifikat publik.

| Keadaan | Hasil client |
| --- | --- |
| Server memuat sertifikat yang berakhir 30 September 2025 | `CERT_HAS_EXPIRED`; koneksi ditolak. |
| File diganti dengan sertifikat baru, server belum memuatnya | Tetap `CERT_HAS_EXPIRED`. |
| Server memuat sertifikat baru bernomor serial 1001 | 200 dan `TLS_LAB_OK`. |
| Client meminta identitas hostname yang salah | `ERR_TLS_CERT_ALTNAME_INVALID`; tetap ditolak. |
| Uji ulang dengan nama yang sah | Tetap 200 dengan serial 1001. |

Sertifikat baru lab berlaku satu hari. `-checkend 0` memberi exit code **0**, tetapi `-checkend 604800` memberi **1**. Perbedaan ini menunjukkan pentingnya membaca ambang pemeriksaan; bukan tanda bahwa TLS harus dinonaktifkan.

## Buktikan pembaruan selesai

Dari titik client yang disepakati, periksa nama tujuan, trust, serial/fingerprint serta waktu akhir sertifikat yang disajikan. Uji fungsi yang sah. Untuk beberapa replica atau terminator TLS, periksa cakupan masing-masing; satu koneksi berhasil tidak mewakili semuanya.

Catat pemilik, waktu pembaruan, hasil endpoint, peringatan dan langkah yang belum diperiksa. Lab ini tidak membuktikan scheduler, DNS challenge, CDN, semua replica atau revocation bekerja. Untuk gangguan yang sudah terjadi, lanjutkan ke [penanganan sertifikat kedaluwarsa](/panduan/keamanan/sertifikat-tls-kedaluwarsa/); untuk client mobile, periksa [validasi koneksinya](/panduan/keamanan/pemeriksaan-jaringan-mobile/).

## Hasil tambahan: dua replika belum tentu seragam

Pada **2 Oktober 2026**, `tls-replicas.mjs` dalam [lab operasi infrastruktur 1.0](/unduhan/lab-operasi-infrastruktur-v1.zip) dijalankan dengan Node **24.21.0** dan OpenSSL **3.6.4**, macOS arm64. Dua listener HTTPS loopback memakai CA sementara yang hanya dipercayai client lab. Koneksi baru tidak memakai kembali sesi TLS.

```sh
LAB_OPENSSL=/path/to/openssl node tls-replicas.mjs --out tls-replicas-results.json
```

| Keadaan aktual | Hasil endpoint |
| --- | --- |
| A dan B memuat sertifikat awal | Keduanya 200; serial `07D0`. |
| Sertifikat pengganti sudah dibuat, listener belum reload | Keduanya tetap serial `07D0`. |
| Hanya A memuat konteks baru | A `07D1`, B masih `07D0`; satu endpoint sukses belum mewakili keduanya. |
| A dan B selesai reload, lalu uji ulang | Keduanya 200, penanda replika benar dan serial `07D1`. |
| Nama tujuan salah | Ditolak dengan `ERR_TLS_CERT_ALTNAME_INVALID`. |

Delapan observasi tersebut menguji dua listener lokal, bukan load balancer, seluruh fleet, scheduler, ACME atau pencabutan sertifikat. Kunci/sertifikat sementara dihapus runner dan tidak disertakan dalam ZIP. Hasil sertifikat kedaluwarsa pada bagian sebelumnya tetap observasi 1 Oktober, bukan tes ulang pada tanggal ini.

## Rencana verifikasi ACME: penerbitan sampai pemuatan

RFC 8555 menjelaskan order, authorization/challenge, finalization memakai CSR dan pengambilan sertifikat. **Alur ACME belum dijalankan pada batch ini.** Contoh lokal di atas menerbitkan melalui CA buatan, sehingga tidak membuktikan kendali domain atau pekerjaan client ACME.

Sebelum produksi, pilih lingkungan pengujian CA/client yang sah dan rencanakan: domain yang diizinkan; challenge berhasil/gagal; izin DNS atau HTTP yang dibutuhkan; masa tunggu dan kegagalan order; pengambilan chain; pemasangan key/certificate yang cocok; serta reload setiap replika. Akun ACME, kunci sertifikat dan token DNS adalah kebutuhan berbeda; jangan menyamakan izin atau membagikannya ke laporan.

Catat dukungan ARI terpisah dari ACME dasar. Setelah penerbitan, periksa sertifikat dari jalur client ke setiap terminator yang masuk lingkup. Kegagalan satu replika perlu tindakan dan uji ulang; hasil sukses dari satu koneksi yang melewati load balancer tidak cukup menunjukkan seluruh replika telah berubah.

Hubungkan referensi kunci dengan [inventaris kunci](/template/inventaris-kunci-enkripsi/) dan bukti per titik dengan [inventaris TLS](/template/inventaris-sertifikat-tls/). Tidak ada order publik atau perubahan DNS produksi yang dilakukan untuk contoh ini.
## Sumber rujukan

- [RFC 9525 — Service Identity in TLS](https://www.rfc-editor.org/rfc/rfc9525.html) — Identitas layanan yang diharapkan client dan Subject Alternative Name.
- [RFC 5280 — Internet X.509 Public Key Infrastructure](https://www.rfc-editor.org/rfc/rfc5280.html) — Bagian 4.1.2.5 dan 6: masa berlaku serta validasi sertifikat.
- [RFC 9773 — ACME Renewal Information (ARI) Extension](https://www.rfc-editor.org/rfc/rfc9773.html) — Jendela pembaruan dari CA untuk client ACME yang mendukung ARI.
- [OpenSSL 3.6 — openssl-x509](https://docs.openssl.org/3.6/man1/openssl-x509/) — Tanggal, serial, issuer, extension dan checkend pada OpenSSL 3.6.
- [Let’s Encrypt — Decreasing Certificate Lifetimes to 45 Days](https://letsencrypt.org/2025/12/02/from-90-to-45.html) — Perubahan profil/lifetime; jangan memakai interval hardcoded yang mengabaikan umur sertifikat.
- [Let’s Encrypt — Ending Support for Expiration Notification Emails](https://letsencrypt.org/2025/01/22/ending-expiration-emails/) — Pengumuman penghentian email kedaluwarsa pada 4 Juni 2025; rekomendasi vendor dalam artikel tidak digunakan.
- [RFC 8555 — Automatic Certificate Management Environment](https://www.rfc-editor.org/rfc/rfc8555.html) — §7.1.6, §7.4/7.5: status, order dan authorization; tambahan rencana 2 Oktober 2026, belum uji client ACME.

## Perlu membahas kebutuhan tim Anda?

Ceritakan sistem yang dikelola dan kebutuhan pengamanan tim Anda.

[Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=keamanan)

## Bacaan terkait

- [Apa yang dilakukan saat sertifikat TLS kedaluwarsa?](https://kompli.id/panduan/keamanan/sertifikat-tls-kedaluwarsa/)
- [Inventaris sertifikat TLS](https://kompli.id/template/inventaris-sertifikat-tls/)
- [Keamanan website sebelum peluncuran: apa yang perlu diperiksa?](https://kompli.id/panduan/keamanan/keamanan-website-sebelum-peluncuran/)
- [Memeriksa komunikasi jaringan aplikasi mobile](https://kompli.id/panduan/keamanan/pemeriksaan-jaringan-mobile/)