Chain SSL Adalah: Isi Rantai, CA Bundle & Cara Ceknya

Ikon gembok di address bar sebuah halaman HTTPS hanya punya dua kondisi bagi pengunjung: ada atau tidak. Di belakangnya, browser menjalankan pemeriksaan yang jauh lebih bertingkat daripada sekadar "valid atau tidak". Browser tidak mengenal domain Anda dan tidak punya alasan mempercayai sertifikatnya. Yang ia percayai hanyalah sekumpulan lembaga penerbit yang sudah ditanam di sistem operasi sejak perangkat itu dijual.

Persoalannya, sertifikat website Anda hampir tidak pernah ditandatangani langsung oleh lembaga tersebut. Ada satu atau beberapa perantara di tengah, dan perantara itulah yang harus Anda kirimkan sendiri. Rangkaian sertifikat yang menjembatani keduanya inilah yang disebut chain SSL, dan di situ letak sebagian besar kasus SSL yang "sudah dipasang tapi masih bermasalah". Artikel ini membahas apa isinya, kenapa panjangnya sering berbeda dari yang digambarkan diagram, dan bagaimana memeriksa punya Anda sendiri dengan satu perintah.

Apa Itu Chain SSL?

Chain SSL adalah rangkaian sertifikat digital yang menghubungkan sertifikat website Anda dengan sebuah sertifikat akar yang sudah dipercaya perangkat pengunjung. Istilah lain yang sering dipakai untuk konsep yang sama adalah chain of trust (rantai kepercayaan) atau certificate chain. Setiap sertifikat dalam rantai menjamin sertifikat di bawahnya, sampai jaminan itu berhenti di titik yang tidak perlu dijamin siapa pun lagi.

Titik terakhir itu disebut trust anchor (jangkar kepercayaan), dan ia tersimpan di trust store. Trust store adalah daftar sertifikat akar bawaan sistem operasi, browser, atau runtime bahasa pemrograman. Windows, Android, macOS, dan Firefox masing-masing punya daftar sendiri, dan isinya tidak identik.

Kenapa harus ada perantara sama sekali? Karena kunci privat sebuah sertifikat akar terlalu berharga untuk dipakai sehari-hari. Otoritas sertifikat menyimpannya offline di dalam perangkat kriptografi terkunci, menyalakannya hanya pada upacara penandatanganan terjadwal untuk menerbitkan sertifikat perantara, lalu menguncinya kembali.

Susunan bertingkat ini sekaligus memberi jalan keluar saat terjadi insiden. Kalau kunci perantara bocor, otoritas cukup mencabut perantara itu dan menerbitkan yang baru. Akar tetap utuh, dan tidak ada perangkat di dunia yang perlu diperbarui.

Tiga Peran di Dalam Rantai Sertifikat

Rantai mana pun tersusun dari tiga peran. Yang sering tertukar bukan namanya, melainkan siapa yang bertanggung jawab mengirimkannya.

1. Sertifikat root (akar): milik otoritas penerbit dan lazim disebut root CA, satu-satunya sertifikat yang menandatangani dirinya sendiri (self-signed). Ia tidak dibuktikan pihak mana pun; ia dipercaya karena sudah ditanam di perangkat pengunjung. Karena itu Anda tidak perlu mengirimnya, dan mengirimnya pun tidak menambah keamanan apa pun.
2. Sertifikat intermediate (perantara): diterbitkan oleh root, dan bertugas menerbitkan sertifikat pelanggan. Perantara inilah yang wajib Anda kirim, karena perangkat pengunjung tidak menyimpannya. Satu rantai bisa memuat lebih dari satu perantara.
3. Sertifikat domain: sering disebut leaf atau end-entity certificate, satu-satunya sertifikat yang mencantumkan nama domain Anda. Ini yang Anda pesan, dan ia harus selalu berada paling atas dalam berkas yang dikirim server.

Aturan praktisnya cukup satu kalimat: root sudah ada di perangkat pengunjung, sertifikat domain Anda punya sendiri, dan yang di tengah adalah tanggung jawab Anda untuk melengkapi. Hampir semua kasus "chain issues" berakar pada lapis tengah yang tertinggal.

