TLS Must-Staple Menjadikan OCSP Stapling sebagai Policy Sertifikat
OCSP stapling memungkinkan server TLS mengirim bukti status sertifikat di dalam handshake sehingga setiap client tidak perlu menghubungi OCSP responder milik certificate authority. Susunan ini mengurangi satu dependency jaringan tambahan di sisi client, tetapi stapling biasa bersifat opsional: ketiadaan response yang di-staple tidak dengan sendirinya membuktikan bahwa sertifikat tidak valid.
Ekstensi X.509 TLS Feature mengubah kondisi tersebut ketika mengiklankan status_request. Dalam penggunaan ini mekanismenya umum disebut Must-Staple. Sertifikat menyatakan bahwa server diharapkan menyediakan TLS feature terkait. Client yang meminta feature tersebut sekaligus menerapkan ekstensi sertifikat dapat menolak koneksi ketika response status yang diwajibkan tidak tersedia.
Batasnya spesifik. OCSP menyediakan informasi status sertifikat. TLS membawa salinan informasi tersebut sebagai staple. Ekstensi sertifikat menjadikan kehadiran feature yang dinegosiasikan sebagai persyaratan validasi bagi client yang mendukungnya.
Status OCSP dan stapling berada pada layer berbeda
OCSP mendefinisikan response bertanda tangan mengenai status sertifikat. Response dapat menyatakan good, revoked, atau unknown, sesuai semantik response dan aturan validasi protokol. Response dibuat oleh OCSP responder yang berwenang; server TLS tidak membuat signature milik responder.
Stapling mengubah cara pengiriman. Server memperoleh response OCSP lalu menyertakannya dalam TLS ketika client meminta status sertifikat.
CA / OCSP responder
|
| response status bertanda tangan
v
server TLS
|
| response di-staple
v
clientClient tetap memvalidasi response OCSP. Memindahkan pengiriman ke TLS tidak menjadikan server sebagai otoritas status, dan tidak membuat data status yang kedaluwarsa, malformed, atau tidak dapat diterima menjadi valid.
Pada TLS 1.3, informasi OCSP dibawa dalam ekstensi status_request pada CertificateEntry terkait. Versi TLS sebelumnya memakai mekanisme certificate-status yang ditetapkan untuk versi tersebut. Detail transport berbeda, tetapi peran dasarnya tetap sama: bukti status menyertai pertukaran sertifikat.
Stapling opsional membuat ketiadaan response ambigu
Client dapat mengiklankan status_request untuk meminta informasi OCSP yang di-staple. Tanpa sinyal policy tambahan, staple yang tidak ada dapat berasal dari beberapa kondisi operasional. Server mungkin tidak mendukung stapling, belum memiliki response yang dapat dipakai, atau dikonfigurasi untuk tidak mengirimkannya.
Ambiguitas ini berpengaruh pada policy revocation. Client tidak dapat menganggap ketiadaan staple sebagai bukti bahwa sertifikat telah dicabut. Sebaliknya, policy yang selalu menerima response yang hilang tidak dapat menjadikan stapling sebagai persyaratan ketat.
RFC 7633 mendefinisikan ekstensi X.509 TLS Feature untuk mengikat ekspektasi TLS feature tertentu pada sertifikat. Untuk feature status_request, sertifikat dapat memberi sinyal bahwa informasi status diharapkan ketika client meminta feature tersebut.
Secara konseptual:
sertifikat:
TLS Feature = status_request
client:
meminta status_request
server:
harus memenuhi feature sertifikat yang dimintaSifat ini lebih kuat daripada preferensi konfigurasi server karena persyaratan tersebut ikut dibawa oleh sertifikat yang disajikan untuk validasi.
Enforcement bergantung pada sertifikat dan perilaku client
Must-Staple tidak membuat semua client TLS mengambil tindakan yang sama. Perilaku yang relevan bergantung pada dukungan client terhadap TLS feature, apakah client memintanya, apakah ekstensi sertifikat diproses, serta semantik validasi yang diterapkan.
RFC 7633 mewajibkan server yang menyajikan sertifikat dengan ekstensi TLS Feature untuk mendukung feature yang ditentukan. RFC tersebut juga menetapkan perilaku validasi client ketika feature yang terdapat pada request client sekaligus ekstensi sertifikat tidak ditawarkan oleh server.
Cakupan ini mencegah klaim berlebihan terhadap istilah Must-Staple: sertifikat tidak secara mandiri memaksa software arbitrer untuk mengimplementasikan OCSP atau pemrosesan certificate feature. Client yang tidak mengimplementasikan mekanisme tersebut tidak memperoleh enforcement hanya dari keberadaan ekstensi.
Bagi software yang menerapkannya, ekstensi ini menghapus ambiguitas normal ketika negotiated staple tidak tersedia. Ketiadaan response menjadi kegagalan validasi sertifikat, bukan alasan untuk melanjutkan koneksi seolah stapling tidak pernah diminta.
Staple yang valid memiliki batas waktu sendiri
Mewajibkan staple tidak berarti satu response OCSP dapat disimpan tanpa batas. Response OCSP berisi data status bertanda tangan dengan field waktu yang dievaluasi client sesuai aturan pemrosesan OCSP dan policy lokal.
Server karena itu memiliki siklus refresh operasional:
ambil response
|
v
cache staple yang dapat dipakai
|
v
layani handshake TLS
|
v
refresh sebelum tidak dapat dipakaiJika refresh gagal cukup lama hingga tidak ada response yang dapat diterima, server dengan sertifikat Must-Staple dapat memasuki kondisi fail-closed bagi client yang menerapkannya. Sertifikat mungkin masih berada dalam interval validitas X.509, tetapi bukti status yang diwajibkan tidak tersedia atau tidak dapat diterima.
Keterikatan ini memang disengaja. Deployment yang meminta client menolak status yang hilang harus mengoperasikan pengambilan status sebagai bagian dari penyajian sertifikat, bukan maintenance latar belakang yang opsional.
Penggantian sertifikat memerlukan kesiapan status
Sertifikat baru dapat menimbulkan masalah urutan yang singkat tetapi penting. Server mungkin sudah memiliki sertifikat dan private key sebelum response OCSP yang dapat diterima untuk sertifikat tersebut tersedia.
RFC 7633 menyarankan server tidak mulai memakai sertifikat pengganti yang memuat ekstensi TLS Feature sampai token status OCSP yang diperlukan tersedia. Urutan ini mencegah server menyajikan sertifikat yang policy-nya sendiri belum dapat dipenuhi.
Transisi state yang praktis:
sertifikat baru diterbitkan
|
v
ambil response OCSP yang dapat dipakai
|
v
aktifkan sertifikat + staple
|
v
refresh status secara berkelanjutanKondisi yang sama berlaku pada sebuah fleet. Jika deployment sertifikat mencapai endpoint sebelum material status atau konfigurasi stapling yang sesuai, client yang menerapkan feature dapat menolak endpoint tersebut meskipun node lain beroperasi dengan benar.
Must-Staple tidak menggantikan infrastruktur revocation
Ekstensi TLS Feature tidak menentukan apakah sertifikat telah dicabut. Ekstensi ini menetapkan persyaratan mengenai TLS feature yang terkait dengan validasi credential. Dalam kasus ini, OCSP tetap menjadi mekanisme yang membawa pernyataan status sertifikat.
Ekstensi ini juga tidak menghilangkan kebutuhan terhadap OCSP responder. Stapling memindahkan kontak dengan responder dari setiap client ke sisi server, tetapi server tetap membutuhkan sumber response status yang baru. Availability, caching, waktu refresh, dan otorisasi responder tetap menjadi bagian dari desain operasional.
Must-Staple juga tidak memperbaiki certificate mis-issuance dengan sendirinya. Mekanisme seperti Certificate Transparency dan CAA menangani bagian berbeda dari lifecycle PKI. Keduanya dapat berjalan bersama status revocation yang di-staple tanpa menjadi penggantinya.
Sertifikat membentuk komitmen availability
Menambahkan status_request ke ekstensi TLS Feature mengubah deployment sertifikat dari “kirim staple jika tersedia” menjadi kontrak yang lebih kuat bagi client yang menerapkan feature. Kontrak tersebut meluas dari konfigurasi TLS ke penerbitan sertifikat, pengambilan response OCSP, refresh cache, urutan rollout, dan penanganan kegagalan.
Properti keamanan yang dihasilkan bersifat spesifik: client yang menerapkan mekanisme dan meminta feature yang diiklankan tidak perlu memperlakukan staple yang hilang sebagai perilaku opsional biasa. Client dapat menolak credential karena feature yang diwajibkan sertifikat tidak diberikan.
Ketepatan tersebut membawa biaya operasional. Site yang memakai Must-Staple harus menjaga bukti status yang dapat diterima tetap tersedia di setiap tempat sertifikat disajikan. Ekstensi ini paling berguna ketika persyaratan availability tersebut diperlakukan sebagai bagian dari lifecycle sertifikat itu sendiri.
Referensi
- IETF, RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions: https://www.rfc-editor.org/rfc/rfc6066
- IETF, RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP: https://www.rfc-editor.org/rfc/rfc6960
- IETF, RFC 7633: X.509v3 Transport Layer Security (TLS) Feature Extension: https://www.rfc-editor.org/rfc/rfc7633
- IETF, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3: https://www.rfc-editor.org/rfc/rfc8446