Log masuk VPN baharu gagal walaupun sijil masih sah: semak CRL

Sijil yang masih berbaki berbulan-bulan dan log masuk yang gagal serta-merta menunjuk kepada dua objek berbeza dengan dua jam berbeza. Pelayan menolak sambungan kerana senarai sijil yang dibatalkan yang dirujuknya telah melepasi tarikh luputnya sendiri, bukan kerana sijil pengguna menjadi lapuk. Memperbaharui sijil pengguna tidak melakukan apa-apa untuk senarai itu.

Mengasingkan kedua-dua jadual itulah keseluruhan diagnosis, dan ia mengubah bentuk pembaikan yang diperlukan.

Dua jam, dan hanya satu daripadanya ialah sijil

Sijil membawa tetingkap kesahan. Senarai pembatalan sijil membawa tetingkapnya sendiri, bersama pengeluar dan tandatangan, dan pengesah enggan mempercayai senarai yang masa kemas kini seterusnya telah berlalu. Apabila itu berlaku, klien mengemukakan sijil yang sah sepenuhnya dan pelayan tetap memutuskan sambungan dengan mesej tentang senarai itu. Pengguna membaca mesej itu sebagai 'sijil telah tamat tempoh', yang menghantar permintaan pembaharuan ke tempat yang salah.

Kedua-dua objek juga mempunyai pemilik berbeza: sijil datang daripada CA yang mengeluarkannya, manakala senarai dijana mengikut jadual oleh sesiapa yang mengendalikan CA itu. Pengguna tidak boleh menyegarkannya, dan pengeluaran semula sijil tidak boleh memanjangkannya.

Baca senarai yang benar-benar dimuatkan oleh perkhidmatan

Mulakan daripada konfigurasi yang sedang berjalan dan bukan daripada fail yang anda jangkakan. Laluan crl-verify mungkin mutlak, relatif kepada profil, atau salinan yang dibakar ke dalam imej, dan pengesah membaca salinan itu. Periksa di tempatnya dengan openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate dan bandingkan tarikh dengan jam pelayan.

Kemudian sahkan bahawa fail itu benar-benar yang digunakan: semak tandatangannya dengan openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, yang melaporkan hasil pengesahan dan bukannya mencetak medan secara senyap. Senarai yang ditandatangani oleh CA lain, atau salinan lapuk yang tertinggal dalam direktori kedua, gagal sama seperti senarai yang tamat tempoh.

Jana semula daripada pangkalan data pembatalan, bukan dari awal

Senarai baharu mesti datang daripada pangkalan data pembatalan semasa CA, melalui proses penandatanganan yang diluluskan. Menjana senarai kosong, atau menjana semula daripada sandaran indeks yang lama, secara senyap membatalkan pembatalan setiap identiti yang ditambah sejak sandaran itu. Itu menjadikan gangguan log masuk sebagai kemunduran keselamatan, dan tiada siapa menyedarinya kerana gejala itu hilang.

Simpan langkah penjanaan dalam kawalan versi bersama alat CA yang lain, supaya selang dan kunci tandatangan didokumenkan dan bukan diingati. Entri runbook yang menamakan arahan, penandatangan dan sasaran penerbitan sudah memadai. Dengan itu sesiapa yang bertugas boleh menjana semula tanpa meneka fail indeks mana yang berwibawa. Simpan nombor siri senarai dan masa kemas kini seterusnya bersama rekod penggunaan.

Gunakan di tempat pengesah melihat

Salin senarai baharu ke laluan yang dibaca oleh perkhidmatan, tetapkan pemilikan dan mod supaya akaun perkhidmatan boleh membacanya tetapi yang lain tidak, dan muat semula atau mulakan semula mengikut tingkah laku yang didokumenkan. Jika daemon menyimpan senarai dalam cache semasa permulaan, menggantikan fail tanpa memuat semula tidak mengubah apa-apa yang akan disedari oleh proses yang sedang berjalan. Sahkan cap masa yang dilaporkan oleh proses selepas muat semula.

Jika beberapa perkhidmatan mengesahkan klien, gunakan pada setiap satu daripadanya. Mengemas kini satu titik akhir dan membiarkan yang lain dengan salinan lama menghasilkan kegagalan yang hanya muncul pada pengguna yang mendarat di titik kedua. Simpan senarai pendek titik akhir itu dalam runbook yang sama. Selepas pelaksanaan, semak tarikh senarai yang dilaporkan oleh setiap satu dan bukannya menganggap salinan itu telah tiba.

Jadikan tarikh akhir seterusnya kelihatan sebelum ia berlalu

Selang penerbitan yang lebih panjang menurunkan kekerapan insiden ini tanpa mencipta proses. Pilih selang daripada dasar pengendali, kemudian tetapkan amaran pada medan kemas kini seterusnya senarai yang digunakan dengan masa mendahului yang cukup untuk menjana semula dan menggunakan. Tetapkan amaran pada salinan yang digunakan, bukan pada hos CA, kerana salinan yang digunakan itulah yang gagal.

Selepas penggunaan, sahkan kedua-dua arah: pengguna yang dibenarkan bersambung, dan identiti terbatal yang diketahui masih gagal. Semakan kedua itulah yang menangkap penjanaan semula yang tidak lengkap, dan ia memerlukan satu arahan terhadap profil ujian yang anda simpan khusus untuk tujuan ini.