Semak SSL/TLS laman sendiri dalam 5 minit

Gembok dalam bar alamat pelayar bukan bukti bahawa laman awak selamat. Ia bermakna sambungan antara pelawat dan pelayan disulitkan, dan nama hos dalam sijil padan dengan laman yang dibuka. Qualys SSL Labs sendiri mengingatkan bahawa TLS ialah asas untuk dibina di atasnya, bukan asas yang sudah cukup.

Yang lebih kerap merosakkan laman bukan sijil luput, tetapi perkara yang lebih halus: rantaian sijil yang tidak lengkap, protokol lama yang masih diterima pelayan, header HSTS yang hilang, dan kandungan yang masih dimuat melalui http pada halaman yang sepatutnya https. Semuanya boleh disemak dengan dua alat yang sudah ada pada hampir setiap pelayan Linux, openssl dan curl.

Lima semakan pantas, apa yang kita cari

• ▸ Rantaian sijil: pelayan patut menghantar sijil daun bersama sijil perantara, tetapi bukan sijil akar.
• ▸ Nama hos (SAN): pastikan www dan setiap subdomain yang awak guna tersenarai dalam sijil.
• ▸ Protokol: TLS 1.0 dan 1.1 sepatutnya sudah ditolak. Hanya TLS 1.2 dan 1.3 diterima.
• ▸ HSTS: header Strict-Transport-Security memaksa pelayar kekal pada HTTPS.
• ▸ Kandungan bercampur: tiada skrip, gaya atau iframe yang masih dimuat melalui http dalam halaman https.

Semakan 1, protokol, rantaian dan tarikh luput

Perintah paling pantas untuk melihat protokol, ciphersuite dan status pengesahan sekali gus ialah openssl s_client dengan pilihan -brief. Gantikan laman-anda.com dengan domain awak.

# 1) Protokol + status pengesahan (Verification: OK = rantaian lengkap)
openssl s_client -connect laman-anda.com:443 -servername laman-anda.com -brief </dev/null # 2) Tarikh luput sijil
openssl s_client -connect laman-anda.com:443 -servername laman-anda.com </dev/null 2>/dev/null | openssl x509 -noout -enddate # 3) Nama hos yang dilindungi (SAN)
openssl s_client -connect laman-anda.com:443 -servername laman-anda.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Cara membaca hasilnya: Verification: OK bermakna klien berjaya membina rantaian penuh sehingga ke sijil akar yang dipercayai. Ayat unable to verify the first certificate hampir selalu bermakna fail sijil awak tiada sijil perantara (fullchain), manakala self-signed certificate in certificate chain bermakna sijil akar pula turut dihantar, sedangkan klien sudah menyimpannya.

Untuk tahu berapa hari lagi sijil akan luput, tukar tarikh kepada saat, tolak daripada masa sekarang, dan bahagi dengan 86400 (bilangan saat dalam sehari). Kalau bakinya kurang daripada 30 hari, itu masanya untuk memulakan pembaharuan, bukan tunggu amaran pelayar.

Semakan 2, adakah protokol lama masih dibenarkan

Ramai pemilik laman menganggap TLS 1.0 sudah tiada kerana pelayar moden tidak menggunakannya. Yang dikira ialah apa yang pelayan masih terima. Uji dengan menawarkan versi lama secara paksa:

# Uji TLS 1.0 (pilihan -tls1) dan TLS 1.1 (pilihan -tls1_1)
openssl s_client -connect laman-anda.com:443 -servername laman-anda.com -tls1 -cipher DEFAULT@SECLEVEL=0 </dev/null 2>&1 | grep -i -e protocol -e alert | head -1 # Senarai pilihan yang disokong oleh openssl versi awak
openssl s_client -help

Jawapan tlsv1 alert protocol version bermakna pelayan sudah menolak protokol itu. Kalau keluar baris Protocol : TLSv1.0, pelayan masih menerimanya dan SSL Labs akan menghadkan gred awak. Nota penting: OpenSSL 3.x enggan menawarkan TLS 1.0 atau 1.1 secara lalai, jadi seting SECLEVEL=0 perlu supaya ujian ini benar-benar menguji pelayan, bukan menguji klien.

Semakan 3, HSTS dan kandungan bercampur

# HSTS mesti muncul pada respons HTTPS itu sendiri
curl -sSI https://laman-anda.com | grep -i strict-transport-security # Cari rujukan http dalam HTML (http: memadankan http sahaja, bukan https)
curl -sS https://laman-anda.com | grep -n http: | head