Tiga peran chain SSL: sertifikat domain ditandatangani perantara, perantara oleh akar, akar oleh dirinya sendiri.

Pembagian ini juga menjelaskan kenapa memasang sertifikat SSL bukan sekadar menempelkan satu berkas. Yang Anda terima dari penerbit umumnya beberapa berkas sekaligus, dan salah satunya berisi perantara tersebut.

Kenapa Chain SSL Anda Mungkin Berisi Empat Sertifikat

Gambaran tiga kotak bertingkat memang mudah diingat, tetapi ia bukan bentuk yang paling sering ditemui di lapangan. Pada 7 September 2026 kami memeriksa rantai yang benar-benar dikirim 20 situs Indonesia: hosting, bank, e-commerce, media, dan instansi pemerintah. Sembilan belas di antaranya berhasil diukur.

Hasilnya: rata-rata server mengirim 3,0 sertifikat. Sebanyak 58% mengirim tiga, tetapi 21% mengirim empat dan 21% lainnya hanya dua. Jadi angka tiga memang lazim, hanya saja ia bukan aturan.

Yang lebih menarik ada di ujung rantai. Pada 47% situs yang diukur, sertifikat paling bawah bernama "Root" tetapi bukan trust anchor. Kalau kolom penerbitnya dibaca, sertifikat itu ternyata masih ditandatangani akar lain. Penyebabnya adalah cross-signing (penandatanganan silang): sebuah akar baru ikut ditandatangani akar lama yang sudah dipercaya luas, supaya perangkat lawas tetap menemukan jalur kepercayaan yang ia kenali.

Contoh yang bisa Anda verifikasi sendiri datang dari Let's Encrypt. Menurut halaman resmi mereka yang diperbarui 8 Juli 2026, rantai bawaan untuk sertifikat ECDSA sekarang berbentuk seperti ini:

sertifikat domain
  ← YE2
  ← Root YE
  ← ISRG Root X2
  ← ISRG Root X1   (jangkar di perangkat)

Empat sertifikat dikirim server, dan verifikasi berhenti di ISRG Root X1 yang tertanam di perangkat. Root YE baru dibuat 3 September 2025 dan belum masuk daftar akar tepercaya mana pun, sehingga ia harus menumpang jalur akar lama.

Chain SSL letsencrypt.org berisi empat sertifikat sampai ISRG Root X2; jangkarnya ISRG Root X1 di perangkat.

Konsekuensi praktisnya: jangan menilai kebenaran rantai dari jumlah sertifikatnya. Dua sampai empat sertifikat sama-sama wajar. Yang menentukan adalah apakah setiap sertifikat benar-benar menyambung ke penerbitnya, dan apakah ujungnya bertemu akar yang dikenal perangkat pengunjung.

Chain SSL dan CA Bundle: Konsep dan Berkasnya

Dua istilah ini sering dianggap sinonim, padahal keduanya berada di tingkat yang berbeda. Chain SSL adalah konsepnya — hubungan kepercayaan antar sertifikat. CA bundle adalah berkasnya — satu file teks berisi sertifikat perantara yang Anda tempelkan ke konfigurasi server atau ke kolom di panel hosting.

Isinya hanyalah beberapa blok sertifikat yang ditulis berurutan dalam satu berkas berformat PEM, sehingga bisa dibuka dengan penyunting teks biasa. Yang membingungkan justru penamaannya, karena tiap penerbit memakai konvensi sendiri:

Pada Apache, SSLCertificateFile menerima berkas gabungan sejak versi 2.4.8, sementara versi lawas memisahkannya lewat SSLCertificateChainFile.

Perhatikan baris ketiga. fullchain.pem sudah memuat isi cert.pem dan chain.pem, sehingga tidak perlu digabung lagi. Kekeliruan paling umum di Nginx justru sebaliknya: cert.pem yang dipasang, sehingga perantaranya tidak pernah ikut terkirim.

