Let's Encrypt menerbitkan sertifikat berumur sembilan puluh hari dan memperpanjangnya secara otomatis, karena itu orang berhenti memikirkannya sepekan setelah menyetelnya. Masalahnya, perpanjangan otomatis rusak dengan diam-diam: tidak ada yang melihat galatnya, dan tiga bulan kemudian situs menyambut pengunjung dengan peringatan peramban. Sejak 2025 Let's Encrypt juga berhenti mengirim surel pemberitahuan kedaluwarsa, jadi pengingat eksternal terakhir pun hilang.

Di bawah ini sebab-sebab perpanjangan berhenti bekerja, menurut urutan frekuensi yang menurun.

1. Sertifikat sudah diperpanjang dan layanannya tidak membacanya ulang

Yang paling umum. certbot renew sudah berjalan, berkas baru ada di disk, dan nginx atau Apache masih menyimpan yang lama di memori — dan terus menyajikannya kepada pengunjung sampai konfigurasinya dimuat ulang. Secara formal semuanya beres; kenyataannya situs punya sertifikat yang kedaluwarsa.

Obatnya adalah hook yang berjalan setelah perpanjangan berhasil:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Ini ditulis sekali ke berkas perpanjangan (/etc/letsencrypt/renewal/example.com.conf, bagian [renewalparams], baris renew_hook) dan sejak itu bekerja sendiri.

2. Server web berubah dan challenge-nya tidak

HTTP-01 challenge menuntut sebuah berkas dari /.well-known/acme-challenge/ disajikan lewat HTTP biasa. Biasanya itu rusak begini:

  • pengalihan tanpa syarat dari HTTP ke HTTPS ditambahkan ke konfigurasi — challenge mengikuti pengalihan dan gagal;
  • muncul aturan location ~ /\. dengan deny all, yang menutup setiap direktori bertitik, termasuk .well-known;
  • akar situs berpindah sementara pengaturan certbot masih menyimpan --webroot-path yang lama;
  • pemblokiran per negara atau autentikasi dasar dinyalakan dan ikut menjaring server validasi bersama semua orang.

Urutan yang benar di konfigurasi: pertama location khusus untuk /.well-known/acme-challenge/, baru kemudian pengalihan umum.

3. Timer-nya mati

Perpanjangan berjalan dari timer systemd atau tugas cron, dan keduanya bisa dimatikan tanpa sengaja saat penelusuran galat atau hilang saat pemindahan server.

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

Perintah kedua menjalankan siklus perpanjangan penuh dalam mode uji tanpa memakai kuota Anda. Inilah satu-satunya pemeriksaan yang menjawab lebih awal pertanyaan «apakah sebulan lagi ia akan diperpanjang» alih-alih setelah kejadian.

4. Sebuah domain tidak lagi mengarah ke sini

Sertifikat mencakup lima domain, salah satunya pindah ke host lain, DNS berubah. Validasi untuk domain itu berhenti lolos, dan certbot tidak memperpanjang seluruh sertifikat — termasuk empat domain yang masih bekerja. Domain berlebih harus dikeluarkan dari sertifikat, bukan diabaikan bersama pesannya.

5. Anda menabrak batas

Let's Encrypt membatasi jumlah sertifikat per domain per pekan. Biasanya itu hasil dari lingkaran «tidak berhasil, coba lagi» saat menelusuri galat. Ada server staging untuk percobaan (--dry-run atau --test-cert), dan itu perlu dipakai sebelum kuotanya habis, bukan sesudahnya.

Periksa yang disajikan, bukan yang disimpan

Setiap pemeriksaan yang bertumpu pada berkas di disk punya satu cacat: berkasnya bisa segar sementara pengunjung menerima sertifikat lama. Lihatlah dari sisi klien:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Opsi -servername wajib: tanpanya, pada server dengan beberapa situs Anda akan mendapat sertifikat virtual host yang datang pertama, bukan yang Anda maksud. Pada keluarannya, notAfter adalah tanggal kedaluwarsa yang sebenarnya.

Sekalian periksa rantainya:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Kalau hanya ada satu sertifikat berarti sertifikat perantaranya tidak disajikan. Peramban biasanya memaafkan susunan seperti itu — mereka menyusun rantainya sendiri — tetapi curl, aplikasi seluler dan klien Java akan gagal memvalidasi. Inilah klasik «di tempat saya terbuka normal, di pelanggan tidak jalan».

Berapa hari sebelumnya perlu diperingatkan

Tiga puluh hari adalah peringatan pertama yang masuk akal: itu juga sisa waktu ketika certbot mulai mencoba memperpanjang, jadi kalau sampai saat itu belum ada apa-apa berarti mekanismenya rusak. Empat belas hari adalah peringatan kedua, yang sudah menuntut tindakan hari ini. Tujuh hari adalah keadaan darurat.

Yang penting adalah mengawasi setiap sertifikat sekaligus, termasuk yang bukan dari Let's Encrypt: yang dibeli untuk setahun paling andal terlupakan, karena dalam setahun semua orang lupa baik bahwa ia ada maupun ke kotak surat siapa pemberitahuannya pergi. Satu halaman berisi domain, tanggal dan sisa hari menutup pertanyaan ini sepenuhnya — seperti pada demo di bawah.