Sijil SSL tamat: apa yang pelawat nampak dan cara membaikinya

Pemilik laman biasanya tahu sijil HTTPS sudah tamat bukan daripada sistem pemantauan, tetapi daripada mesej WhatsApp pelanggan. Ayat itu berbunyi begini: saya cuba buka laman awak, keluar amaran merah, jadi saya tutup. Orang yang benar-benar mahu membeli ialah orang yang akan memberitahu. Pelawat lain cuma pergi dan tidak kembali.

Masalah ini juga tidak lagi diingatkan oleh pihak yang mengeluarkan sijil. Let's Encrypt menamatkan perkhidmatan e-mel peringatan tamat tempoh pada 4 Jun 2025. Sebelum itu, e-mel akan sampai beberapa minggu lebih awal dan memberi masa untuk bertindak. Kini tiada e-mel itu. Sesiapa yang tidak memasang pemantauan sendiri akan tahu selepas pelawat sudah hilang.

Apa yang pelawat nampak bila sijil tamat

Setiap pelayar memaparkan amaran penuh, dan kod ralat di bawah butang Advanced memberitahu puncanya. Chrome dan Edge memaparkan Your connection is not private dengan kod NET::ERR_CERT_DATE_INVALID. Firefox memaparkan Warning: Potential Security Risk Ahead dengan SEC_ERROR_EXPIRED_CERTIFICATE. Safari memaparkan This Connection Is Not Private. Di terminal, curl menjawab dengan curl: (60) SSL certificate problem: certificate has expired.

Sebelum memuatkan halaman, pelayar memeriksa tiga perkara. Sama ada sijil masih dalam tempoh sah, sama ada nama domain dalam sijil sepadan dengan alamat yang ditaip, dan sama ada rantaiannya berakhir pada pihak berkuasa yang dipercayai. Kod ralat memberitahu yang mana satu gagal. Kalau anda pelawat, keluar sahaja. Kalau laman itu laman anda, kod itu ialah titik mula diagnosis.

• ▸ NET::ERR_CERT_DATE_INVALID, sijil sudah tamat atau belum mula sah. Jam peranti yang salah memberi kod yang sama, jadi uji dari peranti lain sebelum menyalahkan pelayan.
• ▸ NET::ERR_CERT_COMMON_NAME_INVALID, nama domain yang ditaip tiada dalam senarai SAN sijil. Ini berlaku bila www ditambah atau nama hos e-mel ditambah tanpa menerbitkan semula sijil.
• ▸ NET::ERR_CERT_AUTHORITY_INVALID, rantaian sijil tidak lengkap atau akar yang menandatangani sudah tidak dipercayai pelayar.
• ▸ NET::ERR_CERT_REVOKED, sijil ditarik balik oleh pihak berkuasa, biasanya selepas kunci persendirian terdedah.

Amaran ini bukan sekadar gangguan kecil. Pelawat masih boleh menekan Advanced dan teruskan di banyak pelayar, tetapi HSTS menutup jalan itu. HSTS ialah arahan yang dihantar pelayan dan disimpan oleh pelayar. Selepas pelayar melihatnya sekali, ia enggan membenarkan sambungan yang tidak boleh dipercayai ke domain itu, tanpa butang teruskan. Pada pelayan saya sendiri, header itu berbunyi max-age=15552000, iaitu kira-kira 180 hari.

Bukan halaman web sahaja yang berhenti

Satu sijil biasanya memuatkan beberapa nama. Sijil untuk laman ini mengandungi tiga nama sekaligus, iaitu thalhah.my, www.thalhah.my dan mail.thalhah.my. Ini menjimatkan masa pengurusan, tetapi ia juga bermakna satu tarikh luput menutup tiga perkhidmatan pada saat yang sama.