Header HSTS yang lengkap kelihatan begini: max-age=31536000. IncludeSubDomains. Preload. Syarat untuk senarai preload pelayar ialah max-age sekurang-kurangnya 31536000 saat (setahun), includeSubDomains, dan preload. Tetapi hstspreload.org sendiri menyatakan preloading tidak disyorkan kerana faedahnya kecil berbanding HSTS biasa, sedangkan membuangnya memakan masa. Uji dahulu dengan max-age pendek (contoh 300) sebelum naik ke nilai besar, kerana includeSubDomains yang dipasang terlalu awal boleh memutuskan subdomain yang belum bersedia.

Untuk kandungan bercampur, pelayar kini menaikkan permintaan gambar, audio dan video http menjadi https, tetapi menyekat skrip, stylesheet, iframe dan permintaan fetch yang tidak selamat. Masalahnya biasanya muncul sebagai fungsi yang senyap gagal, jadi semak konsol pembangun pelayar pada halaman paling penting.

Gred SSL Labs, apa sebenarnya yang dinilai

Ujian percuma Qualys SSL Labs mengira skor daripada tiga kategori: sokongan protokol 30 peratus, pertukaran kunci 30 peratus, dan kekuatan cipher 40 peratus. Skor itu diterjemah kepada gred:

• ▸ 80 atau lebih: A
• ▸ 65 atau lebih: B
• ▸ 50 atau lebih: C
• ▸ 35 atau lebih: D
• ▸ 20 atau lebih: E
• ▸ bawah 20: F

Peraturan tambahan selalunya lebih penting daripada angka: pelayan yang masih menerima TLS 1.0 atau 1.1 dihadkan pada gred B. TLS 1.3 yang tidak disokong menghadkan gred pada A- dengan amaran. HSTS yang tiada atau tidak sah juga menurunkan gred ke A-. Ada dua gred khas, T (sijil tidak dipercayai) dan M (nama dalam sijil tidak padan), dan dalam kedua-dua keadaan itu gred angka tidak lagi bermakna.

Sijil kini hidup lebih pendek: jadual 2026 sampai 2029

CA/Browser Forum Ballot SC-081v3 (April 2025) mengurangkan tempoh sah maksimum sijil TLS awam secara berperingkat:

• ▸ Sebelum 15 Mac 2026: maksimum 398 hari
• ▸ Dari 15 Mac 2026: maksimum 200 hari
• ▸ Dari 15 Mac 2027: maksimum 100 hari
• ▸ Dari 15 Mac 2029: maksimum 47 hari, dengan tempoh guna semula pengesahan domain hanya 10 hari

Let's Encrypt bergerak lebih awal dalam jadualnya sendiri: profil tlsserver sudah menerbitkan sijil 45 hari sejak 13 Mei 2026, sementara profil classic lalai turun kepada 64 hari pada 10 Februari 2027 dan 45 hari pada 16 Februari 2028. Tempoh guna semula kebenaran domain pula menyusut daripada 30 hari kepada 7 jam menjelang 2028. Nasihatnya jelas: perbaharui pada kira-kira dua pertiga hayat sijil, bukan pada selang keras, dan gunakan ARI (ACME Renewal Information) kalau klien awak menyokongnya.

Kesannya mudah diramal: kalau pembaharuan sijil bergantung pada seorang manusia yang mengingatinya, ia akan gagal lambat laun. Pada hayat 200 hari, kalendar tahunan sudah tidak cukup. Pada 45 hari, hampir tiada ruang untuk terlupa.

Kesilapan biasa yang memakan masa

• ▸ Menghantar hanya sijil daun tanpa sijil perantara, pelayar moden selalunya boleh membaikinya sendiri, tetapi sesetengah peranti mudah alih lama gagal terus.
• ▸ Mencampurkan fail fullchain dan private key dalam susunan yang salah. Uji konfigurasi (nginx -t) sebelum reload.
• ▸ Menguji dari rangkaian sendiri sahaja, masalah rantaian tidak kelihatan. Uji daripada hos lain.
• ▸ Sijil hanya untuk domain utama sedangkan pelawat juga membuka subdomain mail dan www.
• ▸ Menghidupkan includeSubDomains sebelum semua subdomain bersedia dilayan melalui HTTPS.
• ▸ Tiada amaran automatik apabila sijil hampir luput, ini punca klasik laman mati pada hujung minggu.

Senarai semak 5 minit (boleh salin)

#!/bin/bash
# semak-tls.sh, guna: bash semak-tls.sh laman-anda.com
D=$1 echo == Protokol, cipher dan pengesahan ==
openssl s_client -connect $D:443 -servername $D -brief </dev/null 2>&1 | grep -i -e protocol -e ciphersuite -e verification echo == Tarikh luput ==
openssl s_client -connect $D:443 -servername $D </dev/null 2>/dev/null | openssl x509 -noout -enddate echo == Nama hos (SAN) ==
openssl s_client -connect $D:443 -servername $D </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName echo == TLS 1.0 ditolak? ==
openssl s_client -connect $D:443 -servername $D -tls1 -cipher DEFAULT@SECLEVEL=0 </dev/null 2>&1 | grep -i -e protocol -e alert | head -1 echo == HSTS ==
curl -sSI https://$D | grep -i strict-transport-security || echo TIADA HSTS echo == Bilangan rujukan http ==
curl -sS https://$D | grep -c http:

Automasi, jangan bergantung pada ingatan

Semakan manual di atas bagus untuk diagnosis, tetapi ia tidak akan menyelamatkan laman awak pada bulan kedua. Yang menyelamatkan ialah pembaharuan automatik yang diuji. Kalau awak guna Certbot, perintah certbot renew menjalankan pembaharuan, dan certbot renew --dry-run meniru keseluruhan proses tanpa menyentuh sijil sebenar. Jalankannya dahulu, dan simpan tabiat menjalankannya semula setiap bulan. Kalau simulasi itu gagal, sebabnya dicetak terus pada skrin, dan puncanya selalunya cabaran DNS-01 atau laluan HTTP-01 yang tidak lagi boleh diakses.

Susunan yang saya pakai pada pelayan sendiri begini. Satu pemasa systemd menjalankan certbot renew dua kali sehari, pada pukul 3 pagi dan 3 petang, dengan kelewatan rawak sehingga 30 minit supaya semua pelayan tidak menyerbu Let's Encrypt pada saat yang sama. Selepas setiap percubaan, skrip kecil menyemak tarikh luput sijil yang sedang digunakan dan menghantar e-mel kalau bakinya kurang daripada 21 hari. Amaran 30 hari pada kalendar tidak berguna kalau tiada siapa membuka kalendar itu. E-mel amaran akan dibuka.

Kos sijil dalam ringgit

Sijil yang saya syorkan untuk laman biasa ialah Let's Encrypt atau CA bukan komersial lain, dan kosnya sifar ringgit. Bayarannya ialah hayat sijil yang pendek, 45 hari pada profil tlsserver, jadi automasi bukan pilihan, ia syarat. Sijil DV berbayar dari CA komersial pula biasanya dalam lingkungan 4 dolar hingga 40 dolar AS setahun mengikut panduan harga penyedia. Pada kadar Bank Negara Malaysia 1 dolar AS bersamaan 4.0715 ringgit pada 25 September 2026, itu kira-kira RM16 hingga RM160 setahun.

Untuk laman perniagaan kecil di Malaysia, DV sudah mencukupi kerana pelawat melihat gembok dan nama domain, bukan jenis pengesahan. OV dan EV lebih mahal kerana CA perlu menyemak dokumen syarikat, dan faedahnya kecil untuk laman yang pelawatnya sudah mengenali jenama. Satu perkara yang perlu disemak sebelum beli. Sesetengah penyedia mengenakan bayaran setiap domain tambahan atau setiap pemasangan semula, jadi harga tahun pertama tidak semestinya harga tahun seterusnya.

Soalan yang pembaca selalu tanya

Kalau gembok hilang, adakah laman saya digodam? Tidak semestinya. Gembok hilang bermakna pelayar tidak dapat mengesahkan sambungan, dan puncanya selalunya sijil luput, nama hos tidak padan, atau rantaian tidak lengkap. Kes yang paling kerap berlaku bukan serangan, tetapi sijil yang terlepas tarikh pembaharuan pada hujung minggu atau cuti panjang.

Kenapa ujian saya lulus di rumah tetapi pengguna lain dapat amaran? Kerana yang diuji ialah laluan dari rangkaian awak ke pelayan. Pelanggan yang melalui rangkaian berbeza, sistem operasi lama, atau penyemak imbas dalam aplikasi boleh menemui masalah rantaian yang tidak kelihatan di rumah. Uji juga daripada hos lain, contohnya pelayan kecil di luar negara, sebelum menganggap semuanya selesai.

Apa yang belum diketahui dan had semakan ini

Semakan di atas menyentuh lapisan TLS sahaja. Ia tidak menyemak kod aplikasi, tidak menyemak keselamatan e-mel yang berasingan seperti SPF, DKIM dan DMARC, dan tidak menyemak sama ada sijil pernah ditarik balik melalui OCSP atau CRL. Ia juga tidak menyentuh TLS antara pelayan dan pangkalan data, dan tidak menilai sama ada pelayan menghantar OCSP stapling. Tarikh dan dasar dalam tulisan ini pula boleh berubah bila CA/Browser Forum mengemas kini peraturan. Sahkan dengan sumber rasmi sebelum awak jadikannya dasar tetap untuk pelanggan.