Log Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit
Sertifikat TLS yang dipercaya publik dapat valid menurut PKI tetapi tetap tidak diharapkan oleh operator domain. Certificate authority dapat menerbitkan sertifikat setelah kompromi akun, kesalahan validasi, atau kegagalan lain pada jalur penerbitan. Validasi sertifikat biasa memeriksa chain, hostname, masa berlaku, signature, dan policy yang relevan. Pemeriksaan tersebut tidak memberi tahu operator bahwa ada sertifikat valid lain untuk nama yang sama.
Certificate Transparency (CT) menambahkan lapisan audit publik pada penerbitan sertifikat. Certificate authority mengirim sertifikat atau precertificate ke log publik append-only. Log mengembalikan Signed Certificate Timestamp (SCT), yaitu janji bahwa item yang dikirim akan dimasukkan dalam maximum merge delay yang ditetapkan log. Client dapat mewajibkan bukti CT yang sesuai sebagai bagian dari policy sertifikat, sementara operator domain dapat memantau log untuk nama yang mereka kelola.
CT tidak mencegah certificate authority mengambil keputusan penerbitan yang keliru. CT membuat penerbitan yang dipercaya publik lebih terlihat dan menyediakan bukti kriptografis agar konsistensi riwayat log dapat diperiksa.
Log memakai Merkle tree append-only
Log CT merepresentasikan entry dalam Merkle tree. Leaf mengikat material sertifikat yang dicatat, sedangkan parent hash menggabungkan child hash sampai satu tree root mengikat state tree saat ini.
entry A ---- hash A --\
+-- hash AB --\
entry B ---- hash B --/ \
+-- tree root
entry C ---- hash C --\ /
+-- hash CD --/
entry D ---- hash D --/Struktur ini mendukung proof yang ringkas. Inclusion proof menunjukkan bahwa entry tertentu berada dalam tree yang direpresentasikan oleh root tertentu. Consistency proof menunjukkan bahwa tree yang lebih baru merupakan perluasan append-only dari tree sebelumnya, bukan riwayat yang ditulis ulang.
Sifat kriptografis tersebut lebih sempit daripada pernyataan umum bahwa sebuah log selalu tepercaya. Log yang bermasalah atau berbahaya tetap dapat melakukan pelanggaran. Signed tree head, inclusion proof, consistency proof, dan observasi independen membuat riwayat yang bertentangan dapat terdeteksi ketika view yang relevan dibandingkan.
SCT adalah janji, bukan inclusion proof
Saat log menerima submission, log dapat mengembalikan SCT. SCT mengidentifikasi log serta mengikat timestamp dan data sertifikat yang dikirim di bawah signature log.
SCT merupakan bukti bahwa log berjanji memasukkan entry dalam maximum merge delay. SCT sendiri bukan bukti bahwa entry sudah dimasukkan. Inclusion kemudian dibuktikan terhadap state tree melalui inclusion proof atau jalur verifikasi yang setara.
Perbedaan ini penting secara operasional:
submission
|
v
SCT dikembalikan
|
| maximum merge delay
v
entry dimasukkan
|
v
inclusion dapat diperiksaMonitor yang hanya mengumpulkan SCT tanpa memeriksa state log setelahnya dapat melewatkan log yang menerima submission tetapi gagal memasukkannya sesuai janji.
CT menambah visibilitas di samping validasi sertifikat
Browser yang memvalidasi koneksi TLS tetap menjalankan pemeriksaan sertifikat biasa. Policy CT merupakan lapisan keputusan tambahan, bukan pengganti path validation, pencocokan hostname, mekanisme revocation, atau authorization aplikasi.
Gambaran client yang disederhanakan:
sertifikat server
|
+-- pemeriksaan chain dan signature
+-- pemeriksaan hostname dan masa berlaku
+-- policy CT yang berlaku
|
v
keputusan koneksiAturan enforcement CT yang tepat merupakan policy client dan dapat berubah secara independen dari protokol log. Operator server tidak seharusnya menganggap satu SCT menjamin penerimaan universal. Persyaratan client dapat mencakup log yang diterima, jumlah SCT, masa berlaku sertifikat, bentuk penyampaian, serta detail policy lain.
Monitoring mengubah catatan publik menjadi kontrol operasional
Sifat publik CT berguna ketika catatan tersebut diperiksa. Operator domain dapat memantau entry sertifikat untuk domain terdaftar dan subdomain yang relevan, lalu membandingkan penerbitan yang terlihat dengan inventory sertifikat yang disetujui organisasi.
Alert yang berguna memuat konteks untuk triage:
nama DNS yang terlihat
serial number sertifikat
issuer
not-before / not-after
identitas log
waktu pertama terlihat
kecocokan inventorySertifikat yang tidak dikenal tidak otomatis berbahaya. Sertifikat itu dapat berasal dari CDN yang sah, managed hosting, migrasi sertifikat, environment disaster recovery, atau layanan lain yang mendapat delegasi. Monitor perlu membandingkan observasi CT dengan catatan kepemilikan dan inventory deployment sebelum eskalasi.
Sebaliknya, sertifikat yang tercatat dalam inventory internal tidak otomatis aman hanya karena muncul di CT. CT mencatat penerbitan; CT tidak menyatakan bahwa private key terlindungi, deployment dikonfigurasi dengan benar, atau sertifikat masih diizinkan organisasi.
Eksposur nama merupakan bagian dari desain
Logging publik dapat mengekspos nama DNS yang terdapat dalam sertifikat. Hostname yang terlihat internal tetapi ditempatkan dalam sertifikat yang dipercaya publik dapat menjadi terlihat bagi pengamat log CT.
Ini bukan kebocoran rahasia akibat kesalahan sistem logging; auditabilitas publik memerlukan publikasi informasi sertifikat. Organisasi perlu memperlakukan nama yang dikirim untuk sertifikat publik sebagai metadata publik.
Pertimbangan tersebut masuk ke arsitektur sertifikat. Layanan yang harus menjaga penamaan internal tetap privat sebaiknya tidak bergantung pada sertifikat publik yang memuat label internal sensitif. Private PKI dan distribusi trust internal menyelesaikan persoalan berbeda dan tidak perlu dipublikasikan hanya untuk mendapat cakupan CT.
CT tidak menggantikan kontrol penerbitan
CT paling kuat sebagai mekanisme deteksi dan akuntabilitas. Kontrol preventif tetap diperlukan pada akun certificate authority, DNS, validasi domain, dan boundary deployment.
Kontrol yang berguna mencakup pembatasan akun CA, autentikasi kuat, API credential dengan scope sempit, perlindungan perubahan DNS, jalur validasi domain yang terdokumentasi, dan ownership yang jelas untuk renewal sertifikat. DNS Certification Authority Authorization (CAA) juga dapat membatasi certificate authority yang diizinkan menerbitkan sertifikat untuk domain, sesuai semantik pemrosesan CAA.
Lapisan tersebut menangani titik kegagalan berbeda:
CAA -> sinyal otorisasi penerbitan kepada CA
kontrol akun CA -> melindungi workflow penerbitan
CT -> catatan publik dan bukti audit
monitoring -> mendeteksi penerbitan tak terduga
validasi TLS -> pemeriksaan koneksi clientTidak ada satu lapisan yang menggantikan lapisan lainnya.
Respons memerlukan playbook penerbitan
Alert CT menjadi berguna ketika organisasi sudah memiliki jalur untuk menentukan apakah sertifikat tersebut memang diharapkan. Responder memerlukan akses ke data ownership domain, issuer yang disetujui, otomasi sertifikat, hubungan delegated hosting, dan deployment aktif.
Untuk sertifikat yang tidak diharapkan, investigasi dapat menetapkan siapa yang memintanya, metode validasi yang dipakai, apakah private key dikendalikan pihak yang disetujui, dan apakah sertifikat sedang aktif. Jika penerbitan tidak sah, respons dapat mencakup revocation, perbaikan akun CA, perbaikan DNS atau jalur validasi, rotasi credential bila relevan, serta pemeriksaan sertifikat terkait.
CT dapat menampilkan sertifikat, tetapi tidak dapat mencabutnya atau memperbaiki jalur penerbitan. Deteksi harus terhubung dengan kewenangan operasional.
Auditabilitas mengubah failure model PKI
Sebelum logging sertifikat publik, sertifikat yang salah terbit dapat sulit terlihat oleh operator domain yang terdampak kecuali muncul dalam traffic, telemetry, atau investigasi terpisah. CT membuat catatan bersama yang dapat diperiksa monitor tanpa kerja sama dari pemegang sertifikat yang menerima sertifikat tersebut.
Hasilnya bukan pencegahan sempurna. CT membentuk boundary akuntabilitas yang lebih ketat: penerbitan sertifikat yang dipercaya publik meninggalkan bukti pada log yang dapat diamati secara independen, konsistensi append-only dapat diperiksa, dan operator domain dapat membandingkan catatan publik itu dengan state otorisasi internal.
Boundary tersebut bernilai karena tidak mengasumsikan setiap pihak dalam jalur penerbitan akan mendeteksi kesalahannya sendiri.
Referensi
- RFC 9162, Certificate Transparency Version 2.0: https://www.rfc-editor.org/rfc/rfc9162
- RFC 6962, Certificate Transparency: https://www.rfc-editor.org/rfc/rfc6962