Rantai Sertifikat SSL: Urutan, Cara Cek, dan Perbaikan

Apa Itu Rantai Sertifikat SSL?

Rantai sertifikat SSL (disebut juga rantai kepercayaan atau jalur sertifikasi) adalah daftar berurutan sertifikat digital yang menghubungkan sertifikat SSL/TLS situs Anda ke Certificate Authority (CA) root yang tepercaya. Setiap sertifikat dalam rantai ditandatangani secara digital oleh sertifikat di atasnya, sehingga terbentuk jalur kepercayaan yang dapat diverifikasi dari server Anda hingga CA root yang sudah dipercaya browser.

Bayangkan seperti rantai rekomendasi. Sertifikat server Anda berkata: "Saya example.com." CA intermediate berkata: "Saya menjamin sertifikat example.com." CA root berkata: "Saya menjamin intermediate itu." Browser Anda sudah memercayai CA root, jadi dengan menelusuri rantai tanda tangan, ia juga memercayai server Anda.

Saat Anda membuka situs HTTPS, browser menelusuri rantai ini dalam hitungan milidetik. Jika setiap mata rantai beres, halaman dimuat tanpa peringatan. Jika ada mata rantai yang hilang, kedaluwarsa, atau tidak tepercaya, Anda akan melihat peringatan keamanan seperti NET::ERR_CERT_AUTHORITY_INVALID sebagai ganti halaman.

Tiga Jenis Sertifikat dalam Sebuah Rantai

Setiap rantai punya tiga jenis sertifikat, meskipun server bisa mengirim lebih dari satu intermediate:

Sertifikat Root

Sertifikat root adalah jangkar kepercayaan di puncak rantai. Sertifikat ini self-signed, artinya Certificate Authority menandatangani sertifikatnya sendiri. Sertifikat root sudah terpasang di browser dan sistem operasi Anda — kumpulan ini disebut trust store.

Daftar root milik Chrome sendiri berisi sekitar 100 root (Chrome Root Store); Mozilla, Apple, dan Microsoft punya daftar sendiri. Organisasi seperti DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign, dan Google Trust Services mengoperasikan root. Karena kunci root sangat berharga, CA menyimpannya offline di hardware security module dan hanya memakainya untuk menandatangani intermediate.

Sertifikat Intermediate

Sertifikat intermediate berada di antara root dan sertifikat server Anda. CA root menandatangani sertifikat intermediate, lalu CA intermediate menandatangani sertifikat end-entity (server). Kebanyakan CA memakai satu atau dua intermediate.

Server web Anda harus mengirim sertifikat intermediate bersama sertifikat leaf selama TLS handshake. Chrome bisa mengunduh intermediate yang hilang dan Firefox memuatnya terlebih dahulu, tetapi aplikasi, klien API, dan perangkat Android lama tidak punya keduanya, sehingga bagi mereka rantainya putus.

Sertifikat Leaf (Sertifikat Server)

Sertifikat leaf (disebut juga sertifikat end-entity atau sertifikat server) adalah sertifikat yang diinstal di server web Anda. Berisi nama domain, kunci publik, periode validitas, dan informasi tentang penerbit (CA intermediate yang menandatanganinya).

Ini adalah sertifikat pertama yang diterima browser selama TLS handshake. Browser kemudian naik melalui rantai, memverifikasi setiap tanda tangan hingga mencapai root terpercaya.

Cara Kerja Rantai Kepercayaan

Saat browser Anda terhubung ke website melalui HTTPS, TLS handshake memicu proses verifikasi rantai yang terjadi dalam hitungan milidetik:

• Server mengirim sertifikatnya — leaf dulu, lalu intermediate.
• Browser membangun jalur — dari leaf naik ke root dalam daftarnya sendiri. Jika intermediate hilang, Chrome mengunduhnya dari alamat yang tertulis di sertifikat (AIA), dan Firefox memakai set bawaannya sendiri; banyak klien lain langsung gagal.
• Tanda tangan diperiksa — setiap sertifikat harus ditandatangani dengan kunci sertifikat di atasnya.
• Root diperiksa — jalur harus berakhir di root yang ada dalam daftar browser. Root yang tidak dikenal gagal.
• Masa berlaku diperiksa — setiap sertifikat harus dalam rentang tanggalnya dan tidak dicabut, dan leaf harus mencakup nama di bilah alamat.