Berkas kunci privat tidak pernah menjadi bagian rantai dan tidak boleh keluar dari server. Penjelasan lengkapnya ada di artikel private key. Untuk pemasangan lewat panel, urutan pengisian kolomnya kami tulis terpisah di cara instalasi SSL certificate.

Urutan Sertifikat dan Aturan yang Berubah di TLS 1.3

Pertanyaan yang selalu muncul saat menyusun berkas: apakah root dulu atau sertifikat domain dulu? Jawabannya ada di spesifikasi protokolnya, bukan di kebiasaan vendor.

RFC 8446, dokumen resmi TLS 1.3, menetapkan bahwa sertifikat pengirim harus menempati posisi pertama. Setiap sertifikat berikutnya sebaiknya menandatangani sertifikat tepat sebelumnya, dan sertifikat yang merupakan trust anchor boleh dihilangkan dari rantai. Jadi urutannya menurun: sertifikat domain, lalu penerbitnya, lalu penerbit dari penerbitnya.

Derajat kewajibannya sendiri sempat berubah. Sebelum TLS 1.3, urutan itu wajib penuh — satu sertifikat yang salah tempat bisa memutus koneksi. TLS 1.3 menurunkannya menjadi anjuran, dan alasannya disebut langsung di dokumen tersebut: banyak server mengirim perantara lama dan baru sekaligus selama masa transisi, sebagian lagi memang salah konfigurasi, tetapi keduanya masih bisa divalidasi dengan benar.

Praktisnya, ini berarti dua hal sekaligus. Urutan yang keliru tidak selalu membuat website Anda tidak bisa dibuka di browser modern. Namun ia tetap dilaporkan sebagai Incorrect order oleh alat pemeriksa, dan tetap memutus koneksi pada klien lama yang masih memakai TLS 1.2 dengan pemeriksaan ketat. Menyusunnya dengan benar tidak sulit, jadi tidak ada alasan menyerahkannya pada toleransi klien.

Sertifikat Root Sebaiknya Tidak Ikut Dikirim

Alat pemeriksa seperti SSL Labs mengenal tiga keluhan tentang rantai: Incomplete bila perantaranya kurang, Incorrect order bila susunannya terbalik, dan Contains anchor bila sertifikat root ikut dikirim. Yang ketiga paling sering disalahpahami sebagai kesalahan berbahaya, padahal ia sama sekali tidak mengurangi keamanan.

Logikanya begini. Kalau perangkat pengunjung sudah punya root tersebut, kiriman Anda mubazir. Kalau perangkat itu belum punya, kiriman Anda tetap tidak menolong. Tidak ada klien yang mau mempercayai sertifikat akar hanya karena server yang sedang diperiksa mengirimkannya sendiri. Manfaatnya nol dalam kedua skenario, sementara biayanya nyata.

Biaya itu bisa diukur. Dari 19 situs yang kami periksa, 5 situs atau 26% ikut mengirim sertifikat root. Ukuran root yang terbuang berkisar 867 sampai 1.506 byte, dengan rata-rata 1.141 byte, atau setara 22 sampai 32 persen dari total ukuran rantai yang mereka kirim. Sebagai pembanding, rantai paling ramping dalam pengukuran ini hanya dua sertifikat dengan total 2.770 byte.

Chain SSL yang ikut mengirim akar rata-rata 4.621 byte; 1.141 byte di antaranya terbuang percuma.

Angka seribuan byte terdengar kecil, tetapi ia dikirim ulang di setiap koneksi baru, sebelum satu byte konten pun berpindah. Pada jaringan seluler berlatensi tinggi, tambahan itu ikut menentukan apakah rantainya muat dalam pengiriman pertama atau menunggu satu perjalanan bolak-balik lagi.

Chain Tidak Lengkap: Aman di Browser, Gagal di Aplikasi

Gejala berikut termasuk yang paling sering dilaporkan. Website terbuka normal di Chrome dengan gembok utuh. Namun aplikasi Android melempar SSLHandshakeException, skrip cron berhenti dengan curl: (60) SSL certificate problem, dan webhook dari penyedia pembayaran gagal terkirim. Semuanya menuju server yang sama.