• ▸ Peti masuk e-mel. Klien di telefon dan komputer yang menggunakan nama hos mail.anda.com akan berhenti menyegerak atau meminta pengesahan semula.
• ▸ Aplikasi telefon. Aplikasi yang memanggil API laman gagal tanpa apa-apa amaran kepada pemilik laman.
• ▸ Skrip cron dan integrasi. Skrip yang menghantar atau mengambil data dengan curl mula menulis ralat 60 dalam log. Log itu jarang dibaca.
• ▸ Halaman pendaratan iklan. Trafik berbayar yang sampai semasa amaran aktif tetap dibayar, tetapi hampir tiada yang bertukar menjadi pesanan.
• ▸ E-mel sistem. Laporan pesanan, notifikasi borang dan e-mel set semula kata laluan yang dihantar melalui laman itu boleh gagal.

Sebab itu menunggu sehingga esok jarang menjadi pilihan yang baik. Kerosakan berlaku serentak pada setiap saluran yang berkongsi sijil itu.

Diagnosis pantas, sijil atau jam

Dua perintah di bawah menjawab soalan asas: berapa hari lagi, dan adakah rantaiannya sihat. Ia membaca sijil yang benar-benar dihidangkan pelayan, bukan fail yang disangka betul.

# Tarikh sah sijil yang dihidangkan pelayan
echo | openssl s_client -connect laman-anda.com:443 -servername laman-anda.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

# Rantaian penuh dan status pengesahan
echo | openssl s_client -connect laman-anda.com:443 -servername laman-anda.com 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:|Verify return code"

Baris Verify return code mesti berbunyi 0 (ok). Kalau ia berbunyi unable to verify the first certificate, rantaian anda tidak lengkap dan sesetengah peranti akan menolaknya walaupun tarikhnya masih jauh. Baris notAfter pula tarikh yang perlu diawasi. Pada pelayan ini, rantaian penuh berbunyi: sijil laman, kemudian YE2, kemudian ISRG Root YE, kemudian ISRG Root X2, dan berakhir pada ISRG Root X1.

Kalau semua laman memberi amaran, bukan satu sahaja, jam peranti awak yang salah. Uji dari telefon supaya tidak terperangkap mencari masalah di pelayan yang sebenarnya sihat. Kalau satu laman sahaja yang bermasalah, ia di pihak pelayan.

Cara membaikinya, langkah demi langkah

Jangan terus paksa pembaharuan. Jalankan dry-run dahulu, kerana ia menjalankan cabaran sebenar terhadap pelayan ujian Let's Encrypt tanpa menulis apa-apa dan tanpa menggunakan kuota pengeluaran.

# 1) Lihat sebab sebenar dahulu
sudo certbot renew --dry-run

# 2) Pembaharuan biasa, hanya sijil yang hampir tamat
sudo certbot renew

# 3) Kalau sijil sudah tamat, keluarkan yang baharu
sudo certbot renew --force-renewal --cert-name thalhah.my

# 4) Beritahu pelayan web supaya membaca sijil baharu
sudo nginx -t && sudo systemctl reload nginx

Tiga perkara perlu diberi perhatian. Pertama, dry-run menjalankan cabaran dan hook, jadi kegagalan sebenar muncul di situ dan bukan tiga bulan kemudian. Kedua, --force-renewal menggunakan kuota sebenar, iaitu lima sijil untuk set nama yang sama dalam tujuh hari, jadi jangan jadikannya alat mencari masalah. Ketiga, reload bukan restart. Pelayan web membaca sijil ke dalam memori semasa ia mula, jadi fail baharu di cakera tidak mengubah apa-apa sehingga ia dimuat semula.

Selepas itu, sahkan sijil yang dihidangkan, bukan sijil pada cakera. Ini kesilapan yang paling kerap berlaku: pembaharuan berjaya, tetapi pelayan masih menghidangkan sijil lama kerana belum dimuat semula.

# Tarikh pada cakera
openssl x509 -noout -enddate -in /etc/letsencrypt/live/laman-anda.com/cert.pem

# Tarikh yang benar-benar dihidangkan
openssl s_client -connect laman-anda.com:443 -servername laman-anda.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

Dua tarikh itu mesti sama. Kalau tidak, sama ada pelayan belum dimuat semula, atau fail konfigurasi yang aktif menunjuk ke laluan sijil yang berlainan daripada yang awak perbaharui.

