Belajar PKI - Revocation: CRL & OCSP

#Pendahuluan

Di episode 5 sebelumnya kalian sudah berhasil membangun private CA, menerbitkan root certificate, dan mendistribusikannya ke trust store berbagai mesin. Sekarang semua mesin di lingkungan kalian percaya pada root CA tersebut. Tapi mari kita jujur: kepercayaan tanpa mekanisme pencabutan itu seperti pintu terkunci tanpa mekanisme darurat — sekali pintunya dibobol, tidak ada cara menutupnya kembali.

Kenyataannya, tidak semua sertifikat hidup sampai tanggal kedaluwarsanya. Kunci privat bisa bocor, karyawan bisa keluar dari perusahaan, atau sebuah service bisa dihentikan dan tidak boleh lagi diakses. Tanpa mekanisme untuk membatalkan sertifikat lebih awal, kalian terjebak menunggu waktu kedaluwarsa. Episode inilah yang menjawab masalah itu.

Di episode ini kita akan membahas dua standar pencabutan utama: CRL (Certificate Revocation List) dan OCSP (Online Certificate Status Protocol). Kalian akan belajar membangkitkan CRL dengan OpenSSL, mempublikasikannya lewat extension crl_distribution_points, menjalankan OCSP responder, menambahkan authority_info_access, sampai memahami OCSP Stapling dan apa yang terjadi ketika sertifikat revoked muncul di TLS handshake.

#Mengapa Sertifikat Harus Bisa Dicabut

Sertifikat diterbitkan dengan masa berlaku, misalnya 365 hari. Selama periode itu, semua pihak yang mempercayai CA akan mempercayai sertifikat tersebut. Masalahnya, kondisi nyata jarang seindah masa berlaku: kunci privat bisa dicuri dari server, karyawan yang menguasai key bisa pindah kerja, atau service lama yang dianggap sudah mati ternyata masih menerima koneksi. Dalam semua kasus itu, membiarkan sertifikat tetap berlaku sampai kedaluwarsa adalah risiko keamanan yang tidak perlu.

Revocation adalah mekanisme untuk menyatakan bahwa sebuah sertifikat tidak lagi bisa dipercaya sebelum masa berlakunya habis. Dua standar yang paling umum: CRL, daftar nomor seri sertifikat yang dicabut, dan OCSP, protokol untuk menanyakan status satu sertifikat secara real-time. Keduanya bergantung pada pemroses, yaitu pihak yang memverifikasi sertifikat, untuk benar-benar mengecek status sebelum memutuskan percaya.

Penting untuk disadari: tanpa pengecekan status, sertifikat revoked tetap diterima. Revocation hanya berguna jika pemroses mau repot menanyakannya. Karena itu, memahami cara kerja dan cara men-deploy kedua mekanisme ini adalah kunci pengamanan lingkungan kalian.

#CRL: Certificate Revocation List

CRL adalah dokumen berisi daftar nomor seri sertifikat yang sudah dicabut, ditandatangani oleh CA, dan dipublikasikan di lokasi yang bisa diakses klien. Saat pemroses menemukan nomor seri sertifikat ada di dalam daftar, koneksi ditolak. CRL bisa memuat alasan pencabutan seperti keyCompromise, certificateHold, atau superseded, yang membantu operasi memahami kenapa sebuah sertifikat dicabut.

#Membangkitkan CRL dengan OpenSSL

OpenSSL memudahkan pembangkitan CRL. Alur yang paling umum: cabut sertifikatnya dulu, baru bangkitkan CRL-nya. Perintah openssl ca -revoke menandai sebuah sertifikat sebagai revoked di database CA, dan openssl ca -gencrl menghasilkan CRL terbaru dari database tersebut.

revoke-and-gencrl.sh

openssl ca -config openssl-ca.cnf \
  -revoke certs/api-server.crt \
  -crl_reason keyCompromise
openssl ca -config openssl-ca.cnf \
  -gencrl -out crl/root-ca.crl

Perhatikan bahwa -crl_reason menandakan alasan pencabutan. Setelah CRL dibuat, kalian bisa memeriksanya untuk memastikan nomor seri yang dicabut benar-benar tercantum.

inspect-crl.sh

openssl crl -in crl/root-ca.crl -noout \
  -text | head -25

Pada output, perhatikan bagian Revoked Certificates yang memuat nomor seri, waktu pencabutan, dan alasan. CRL ini harus dipublikasikan supaya bisa diakses klien, dan itu yang kita bahas berikutnya.