Penyebabnya bukan kebetulan, melainkan perbedaan cara tiap klien menambal rantai yang bolong:

1. Chrome, Edge, dan Safari melakukan AIA fetching: sertifikat domain memuat ekstensi Authority Information Access berisi alamat unduhan penerbitnya. Bila perantara hilang, browser mengunduhnya diam-diam lalu melanjutkan verifikasi. Pengguna tidak melihat apa pun.
2. Firefox memuat perantara di muka: sejak Firefox 75, browser ini mengunduh seluruh sertifikat perantara yang terdaftar dari layanan Mozilla sekali sehari, lalu menyimpannya ke profil pengguna. Mozilla memilih cara ini dan menolak menerapkan AIA fetching, dengan alasan privasi dan kecepatan.
3. Sisanya tidak menambal apa pun: OpenSSL, curl yang dikompilasi dengan OpenSSL, Java dan Android, PHP cURL, Python requests, serta Node.js akan langsung menolak. Bagi mereka, rantai yang tidak lengkap berarti sertifikat tidak terverifikasi.

Kami menguji perbedaan ini pada incomplete-chain.badssl.com, sebuah server uji publik yang sengaja hanya mengirim satu sertifikat. Dengan daftar akar yang bersih, OpenSSL menolaknya secara konsisten:

verify error:num=20:
unable to get local issuer certificate
verify error:num=21:
unable to verify the first certificate
Verify return code: 21

Baris di atas dibungkus agar muat di layar ponsel; aslinya verify error:num=20 dan pesannya berada pada satu baris yang sama.

Diulang tiga kali, hasilnya identik. Pada saat yang sama, halaman itu terbuka mulus di browser. Pegang kesimpulannya: lolos di browser bukan bukti rantai Anda benar. Browser adalah penguji paling pemaaf, dan karena itu paling buruk dijadikan alat verifikasi.

Chain SSL tidak lengkap: Chrome dan Firefox tetap membuka halaman, OpenSSL dan Android menolak koneksi.

Cara Mengecek Chain SSL Website Anda

Ada tiga tingkat pemeriksaan, dari yang paling cepat sampai yang paling teliti. Semuanya memakai OpenSSL yang sudah tersedia di hampir semua Linux dan macOS.

Pertama, lihat persis apa yang dikirim server Anda:

echo | openssl s_client -showcerts \
  -connect namadomain.com:443 \
  -servername namadomain.com

Perhatikan blok Certificate chain di awal keluaran. Angka di depan tiap pasangan baris adalah depth atau kedalaman: 0 selalu sertifikat domain Anda, 1 penerbitnya, dan seterusnya naik ke arah akar. Baris s: berarti subject, yaitu pemilik sertifikat itu. Baris i: berarti issuer, yaitu penerbitnya. Rantai Anda benar bila nilai i: pada satu baris sama persis dengan nilai s: pada baris berikutnya. Kalau rantainya putus di tengah, atau nomor terakhir memiliki s: dan i: yang identik, Anda menemukan masalahnya.

Kedua, buktikan rantai benar-benar tersambung tanpa bergantung pada browser. Simpan sertifikat domain sebagai leaf.pem dan perantaranya sebagai chain.pem, lalu jalankan:

openssl verify -untrusted chain.pem leaf.pem

Keluaran leaf.pem: OK berarti rantai lengkap. Tanpa berkas perantara, OpenSSL membalas error 20 at 0 depth lookup: unable to get local issuer certificate. Pesan itu persis sama dengan yang dilihat aplikasi mobile saat rantai Anda bolong.

Ketiga, baca isi CA bundle sebelum dipasang, supaya Anda tahu berkas itu berisi apa:

openssl crl2pkcs7 -nocrl -certfile chain.pem \
  | openssl pkcs7 -print_certs -noout

Perintah ini mencetak pasangan subject dan issuer setiap blok, tanpa memuntahkan isi sertifikatnya. Jauh lebih cepat daripada membuka berkas dan menebak dari deretan karakter acak.

Tanpa akses terminal, layanan publik SSL Labs memberi informasi yang sama lewat browser, lengkap dengan label Chain issues yang sudah dibahas di atas.

