OCSP versus CRL: cara kerja sebenarnya setiap pemeriksaan pencabutan

Salah satu dari dua pemeriksaan pencabutan ini mengembalikan jawaban bertanda tangan tentang satu sertifikat, dan yang lain mengembalikan daftar bertanda tangan yang Anda unduh seluruhnya. Keduanya dimaksudkan untuk memberi tahu pemverifikasi apakah suatu kredensial masih tepercaya, dan keduanya gagal dengan cara yang sama sekali tidak mirip. Urutan di bawah mengikuti apa yang benar-benar dihadapi operator di produksi, mulai dari byte di jaringan hingga gateway yang menolak koneksi. Melewati satu langkah adalah cara penerapan berakhir dengan kebijakan pencabutan yang hanya ada di atas kertas.

Langkah 1: Apa yang dikembalikan tiap pemeriksaan dan berapa lama ia tetap bisa dipakai

CRL diterbitkan sebagai satu objek bertanda tangan yang mencakup setiap sertifikat yang telah dicabut penerbit, sehingga pemverifikasi mengambilnya sekali dan memakainya ulang sampai nextUpdate daftar itu lewat. Respons OCSP lebih sempit: ia menjawab tepat satu sertifikat dan membawa thisUpdate, producedAt, dan biasanya juga nextUpdate. Perbedaan itulah yang mengarahkan semua hal lainnya. CRL yang di-cache menua secara diam-diam, karena berkasnya masih bisa diurai dan tanda tangannya masih terverifikasi, sedangkan respons OCSP yang kedaluwarsa jelas tidak berguna saat Anda membaca stempel waktunya.

Karena itu cache adalah hal pertama yang harus ditetapkan: komponen mana yang memegang salinan, dan batas atas apa yang dipatuhi salinan itu. Di gateway batas atasnya harus nextUpdate dikurangi margin keamanan, bukan apa pun yang kebetulan disarankan header cache HTTP. openssl crl -in issuer.crl -noout -lastupdate -nextupdate mencetak kedua tanggal, dan daftar yang nextUpdate-nya sudah lewat harus diperlakukan sebagai hilang, bukan sekadar tua.

Langkah 2: Ke mana sertifikat mengarahkan klien

Sertifikat daun biasanya membawa dua petunjuk: ekstensi titik distribusi CRL dan entri akses informasi otoritas untuk OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints mencetak yang pertama, dan yang kedua berada di bawah bagian AIA dari openssl x509 -in client.pem -noout -text. Kedua ekstensi itu adalah penunjuk, bukan kewajiban. Klien yang tidak pernah menerapkan pemeriksaan pencabutan akan terhubung dengan sangat baik ke sertifikat yang ekstensinya menyebut responder yang sudah mati selama setahun.

Titik distribusi sering menyebut host internal yang hanya diresolusi di dalam satu segmen jaringan, dan sebagian klien lama menolak URL ldap mentah-mentah. Uji keterjangkauan dari host yang mengakhiri tunnel, bukan dari laptop Anda sendiri, karena itulah satu-satunya sudut pandang yang kegagalannya benar-benar penting.

Langkah 3: Pilih fail-closed atau fail-open sebelum gangguan

Responder yang tak terjangkau atau daftar yang kedaluwarsa memaksa keputusan: tolak koneksi, atau terima dan catat celahnya. Subperintah verify OpenSSL membuat pilihan ketat itu eksplisit, karena menambahkan -crl_check mengubah CRL yang tidak tersedia menjadi unable to get certificate CRL dan verifikasi yang gagal. Soft-fail di sebagian besar tumpukan sama sekali bukan flag, melainkan tidak adanya pemeriksaan, dan itulah sebabnya ia terkirim secara tidak sengaja.

Untuk melihat perilaku klien yang sebenarnya, singkirkan responder dan sambungkan ulang. Jika tunnel tetap muncul, temukan baris log yang mencatat pemeriksaan yang dilewati, lalu tanyakan apakah ada yang akan membaca baris itu saat insiden. Vendor yang sama bisa berbeda menurut protokol: klien IKEv2 dan klien OpenVPN di satu mesin membaca tombol konfigurasi yang tidak saling terkait.

Langkah 4: Buktikan pemeriksaan berjalan di tempat lalu lintas diterima

Temukan proses yang mengakhiri atau mengesahkan koneksi, lalu tanyakan baris konfigurasi yang mengaktifkan pemeriksaan pencabutan. Gateway yang memvalidasi rantai tetapi tidak pernah bertanya soal pencabutan memberlakukan kebijakan yang berbeda dari yang ada di dokumentasi Anda, dan tidak ada tangkapan layar rantai sertifikat yang membuktikan sebaliknya. OpenVPN menulis opsi itu sebagai crl-verify; strongSwan menyimpan pencarian CRL dan OCSP di bawah konfigurasi CA, tempat crl_uris atau ocsp_uris ditetapkan. Jika Anda tidak bisa menunjuk salah satunya, anggap pemeriksaan tidak ada.

Respons OCSP hanya berlaku bila CA penerbit menandatanganinya, atau bila responder yang memegang penggunaan kunci lanjutan OCSPSigning yang didelegasikan CA itu menandatanganinya, sehingga jawaban dari layanan yang tidak terkait tidak membuktikan apa pun. Jika Anda menjalankan responder sendiri, pantau ia sebagai dependensi keras, karena satu layanan yang mati langsung menjadi gangguan bagi setiap klien fail-closed.

Langkah 5: Cabut satu sertifikat dengan sengaja

Ambil sertifikat uji, cabut melalui kanal yang sama dengan yang dipakai produksi, dan tanyakan langsung kepada responder. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text seharusnya melaporkan Cert Status: revoked bersama waktu pencabutan, dan jawaban good berarti pencabutan Anda tidak sampai ke responder yang ditanyakan klien Anda. Lalu jalankan openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem untuk melihat keputusan yang sama lewat jalur daftar. Baca string alasan, bukan kode keluar, karena penolakan pencabutan dan kesalahan rantai keduanya berakhir dengan kegagalan.

Langkah yang benar-benar penting adalah yang terakhir: sambungkan ulang dengan profil lama terhadap titik penegakan yang sebenarnya dan pastikan penolakan berasal dari pencabutan. Lalu sambungkan ulang dengan sertifikat baru yang valid untuk membuktikan Anda tidak sekadar merusak listener. Menghapus profil di klien tidak membuktikan apa pun soal keputusan server, dan begitu pula eksekusi openssl verify yang berhasil di mesin yang tidak pernah mengakhiri tunnel. RFC 6960 mendefinisikan isi respons OCSP yang sesuai, termasuk nilai status yang dibaca pengujian ini.