#Mempublikasikan CRL

Agar CRL bisa ditemukan pemroses, sertifikat yang diterbitkan perlu memuat extension crlDistributionPoints. Extension ini berisi lokasi CRL, biasanya URL HTTP yang mudah di-cache. Berikut potongan konfigurasi OpenSSL untuk menambahkan extension tersebut saat menandatangani sertifikat.

openssl-ca.cnf

[ crl_ext ]
crlDistributionPoints = URI:http://crl.internal/root-ca.crl
authorityKeyIdentifier = keyid:always,issuer:always
 
[ server_ext ]
crlDistributionPoints = URI:http://crl.internal/root-ca.crl

Saat menerbitkan sertifikat baru dengan konfigurasi di atas, OpenSSL menyisipkan crl_distribution_points ke dalam sertifikat. Klien yang memverifikasi akan membaca URL tersebut, mengambil CRL, dan mengecek nomor seri. Pastikan URL-nya bisa diakses dari jaringan klien, termasuk klien yang berada di luar kantor.

Publikasikan CRL di tempat yang stabil dan jangan biarkan proses pembangkitan serta publikasi dilakukan manual terus-menerus. Pada episode tentang otomatisasi nanti, kita akan melihat bagaimana langkah ini bisa dijadwalkan secara berkala atau dipicu oleh event.

#Periode Update CRL

CRL memiliki dua timestamp penting: thisUpdate dan nextUpdate. thisUpdate menandakan kapan CRL dibuat, sedangkan nextUpdate menjanjikan kapan CRL berikutnya tersedia. Klien menyimpan CRL di cache sampai nextUpdate lewat, lalu mengambil versi baru.

Default nextUpdate di OpenSSL adalah 30 hari, tapi praktik terbaik merekomendasikan interval yang jauh lebih pendek, misalnya harian untuk lingkungan produksi. Ingat bahwa ada jendela kerentanan: sertifikat yang dicabut masih dianggap valid selama CRL lama belum kedaluwarsa di cache klien.

Info

Jika lingkungan kalian menuntut pengecekan yang lebih cepat, pertimbangkan Delta CRL, yaitu CRL kecil yang hanya memuat perubahan sejak CRL utama terakhir. Kombinasi CRL penuh yang jarang diperbarui dengan delta CRL yang sering diperbarui menekan jendela kerentanan tanpa membebani jaringan.

#OCSP: Online Certificate Status Protocol

Jika CRL adalah daftar offline yang diperbarui berkala, OCSP adalah layanan online yang menjawab status satu sertifikat secara real-time. Pemroses mengirim permintaan berisi nomor seri, dan responder menjawab salah satu dari tiga status: good, revoked, atau unknown. Jawaban OCSP ditandatangani sehingga tidak bisa dipalsukan di tengah jalan.

#Menjalankan OCSP Responder

OpenSSL bisa menjalankan OCSP responder sederhana dengan perintah openssl ocsp. Responder ini membaca database CA dan menjawab permintaan status berdasarkan isi index.txt. Biasanya responder menggunakan sertifikat khusus bernama OCSP signing certificate supaya kunci root tidak dipakai untuk menandatangani jawaban.

start-ocsp.sh

openssl ocsp -index index.txt -port 2560 \
  -rsigner ocsp.crt -rkey ocsp.key \
  -CA root-ca.crt -text

Opsi -index menunjuk database CA, -port menentukan port yang didengar, -rsigner dan -rkey adalah sertifikat dan kunci untuk menandatangani jawaban, sedangkan -CA adalah root CA yang memvalidasi sertifikat responder. Untuk menguji, query responder dari mesin lain.

query-ocsp.sh

openssl ocsp -issuer root-ca.crt \
  -cert api-server.crt \
  -url http://ocsp.internal:2560

Jawaban good berarti sertifikat valid, revoked berarti dicabut, dan unknown berarti responder tidak mengenali nomor seri tersebut. Status unknown biasanya muncul karena sertifikat diterbitkan oleh CA lain atau karena database tidak sinkron.

#Menambahkan authority_info_access

Supaya pemroses tahu harus bertanya ke mana, sertifikat perlu memuat extension authorityInfoAccess dengan entri OCSP. Inilah mekanisme yang menghubungkan sebuah sertifikat dengan responder milik CA-nya.

openssl-ca.cnf

[ server_ext ]
authorityInfoAccess = OCSP;URI:http://ocsp.internal:2560

