Certificate Transparency Membuat Penerbitan Sertifikat TLS Dapat Diaudit

Sertifikat TLS yang dipercaya publik dapat valid secara kriptografis tetapi tetap merupakan sertifikat yang tidak pernah diminta operator domain. Validasi sertifikat membentuk chain ke certification authority yang dipercaya dan memeriksa sertifikat terhadap policy client. Proses itu sendiri tidak memberi operator domain catatan global atas seluruh sertifikat yang diterbitkan untuk namanya.

Certificate Transparency (CT) menambahkan lapisan visibilitas tersebut. Log publik menerima sertifikat atau precertificate, membuat komitmen untuk mencatatnya, lalu menyediakan riwayat append-only yang dapat diperiksa monitor. Mekanisme ini tidak menghentikan certification authority yang menerbitkan sertifikat bermasalah. CT membuat penerbitan dapat diamati dan memberi client dasar untuk meminta bukti bahwa sertifikat telah diserahkan ke log yang diterima.

SCT adalah komitmen dari log

Ketika CT log menerima submission yang valid, log mengembalikan Signed Certificate Timestamp (SCT). SCT mengidentifikasi log, membawa timestamp, dan memuat signature yang dibuat log tersebut.

Secara konseptual:

sertifikat atau precertificate
          |
          v
       CT log
          |
          v
  komitmen bertanda tangan
          (SCT)

SCT bukan sertifikat dan bukan pengganti validasi certificate chain. SCT adalah bukti bahwa sebuah log tertentu berkomitmen memasukkan entry yang diserahkan sesuai parameter log tersebut.

RFC 9162 mendefinisikan Maximum Merge Delay (MMD). Setelah menerbitkan SCT, log yang sesuai spesifikasi harus memasukkan entry terkait ke Merkle tree dalam batas waktu tersebut. Pemisahan ini membedakan komitmen bertanda tangan yang tersedia segera dari verifikasi berikutnya bahwa entry yang dijanjikan benar-benar muncul di log.

Sifat append-only berasal dari Merkle tree

CT log direpresentasikan sebagai Merkle tree. Leaf entry mengikat material sertifikat yang dicatat, sedangkan parent hash menggabungkan hash di bawahnya sampai sebuah root hash merepresentasikan keadaan tree.

        root
       /    \
     h01    h23
    /  \   /  \
   h0  h1  h2  h3

Struktur ini mendukung dua pemeriksaan penting. Inclusion proof dapat menunjukkan bahwa entry tertentu merupakan bagian dari tree yang direpresentasikan sebuah root. Consistency proof dapat menunjukkan bahwa tree yang lebih baru memperluas tree lama tanpa menulis ulang entry lama.

Properti tersebut penting karena transparency log yang berguna tidak boleh diam-diam mengubah riwayat setiap kali sertifikat yang tidak diinginkan muncul. Proof kriptografis membuat bentuk mutasi tertentu dapat dideteksi auditor yang menyimpan dan membandingkan keadaan tree.

Model ini tetap memiliki batas. RFC 9162 mencatat bahwa log berbahaya dapat mencoba menyajikan view yang tidak konsisten kepada pihak berbeda. Karena itu CT tetap bergantung pada auditing, monitoring, dan mekanisme yang membandingkan keadaan log yang diamati; Merkle tree saja tidak membuat operator log otomatis dapat dipercaya.

Pencatatan tidak membuktikan penerbitan yang sah

Sertifikat yang tercatat tidak otomatis sah. CT merekam aktivitas penerbitan; CT tidak menentukan apakah pemohon memang berhak menerima sertifikat.

Perbedaannya mendasar:

sertifikat tercatat
        !=
sertifikat diotorisasi pemilik domain

Sertifikat yang salah terbit dapat tetap berada di CT log. Keberadaannya membuat peristiwa tersebut terlihat oleh monitor, yang kemudian dapat memicu respons operasional seperti investigasi dan permintaan revocation. Log adalah infrastruktur bukti, bukan sumber keputusan otorisasi.

Validasi TLS normal juga tetap diperlukan. RFC 9162 memisahkan validasi SCT dari validasi server certificate beserta chain-nya. Client memerlukan pemeriksaan PKI yang diwajibkan trust policy sekaligus pemeriksaan kepatuhan CT yang ditetapkan policy terkait.

Precertificate membuka penerbitan sebelum sertifikat final

Certification authority dapat menyerahkan precertificate sebelum menerbitkan sertifikat TLS final. Log mengembalikan SCT untuk precertificate yang diterima, lalu CA dapat memakai bukti CT tersebut saat membentuk sertifikat yang diterbitkan.