Memperbaiki Chain SSL yang Tidak Lengkap

Hampir semua kasus rantai bolong berujung pada satu sebab: berkas yang dipasang di direktif sertifikat hanya berisi sertifikat domain. Perbaikannya menyesuaikan tempat pemasangan.

Langkah #1: Pastikan Berkas yang Ditunjuk Sudah Lengkap

Pada Nginx, direktif ssl_certificate harus menunjuk berkas yang memuat sertifikat domain beserta perantaranya. Nginx tidak menggabungkannya sendiri.

ssl_certificate /etc/ssl/situs/fullchain.pem;
ssl_certificate_key /etc/ssl/situs/privkey.pem;

Certbot menaruh kedua berkas itu di /etc/letsencrypt/live/[nama-domain]/, jadi sesuaikan jalurnya dengan lokasi di server Anda.

Menunjuk cert.pem di baris pertama adalah penyebab paling sering rantai tidak lengkap pada Nginx, karena konfigurasinya tetap valid dan server tetap menyala tanpa keluhan.

Langkah #2: Sesuaikan dengan Versi Apache Anda

Apache 2.4.8 ke atas membaca seluruh rantai dari SSLCertificateFile, jadi berkas gabungan seperti fullchain.pem sudah cukup. Direktif SSLCertificateChainFile dinyatakan usang sejak versi tersebut dan sebaiknya tidak lagi dipakai. Pada Apache yang lebih lawas, perantara wajib ditunjuk terpisah lewat direktif lama itu.

Langkah #3: Isi Kolom CA Bundle di Panel Hosting

Panel seperti cPanel menyediakan tiga kolom terpisah: Certificate, Private Key, dan Certificate Authority Bundle. Kolom ketiga inilah yang sering ditinggal kosong karena terlihat opsional. Untuk sertifikat yang dipesan lewat penyedia hosting, kolom ini umumnya terisi otomatis. Untuk sertifikat SSL yang dibeli terpisah, isinya harus Anda tempelkan sendiri dari berkas yang dikirim penerbit.

Langkah #4: Muat Ulang Layanan, Lalu Verifikasi Ulang

Jalankan nginx -s reload atau systemctl reload apache2, lalu ulangi perintah openssl s_client dari bagian sebelumnya. Jumlah sertifikat dalam blok Certificate chain harus bertambah. Memeriksa lewat browser tidak cukup, karena ia sudah menyimpan perantara yang sempat diunduhnya sendiri.

Bila berkas perantaranya hilang, unduh ulang dari halaman repositori resmi otoritas penerbit. Jangan menyalinnya dari forum atau blog. Satu karakter yang salah membuat berkas gagal dibaca, dan perantara yang keliru versinya menghasilkan rantai yang tidak tersambung.

Hal yang Perlu Anda Pertimbangkan

Rantai sertifikat bukan pengaturan yang bisa disetel sekali lalu dilupakan. Tiga hal berikut layak masuk pertimbangan.

1. Rantai yang lebih panjang berarti data lebih banyak: setiap sertifikat tambahan menambah ratusan sampai ribuan byte pada pembukaan koneksi, ditambah satu langkah verifikasi tanda tangan. Sertifikat berbasis ECDSA jauh lebih ringkas daripada RSA — dalam pengukuran kami, rantai ECDSA empat tingkat justru lebih kecil daripada rantai RSA tiga tingkat.
2. Sertifikat perantara berotasi tanpa memberi tahu Anda: otoritas mengganti perantaranya secara berkala, dan yang lama akhirnya kedaluwarsa. CA bundle yang disalin manual sekali lalu ditinggalkan akan basi pada perpanjangan berikutnya, dengan gejala yang persis sama seperti rantai bolong.
3. Masa berlaku sertifikat sedang dipersingkat drastis: Baseline Requirements CA/Browser Forum sudah memangkas batas maksimum menjadi 200 hari sejak 15 Maret 2026. Angka itu turun lagi menjadi 100 hari pada 15 Maret 2027, lalu 47 hari pada 15 Maret 2029. Pemasangan manual yang dulu setahun sekali kini menjadi urusan tiap beberapa bulan.