Dengan extension ini, pemroses otomatis menemukan URL OCSP responder tanpa konfigurasi manual. Beberapa pemroses lebih memilih OCSP daripada CRL ketika keduanya tersedia, karena status yang diperoleh lebih segar.

#OCSP Stapling

Masalah utama OCSP adalah overhead: setiap handshake, klien harus melakukan request tambahan ke responder sebelum bisa memvalidasi sertifikat. Ini memperlambat koneksi pertama dan menambah satu titik kegagalan. OCSP Stapling menyelesaikannya dengan cara server mengambil status OCSP dari responder lebih dulu, lalu menyertakan bukti status tersebut saat handshake TLS.

Dengan stapling, klien cukup memeriksa bukti yang ditempel oleh server tanpa request tambahan. Server web modern seperti Nginx mendukungnya lewat direktif ssl_stapling.

nginx.conf

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/api-server.key;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/root-ca.crt;
}

Aktifkan stapling pada setiap virtual host yang memakai sertifikat dari CA yang mendukung OCSP. Kecepatan handshake meningkat dan jendela untuk pengecekan status menjadi nol karena status sudah diverifikasi server.

#Sertifikat Revoked dan Unknown di TLS Handshake

Ketika klien menerima sertifikat revoked di handshake, perilaku standar adalah menolak koneksi. Browser menampilkan peringatan, sementara aplikasi yang memakai curl atau library TLS akan memunculkan error verifikasi. Penolakan ini hanya terjadi jika klien benar-benar mengecek status revocation.

Untuk status unknown, kebijakan bervariasi. Banyak pemroses menganggap unknown sebagai kondisi gagal dengan asumsi lebih aman menolak daripada menerima sertifikat yang statusnya tidak jelas. Ada juga pemroses yang hanya menolak saat status revoked dan menerima unknown dengan toleransi. Pastikan kebijakan kalian konsisten, terutama untuk API internal yang memakai mTLS.

Info

OCSP Stapling yang gagal tidak selalu membuat handshake ditolak. Banyak klien tetap melanjutkan koneksi ketika jawaban stapled tidak tersedia, asalkan sertifikatnya sendiri valid. Jangan anggap stapling sebagai pengganti monitoring responder, melainkan sebagai optimasi kinerja.

#Membandingkan CRL dan OCSP

CRL unggul di sisi kesederhanaan dan cache: satu dokumen bisa melayani banyak klien, dan pemroses tidak perlu koneksi per sertifikat. Kelemahannya, ukuran bisa membengkak di CA besar, dan jendela antara pencabutan dengan pembaruan CRL bisa cukup lama.

OCSP menawarkan status real-time dan muatan kecil, tapi menuntut responder yang selalu tersedia, serta menambah satu request per handshake bila stapling tidak dipakai. Banyak lingkungan produksi memakai keduanya sekaligus: CRL sebagai fallback dan OCSP sebagai jalur utama, dengan stapling sebagai pengaman kinerja.

#Penutup

Pada episode 6 ini kalian sudah menutup celah penting yang tertinggal dari episode sebelumnya: sertifikat yang tidak bisa lagi dipercaya. Kalian belajar membangkitkan dan mempublikasikan CRL, menjalankan OCSP responder, menambahkan extension yang menghubungkan sertifikat dengan sumber status, hingga memahami OCSP Stapling dan perilaku handshake terhadap sertifikat revoked.

Inti yang harus dibawa pulang:

Revocation hanya efektif jika pemroses benar-benar mengecek status sertifikat.
CRL adalah daftar berkala yang didistribusikan lewat crl_distribution_points dan diperbarui sesuai nextUpdate.
OCSP menjawab status satu sertifikat secara real-time dengan tiga status: good, revoked, dan unknown.
authority_info_access menghubungkan sertifikat ke responder OCSP milik CA-nya.
OCSP Stapling menghilangkan request ekstra di handshake dan membuat pengecekan status lebih cepat.
Kombinasi CRL sebagai fallback dan OCSP dengan stapling adalah pola yang umum di produksi.

Sampai episode ini, kalian sudah bisa menerbitkan, mempercayai, dan mencabut sertifikat. Di episode 7, kita akan memakai semua fondasi itu untuk skenario nyata: mengonfigurasi sertifikat TLS server dengan chain yang benar, mengujinya dengan openssl s_client, dan membangun mutual TLS untuk autentikasi dua arah. Sampai jumpa!