Alur ini memasukkan partisipasi CT ke proses penerbitan sertifikat:

CA
 |
 +--> precertificate --> CT log
 |                        |
 |<--------- SCT ---------+
 |
 +--> sertifikat final

Precertificate bukan sekadar draft sertifikat sembarang. Spesifikasi CT menetapkan representasinya dan relasi entry tersebut dengan sertifikat final. Implementasi harus mempertahankan semantik itu, bukan memperlakukan precertificate sebagai objek X.509 apa pun yang dapat dipertukarkan.

Client memerlukan policy untuk bukti CT yang diterima

Memiliki SCT tidak cukup untuk memenuhi setiap policy client. Client harus dapat memvalidasi SCT memakai parameter log terkait, dan policy browser atau platform dapat menerapkan persyaratan tambahan mengenai log yang diterima serta bukti CT yang menyertai sertifikat.

Ini menjadi alasan operasional untuk membedakan protokol dari policy vendor. RFC 9162 menetapkan struktur protokol dan prosedur verifikasi. Program browser dan root store menentukan log yang diakui serta sertifikat mana yang harus memenuhi aturan CT mereka.

Pada Web PKI publik, perilaku browser saat ini menjadikan CT bagian dari deployment sertifikat normal. Operator server sebaiknya memperlakukan kegagalan CT sebagai kegagalan delivery sertifikat, bukan fitur reporting opsional.

Bukti CT dapat dibawa bersama deployment TLS

Informasi CT dapat dikirim melalui mekanisme yang terkait dengan sertifikat dan TLS handshake. Bergantung pada versi protokol dan generasi CT yang digunakan, bukti dapat ditanam dalam sertifikat X.509 atau dibawa melalui TLS maupun mekanisme status yang di-staple.

Menanam bukti dalam sertifikat sederhana secara operasional karena server TLS yang tidak diubah dapat menyajikan sertifikat sebagaimana diterbitkan. Mekanisme delivery dinamis memberi fleksibilitas lebih besar untuk memperbarui informasi CT tanpa menerbitkan ulang sertifikat.

Detailnya sensitif terhadap versi. RFC 9162 mengganti sejumlah struktur RFC 6962 dan mendefinisikan extension TLS transparency_info untuk CT v2. Deployment browser yang ada secara historis memakai format SCT dan policy era RFC 6962. Implementasi sebaiknya mengikuti protokol dan policy client yang benar-benar ditargetkan, bukan mencampur field dari kedua generasi.

Monitoring mengubah transparansi menjadi kontrol operasional

Nilai keamanan dari pencatatan publik muncul ketika ada pihak yang memantau log. Operator domain dapat memonitor certificate entry untuk nama yang dikelolanya lalu membandingkan penerbitan yang terlihat dengan lifecycle sertifikat yang diharapkan.

Alert yang berguna memerlukan konteks yang cukup untuk triage:

dns_name=api.example.com
issuer=Example CA
serial=...
not_before=...
log=...
observed_at=...
expected=false

Entry yang tidak diharapkan adalah sinyal, bukan bukti compromise. Penyebabnya dapat berupa renewal resmi yang terlewat dari inventory, delegated service, proses staging yang memakai nama produksi, atau misissuance nyata. Respons perlu mengorelasikan data CT dengan certificate inventory, catatan akun CA, catatan deployment, dan informasi ownership.

Monitoring juga memerlukan kontinuitas. Memeriksa log hanya saat renewal sertifikat menyisakan periode panjang ketika penerbitan tak terduga dapat luput. Collection dan alerting otomatis membuat catatan publik tersebut berguna pada skala waktu operasional.

CT melengkapi revocation dan kontrol penerbitan

Certificate Transparency tidak melakukan revocation, mengamankan akun CA, melindungi validasi DNS, atau membatasi siapa yang dapat meminta sertifikat. Kontrol tersebut menangani tahap berbeda dalam lifecycle sertifikat.

Program TLS publik yang tangguh menggabungkannya:

kontrol penerbitan -> mengurangi penerbitan tanpa otorisasi
monitoring CT      -> mengekspos penerbitan tak terduga
revocation         -> membatalkan sertifikat terdampak bila didukung
inventory          -> memetakan sertifikat ke owner dan deployment

CT paling kuat ketika diperlakukan sebagai audit plane di sekitar PKI, bukan sebagai pengganti PKI. Komitmen bertanda tangan dan log append-only menghasilkan bukti yang dapat diperiksa secara independen. Monitoring menghubungkan bukti itu dengan ownership domain, sementara validasi sertifikat dan revocation tetap memiliki peran terpisah dalam menentukan apakah credential TLS patut diterima.