Rantai Nyata: Apa yang Dikirim 12 Situs Besar

Pada 27 Oktober 2026 kami meminta rantai dari 12 situs terbesar (openssl s_client -showcerts, dari dua lokasi). Tidak ada yang hanya mengirim leaf, dan beberapa mengirim sertifikat tambahan yang ditandatangani silang agar perangkat lama tetap bisa mencapai root yang mereka kenal. Apa yang dikirim server bisa berubah menurut versi TLS Anda, dukungan ECDSA pada klien, dan lokasi CDN mana yang menjawab: misalnya facebook.com mengirim 3 sertifikat lewat TLS 1.2.

Apa yang Terjadi Setelah Verifikasi

Jika semua pemeriksaan lolos, koneksi dilanjutkan. Jika salah satu gagal, bahkan pada sebuah intermediate, browser menampilkan peringatan seperti "Koneksi Anda bukan koneksi pribadi" dengan kode seperti NET::ERR_CERT_AUTHORITY_INVALID. (Kegagalan sebelum sertifikat apa pun diperiksa, tepatnya saat TLS handshake itu sendiri, menampilkan kode lain: ERR_SSL_PROTOCOL_ERROR atau ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

Inilah alasan seluruh rantai penting, bukan hanya sertifikat leaf. Intermediate yang kedaluwarsa merusak HTTPS sama seperti sertifikat server yang kedaluwarsa, kecuali klien bisa membangun jalur lain yang menghindarinya.

Mengapa Sertifikat Intermediate Ada

CA root secara teori bisa menandatangani setiap sertifikat server secara langsung dan melewati intermediate sepenuhnya. Namun ada tiga alasan penting mengapa mereka tidak melakukannya:

• Isolasi keamanan — Kunci privat CA root disimpan offline di HSM dalam brankas yang aman secara fisik. Kunci ini hanya dipakai untuk menandatangani intermediate, bukan jutaan sertifikat server satu per satu. Ini secara drastis mengurangi risiko kunci root disusupi.
• Pembatasan kerusakan — Jika sebuah CA intermediate disusupi, hanya sertifikat dari intermediate itu yang terdampak. CA root dapat mencabut intermediate yang disusupi dan menerbitkan yang baru — tanpa membatalkan setiap sertifikat yang pernah diterbitkannya.
• Fleksibilitas operasional — CA memakai intermediate yang berbeda untuk tujuan yang berbeda: satu untuk sertifikat DV, lainnya untuk EV, dan terpisah untuk wilayah atau algoritma kunci yang berbeda (RSA dan ECDSA).

Cara Memeriksa Rantai Sertifikat SSL Anda

Ada tiga cara untuk memeriksa rantai sertifikat website, dari alat command line hingga pemeriksaan berbasis browser.

Metode 1: OpenSSL (Command Line)

Perintah openssl adalah cara paling detail untuk memeriksa rantai sertifikat. Jalankan ini di terminal Anda:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Metode 2: Penampil Sertifikat Browser

Setiap browser besar menampilkan rantai yang dibangunnya (yang bisa berbeda dari yang dikirim server, jika ia mengunduh sendiri intermediate yang hilang):

• Chrome: klik ikon di kiri alamat → Koneksi aman → Sertifikat valid, lalu buka tab Detail untuk melihat hierarki sertifikat
• Edge: klik ikon gembok → "Connection is secure" → ikon sertifikat di bagian atas panel
• Firefox: klik ikon gembok → "Connection secure" → "More information" → "View Certificate"; setiap sertifikat dalam rantai punya tab sendiri
• Safari (18.4 ke atas): pilih Safari > Detail Keamanan Koneksi di bilah menu (Apple); di iPhone, ketuk sisi kiri kolom alamat → "Privacy & Security" → "Connection Security Details"

Metode 3: DNS Robot SSL Checker

Pemeriksaan tercepat dari luar jaringan Anda adalah SSL Checker kami: menampilkan rantai yang dikirim server, apakah daftar root Mozilla, Chrome, Apple, dan Microsoft memercayainya, peringatan jika rantai tidak lengkap, dan tanggal setiap sertifikat. Untuk situs di balik Cloudflare, alat ini membaca sertifikat dari log CT publik, jadi di sana rantai yang dikirim server tidak diperiksa.

Error Rantai Sertifikat Umum dan Cara Memperbaikinya

Masalah rantai sertifikat adalah salah satu penyebab paling sering error HTTPS. Berikut error yang paling mungkin Anda temui dan cara menyelesaikan masing-masing.

Sertifikat Intermediate Hilang

Pesan error: "unable to get local issuer certificate" (curl, Python, PHP), "unable to verify the first certificate" (Node.js) atau "incomplete certificate chain"

Penyebab: server hanya mengirim sertifikat leaf. Chrome sering memperbaikinya dengan mengunduh sendiri intermediate-nya (verifier Apple juga begitu), sehingga situs tampak normal di browser sementara curl di Linux, Python, Java, callback pembayaran, dan banyak aplikasi gagal.

Solusi: kirim intermediate bersama leaf. Dengan Let's Encrypt, arahkan server ke fullchain.pem, bukan cert.pem; dengan CA lain, unduh intermediate-nya dan letakkan setelah sertifikat Anda dalam satu file:

cat your-domain.crt intermediate.crt > fullchain.crt

Sertifikat Self-Signed dalam Rantai

Pesan error: "self-signed certificate in certificate chain" (error OpenSSL 19)

Penyebab: rantai berakhir di root yang tidak dipercaya klien: CA privat atau perusahaan, atau proxy atau antivirus yang menandatangani ulang lalu lintas dengan root-nya sendiri. Mengirim root yang dipercaya klien tidak berbahaya, hanya tidak perlu.

Solusi: gunakan sertifikat dari CA publik untuk situs publik, atau pasang root privat di klien yang membutuhkannya. Tidak menyertakan root dalam rantai server memang rapi, tetapi tidak memperbaiki error ini.

Urutan Sertifikat Salah

Pesan error: verifikasi rantai gagal di beberapa klien, atau mereka melaporkan sertifikat tidak tepercaya.

Penyebab: sertifikat dalam file rantai berada dalam urutan yang salah. TLS 1.3 mewajibkan sertifikat server sendiri berada di urutan pertama dan sisanya berurutan, tetapi meminta klien tetap menangani urutan lain (RFC 8446 §4.4.2); klien yang lebih lama atau lebih ketat mungkin tidak bisa.

Solusi: letakkan sertifikat leaf di urutan pertama, lalu setiap intermediate, dimulai dari yang menandatangani leaf Anda.

Sertifikat Kedaluwarsa dalam Rantai

Pesan error: "certificate has expired" — padahal tanggal kedaluwarsa sertifikat leaf Anda tampak normal.

Penyebab: sebuah sertifikat yang lebih tinggi dalam rantai sudah kedaluwarsa. Kasus yang paling terkenal: DST Root CA X3 milik IdenTrust, yang menandatangani silang root Let's Encrypt, kedaluwarsa pada 30 September 2021, dan perangkat yang tidak memercayai ISRG Root X1 (serta klien dengan OpenSSL 1.0.x) mulai gagal di situs Let's Encrypt.

Solusi: unduh intermediate terbaru dari CA Anda dan ganti yang lama. Lalu gunakan SSL Checker kami untuk memverifikasi rantai yang sudah diperbarui.

Praktik Terbaik Rantai Sertifikat

• Selalu kirim intermediate — jangan berharap browser memperbaiki rantai; aplikasi dan klien API tidak akan melakukannya.
• Root bersifat opsional — klien memakai salinannya sendiri, jadi mengirim root yang sudah mereka percaya hanya menambah byte; root yang ditandatangani silang untuk perangkat lama adalah pengecualian yang disengaja.
• Jaga urutan — leaf dulu, lalu intermediate dari yang menandatangani leaf Anda ke atas.
• Otomatiskan perpanjangan — sertifikat yang diterbitkan sejak Maret 2026 berlaku paling lama 200 hari, turun menjadi 100 pada Maret 2027, dan Let's Encrypt beralih ke sertifikat 64 hari pada Februari 2027.
• Periksa setelah setiap perpanjangan atau pemindahan — CA bisa mengganti intermediate di antara perpanjangan. Setelahnya, jalankan situs melalui SSL Checker.
• Perhatikan setiap nama — www, domain utama, dan tiap subdomain bisa dilayani oleh sertifikat dan rantai yang berbeda. Subdomain Finder mencantumkan nama yang pernah dicakup sertifikat Anda, dari log sertifikat publik.