Satu lagi perkara yang selalu terlepas: perkhidmatan lain membaca salinan sijil sendiri. Pada pelayan ini, satu hook selepas pembaharuan menyalin fullchain ke /etc/ssl/mail/ dan memuat semula postfix serta dovecot, kerana perkhidmatan e-mel tidak membaca fail Let's Encrypt secara langsung. Hook jenis ini hanya berjalan apabila pembaharuan benar-benar berlaku, jadi ia selamat diletakkan terus dalam folder hook.

Sepuluh punca pembaharuan automatik gagal senyap

Pembaharuan yang gagal tidak mematikan apa-apa pada hari itu. Ia hanya muncul 60 hingga 90 hari kemudian, iaitu bila sijil benar-benar tamat. Ini punca yang paling kerap saya jumpa.

• ▸ Port 80 ditutup atau dihalang firewall. Cabaran HTTP-01 hanya boleh dijalankan pada port 80, jadi menutup port itu selepas sijil pertama diterbitkan mematikan pembaharuan seterusnya.
• ▸ Halaman HTTP kini dijawab orang lain. Kalau domain diletakkan di belakang CDN atau proksi, permintaan ke .well-known/acme-challenge sampai ke tempat yang salah.
• ▸ Satu nama dalam sijil gagal, semuanya gagal. Contoh biasa: mail.anda.com sudah berpindah ke penyedia e-mel lain dan rekod A lama dipadam, tetapi nama itu masih tersenarai dalam sijil.
• ▸ Rekod AAAA lama masih menunjuk ke pelayan lama. Pengesah boleh memilih laluan IPv6, dan cabaran itu sampai ke tempat yang sudah tiada.
• ▸ Pelayan dipindah atau dipulihkan daripada sandaran, dan pemasa pembaharuan tidak dibawa bersama.
• ▸ Fail konfigurasi pelayan web dinamakan semula, jadi plugin pengesahan tidak lagi tahu di mana hendak menulis fail cabaran.
• ▸ Jam pelayan tersasar. Sijil kelihatan belum sah atau sudah tamat walaupun tarikh sebenarnya betul.
• ▸ Cakera penuh atau keizinan folder cabaran berubah, jadi fail cabaran tidak dapat ditulis dan pengesahan gagal.
• ▸ Had kadar Let's Encrypt. Lima sijil untuk set nama yang sama dalam tujuh hari, lima puluh sijil untuk satu domain berdaftar dalam tujuh hari, dan lima kegagalan pengesahan bagi satu nama setiap jam. Cuba berulang kali memanjangkan masalah, bukan memendekkannya.
• ▸ Akaun atau konfigurasi klien dipadam. Ini berlaku bila seseorang memasang semula klien semasa mencari masalah dan melupuskan fail lama dalam folder /etc/letsencrypt/renewal/.

Semua sepuluh punca ini senyap. Tiada satu pun menulis mesej kepada pemilik laman. Sebab itu pemantauan berasingan diperlukan, bukan keyakinan bahawa automasi sentiasa berjalan.

Cara tahu lebih awal daripada pelanggan

Skrip pendek di bawah boleh dijalankan sekali sehari dan memberi amaran apabila hari yang tinggal jatuh di bawah paras yang dipilih.