Poin ketiga adalah alasan paling kuat untuk menyerahkan urusan ini pada otomasi. Klien ACME seperti Certbot mengambil sertifikat sekaligus perantaranya, menuliskannya ke fullchain.pem, dan memuat ulang layanan tanpa campur tangan Anda. Rantai yang dibangun otomatis jarang salah susun, karena tidak ada yang menyalin dan menempel secara manual.

Pertanyaan Seputar Chain SSL

Apa beda fullchain.pem dan chain.pem?

chain.pem berisi sertifikat perantara saja, sedangkan fullchain.pem berisi sertifikat domain diikuti seluruh perantaranya. Untuk Nginx dan Apache modern, pakai fullchain.pem. Menggabungkan keduanya menghasilkan sertifikat domain yang tercatat dua kali.

Berapa jumlah sertifikat yang wajar dalam satu chain?

Dua sampai empat, dengan tiga sebagai yang paling umum. Jumlahnya tidak menentukan benar atau salah; yang menentukan adalah apakah setiap sertifikat menyambung ke penerbitnya dan berakhir di akar yang dikenal perangkat pengunjung.

Apakah "contains anchor" harus segera diperbaiki?

Tidak mendesak, karena ia tidak mengurangi keamanan dan tidak menurunkan nilai pemeriksaan SSL Labs. Namun memperbaikinya memangkas sekitar seribu byte dari setiap pembukaan koneksi, dan pekerjaannya hanya menghapus satu blok sertifikat terakhir dari berkas.

Urutannya dari root dulu atau sertifikat domain dulu?

Sertifikat domain selalu paling atas, lalu turun ke arah akar. Menaruh root di posisi pertama adalah kesalahan susunan yang paling sering terjadi saat berkas digabung manual dengan penyunting teks.

Kenapa SSL saya normal di Chrome tapi error di aplikasi Android?

Karena Chrome mengunduh sendiri perantara yang hilang lewat AIA fetching, sementara pustaka jaringan Android tidak melakukannya. Gejala ini hampir selalu menandakan rantai yang tidak lengkap, dan bisa dipastikan dengan perintah openssl s_client.

Apa yang terjadi kalau sertifikat perantara di rantai kedaluwarsa?

Website Anda ikut ditolak, meskipun sertifikat domainnya masih jauh dari tanggal kedaluwarsa. Verifikasi memeriksa masa berlaku setiap sertifikat dalam rantai, bukan hanya yang paling atas. Kasus paling terkenal terjadi pada 30 September 2021, ketika sertifikat DST Root CA X3 habis masa berlakunya dan menumbangkan banyak perangkat lama sekaligus. Periksa tanggal tiap lapis dengan openssl s_client -showcerts, lalu perbarui berkas perantaranya.

Apakah SSL gratis punya struktur chain yang sama dengan yang berbayar?

Ya, mekanismenya identik — keduanya sama-sama memakai sertifikat perantara dan berakhir di akar yang tertanam di perangkat. Yang membedakan hanya tingkat validasi identitas pemilik domain, bukan cara rantainya dibangun atau diverifikasi.

Kesimpulan

Chain SSL adalah rantai kepercayaan yang menghubungkan sertifikat domain Anda dengan akar yang sudah dipercaya perangkat pengunjung. Dari seluruh rantai itu, hanya lapis perantara yang menjadi tanggung jawab Anda untuk mengirim. Panjang yang wajar berada di angka dua sampai empat sertifikat, root tidak perlu disertakan, dan urutannya selalu dimulai dari sertifikat domain.

Satu hal yang paling layak dibawa pulang: gembok hijau di browser bukan bukti rantai Anda benar. Chrome dan Firefox menambal rantai yang bolong dengan caranya masing-masing, sementara aplikasi mobile dan skrip server tidak. Sempatkan menjalankan openssl s_client -showcerts sekali setiap kali sertifikat diperbarui, dan bandingkan baris s: dengan i: di bawahnya. Semoga artikel ini membantu.