Anda mencabut sertifikat, membuat daftar baru, dan profil lama masih membangun terowongan. Pencabutan itu sendiri tidak rusak: CRL adalah pernyataan bertanda tangan bahwa nomor seri tidak lagi berlaku, dan itu mengubah akses hanya ketika komponen yang mengakhiri TLS memuatnya, untuk penerbit yang benar, sebelum mengambil keputusan penerimaan. Di sanalah sebagian besar kasus ini berada, dan itulah sebabnya pencabutan dan penolakan adalah dua fakta yang berbeda.

Lakukan lima pemeriksaan di bawah ini secara berurutan, dan berhenti pada yang pertama tidak berlaku, karena setiap pemeriksaan berikutnya menganggap yang sebelumnya benar.

Periksa komponen mana yang mengambil keputusan penerimaan

Sebutkan proses yang memverifikasi sertifikat klien, karena hanya proses itu yang dapat menegakkan daftar. Pada server OpenVPN itu adalah daemon itu sendiri, dikonfigurasi dengan crl-verify. Di ocserv itu adalah baris crl dalam ocserv.conf. Di strongSwan inputnya adalah CRL yang dimuat bersama strictcrlpolicy. Proksi atau perangkat yang mengakhiri TLS di depan VPN juga bisa menjadi pemverifikasi sebenarnya, dan jika demikian, daemon di belakangnya tidak pernah melihat sertifikat klien.

WireGuard termasuk kategori lain. Tidak ada sertifikat dan tidak ada daftar pencabutan; peer diterima berdasarkan kunci publiknya dalam konfigurasi, jadi mengakhiri akses berarti menghapus kunci itu. Jika Anda mencari CRL pada penerapan yang hanya memakai WireGuard, mekanisme itu tidak ada.

Waspadai juga jebakan di sisi klien. Klien yang menolak terhubung karena tidak menyukai sertifikat server sedang menegakkan rantai server, bukan mencabut kredensialnya sendiri. Sertifikat pengguna hanya dicabut di tempat sertifikat pengguna itu diverifikasi, dan itu hampir selalu sisi server.

Periksa untuk penerbit mana daftar itu ditandatangani

CRL dibatasi pada satu CA penerbit. Dengan akar dan perantara, sertifikat daun berasal dari perantara, jadi daftar yang penting adalah CRL perantara; daftar akar tidak mengatakan apa pun tentang daun itu. Pemverifikasi yang diarahkan ke berkas yang salah akan mem-parsing-nya dengan senang hati, tidak menemukan entri yang cocok, dan menerima semuanya.

Konfirmasikan pemasangan sebelum menyentuh daemon. Penerbit pada sertifikat harus cocok dengan subject daftar:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Ketika keduanya berasal dari CA yang sama, nomor seri yang dicetak untuk sertifikat adalah nilai yang harus muncul di daftar. Jika tidak cocok, Anda memegang CRL yang salah atau salinan yang salah.

Validitas termasuk dalam pemeriksaan yang sama. nextUpdate di masa lalu membuat daftar menjadi usang, dan pemverifikasi yang gagal tertutup akan menolak setiap klien alih-alih hanya yang dicabut.

Periksa apakah nomor seri ada di salinan yang dimuat daemon

Pencabutan menulis entri ke basis data CA, dan pembuatan ulang menulis berkas baru. Tidak ada dari keduanya yang mencapai daemon berjalan yang memuat salinan lama saat mulai. Dump daftar dan cari nomor seri:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Lalu periksa bagaimana implementasi Anda mengambil berkas. OpenVPN membaca jalur yang diberikan ke crl-verify sekali saat mulai, jadi daftar baru memerlukan mulai ulang atau sinyal mulai ulang; opsi yang sama diarahkan ke direktori dibaca ulang pada setiap koneksi, dan itulah sebabnya mode direktori ada. strongSwan harus memuat ulang kredensialnya, misalnya dengan swanctl --load-creds. Berkas di disk benar dan pemverifikasi memakainya adalah dua fakta berbeda.

Periksa kebijakan untuk daftar yang hilang atau kedaluwarsa

Ini adalah keputusan yang tidak pernah diambil secara eksplisit oleh banyak penerapan, dan itu menentukan apakah pencabutan melindungi Anda atau mengunci semua orang di luar. Fail-closed berarti tanpa informasi pencabutan yang dapat dipakai terjadi penolakan; fail-open berarti pemverifikasi melanjutkan tanpa itu. strongSwan mengekspos pilihan sebagai strictcrlpolicy. OpenVPN dengan crl-verify menolak mulai pada berkas yang tidak dapat dibaca atau di-parsing, dan daftar yang kedaluwarsa muncul sebagai kesalahan verifikasi TLS tentang CRL kedaluwarsa alih-alih penerimaan senyap.

State of the revocation dataFail-closed resultFail-open result
List missing or unreadableVerification fails, so expect an outageEvery client connects, including the revoked one
List past nextUpdateValidation errors until a fresh list is deployedOld status is trusted indefinitely
Revoked serial present in the loaded listHandshake rejected for that certificateHandshake rejected for that certificate

Arah mana pun yang Anda pilih, otomasi lebih penting daripada pilihan: tugas yang membuat ulang CRL sebelum nextUpdate, dan peringatan ketika salinan yang diterapkan menua, mencegah kedua kebijakan menjadi insiden. Pemeriksaan online dengan OCSP memindahkan kesegaran ke responden, tetapi aturan yang sama berlaku, karena pemverifikasi yang tidak dikonfigurasi untuk memeriksa jawaban tidak mengubah apa pun.

Periksa sesi aktif, lalu salinan kunci

Pencabutan dievaluasi selama validasi sertifikat, yang terjadi saat terhubung dan saat negosiasi ulang. Sesi yang sudah terbentuk terus berjalan sampai melakukan negosiasi ulang, dan nilai bawaan OpenVPN adalah sekali sejam dengan reneg-sec 3600. Jika orang tersebut harus keluar dari jaringan sekarang, akhiri sesi selain menerbitkan daftar, lalu konfirmasikan bahwa sambungan ulang ditolak.

Pisahkan kredensial dari salinannya. Menghapus profil di satu laptop tidak mencegah salinan lain dari kunci privat yang sama untuk mengautentikasi; pencabutan yang membuat setiap salinan tidak berguna, dan hanya ketika pemeriksaan sebelumnya berlaku. Berikan perangkat pengganti sertifikatnya sendiri agar yang satu dapat dicabut tanpa menyentuh yang lain.

Sebelum menyebutnya selesai: komponen pemverifikasi sudah diidentifikasi, penerbit daftar cocok dengan penerbit daun, nomor seri yang dicabut ada di salinan yang benar-benar dimuat daemon, kebijakan untuk daftar yang hilang atau kedaluwarsa bersifat sengaja dan dipantau, dan sesi aktif diakhiri alih-alih ditunggu. Format di balik semua ini ditentukan dalam RFC 5280.

Artikel terkait