#!/bin/sh
# semak-sijil.sh, letak dalam cron harian
set -eu
HOS="laman-anda.com"
TAMAT=$(echo | openssl s_client -connect "$HOS:443" -servername "$HOS" 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
HARI=$(( ( $(date -d "$TAMAT" +%s) - $(date +%s) ) / 86400 ))
echo "$HOS tamat dalam $HARI hari"
[ "$HARI" -gt 21 ] || echo "AMARAN: perbaharui sijil $HOS sekarang"

Paras 21 hari dipilih dengan sengaja. Certbot memperbaharui sijil apabila tinggal kira-kira 30 hari, jadi baki hari yang sihat tidak pernah jatuh jauh di bawah 29 hari. Apabila amaran 21 hari berbunyi, pembaharuan sudah gagal sekurang-kurangnya sekali, dan masih ada tiga minggu untuk membaikinya tanpa pelawat sedar.

Pada pelayan ini, semakan sijil dijalankan sekali sehari untuk setiap nama hos, dengan amaran bertingkat pada 21, 14, 7 dan 3 hari supaya e-mel tidak berulang setiap hari. Pemantauan pihak ketiga juga berguna. Let's Encrypt menyenaraikan perkhidmatan seperti Red Sift Certificates Lite, percuma sehingga 250 sijil.

Bila sijil tamat bukan kerana tarikhnya sendiri

Ada kalanya sijil laman masih sah, tetapi pelanggan tertentu tetap gagal. Ini berlaku bila akar dalam rantaian yang tamat tempoh. Kes terbesar setakat ini ialah DST Root CA X3, yang tamat pada 30 September 2021 dan menerbitkan amaran pada peranti lama. Sambungan silang yang mengekalkan sokongan untuk Android lama tamat pula pada 30 September 2024. Cloudflare mengukur bahawa kira-kira 2.96 peratus permintaan Android ketika itu datang daripada peranti yang terjejas.

Pengajarannya mudah. Yang perlu dibaca bukan hanya tarikh sijil anda, tetapi juga tarikh setiap sijil dalam rantaian. Perubahan jadual hayat sijil bermakna kejadian seperti ini akan berlaku lebih kerap. Ballot SC-081v3 mengehadkan tempoh sah maksimum sijil awam kepada 200 hari mulai 15 Mac 2026, 100 hari mulai 15 Mac 2027, dan 47 hari mulai 15 Mac 2029. Jadual penuh dan kaedah semakan TLS yang lebih lengkap ada dalam artikel semak SSL/TLS laman sendiri.

Soalan yang selalu ditanya

Kalau sijil tamat, adakah laman saya digodam? Tidak semestinya. Sijil tamat ialah masalah pentadbiran, bukan tanda pencerobohan. Tetapi semak juga sama ada fail baharu muncul dalam webroot, dan sama ada pelayan anda mengalihkan trafik ke tempat yang anda tidak kenal.

Bolehkah pelawat teruskan juga? Di banyak pelayar, ya, melalui butang Advanced. Dengan HSTS, tidak. Jangan berharap kepada pelawat yang sanggup menekan butang itu, kerana sambungan sedemikian disulitkan tanpa identiti pelayan yang disahkan.

Adakah data pelanggan terdedah semasa amaran? Tidak semasa amaran penuh, kerana pelayar menyekat sambungan sebelum apa-apa dihantar. Risiko muncul hanya untuk pelawat yang meneruskan.

Kalau saya beli sijil setahun, hilangkah masalah ini? Ia menjadi lebih jarang, bukan hilang. Sijil setahun masih perlu diperbaharui setiap tahun, dan mulai 15 Mac 2029 tempoh sah maksimum untuk sijil awam ialah 47 hari. Sebab itu cara kerja yang selamat ialah automasi dan pemantauan, bukan tempoh yang panjang.

Perlukah saya restart pelayan? Tidak. Reload cukup dan ia tidak memutuskan sambungan yang sedang berjalan. Simpan restart untuk perubahan yang benar-benar memerlukannya.

Bilakah saya perlu memanggil orang lain? Kalau dry-run gagal dua kali dengan sebab yang sama, kalau akaun DNS atau panel hosting tidak boleh diakses, atau kalau sijil sempat tamat sementara anda tidak pasti apa yang sedang dihidangkan pelayan.

Apa yang belum diketahui dan had panduan ini

Panduan ini menyentuh TLS untuk laman web dan perkhidmatan yang berkongsi sijil itu. Ia tidak menyentuh pengesahan e-mel seperti SPF, DKIM dan DMARC, yang masalahnya berasingan. Ia juga tidak boleh menjamin pihak berkuasa sijil sentiasa boleh dihubungi ketika anda memerlukannya, kerana had kadar terpakai. Kalau panel hosting yang menguruskan sijil anda, penyedialah satu-satunya pihak yang tahu sama ada cubaan terakhir gagal. Tanya mereka secara bertulis dan minta tarikh luput semasa.