Sertifikat yang masih tersisa berbulan-bulan dan login yang langsung gagal menunjuk pada dua objek berbeda dengan dua jam berbeda. Server menolak koneksi karena daftar sertifikat yang dicabut yang ia konsultasikan telah melewati tanggal kedaluwarsanya sendiri, bukan karena sertifikat pengguna sudah usang. Memperbarui sertifikat pengguna tidak berpengaruh apa pun pada daftar itu.

Memisahkan kedua jadwal itulah keseluruhan diagnosisnya, dan itu mengubah seperti apa perbaikannya harus dilakukan.

Dua jam, dan hanya salah satunya adalah sertifikat

Sertifikat membawa jendela masa berlaku. Daftar pencabutan sertifikat membawa jendelanya sendiri, ditambah penerbit dan tanda tangan, dan pemverifikasi menolak memercayai daftar yang waktu pembaruan berikutnya sudah lewat. Ketika itu terjadi, klien menyajikan sertifikat yang sepenuhnya valid dan server tetap memutus koneksi dengan pesan tentang daftar tersebut. Pengguna membaca pesan itu sebagai 'sertifikat kedaluwarsa', yang mengirim permintaan pembaruan ke tempat yang salah.

Kedua objek juga memiliki pemilik berbeda: sertifikat berasal dari CA yang menerbitkannya, sedangkan daftar dihasilkan menurut jadwal oleh siapa pun yang mengoperasikan CA itu. Pengguna tidak dapat menyegarkannya, dan penerbitan ulang sertifikat tidak dapat memperpanjangnya.

Bacalah daftar yang benar-benar dimuat layanan

Mulailah dari konfigurasi yang berjalan, bukan dari berkas yang Anda harapkan. Jalur crl-verify bisa absolut, relatif terhadap profil, atau salinan yang ditanam dalam image, dan pemverifikasi membaca salinan itu. Periksa di tempatnya dengan openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate dan bandingkan tanggalnya dengan jam server.

Lalu pastikan berkas itu benar-benar yang dipakai: periksa tanda tangannya dengan openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, yang melaporkan hasil verifikasi alih-alih mencetak kolom secara diam-diam. Daftar yang ditandatangani CA lain, atau salinan usang yang tertinggal di direktori kedua, gagal persis seperti daftar yang kedaluwarsa.

Buat ulang dari basis data pencabutan, bukan dari nol

Daftar baru harus berasal dari basis data pencabutan CA saat ini, melalui proses penandatanganan yang disetujui. Membuat daftar kosong, atau membuat ulang dari cadangan indeks yang lama, diam-diam membatalkan pencabutan setiap identitas yang ditambahkan sejak cadangan itu. Itu mengubah gangguan login menjadi kemunduran keamanan, dan tak seorang pun menyadarinya karena gejalanya hilang.

Simpan langkah pembuatan dalam kendali versi bersama perangkat CA lainnya, agar interval dan kunci penandatanganan terdokumentasi, bukan diingat. Entri runbook yang menyebutkan perintah, penandatangan, dan target publikasi sudah cukup. Dengan begitu siapa pun yang berjaga dapat membuat ulang tanpa menebak berkas indeks mana yang otoritatif. Simpan nomor seri daftar dan waktu pembaruan berikutnya bersama catatan penyebaran.

Sebarkan ke tempat pemverifikasi melihat

Salin daftar baru ke jalur yang dibaca layanan, atur kepemilikan dan mode agar akun layanan dapat membacanya tetapi yang lain tidak, lalu muat ulang atau mulai ulang sesuai perilaku yang terdokumentasi. Jika daemon menyimpan daftar di cache saat mulai, mengganti berkas tanpa memuat ulang tidak mengubah apa pun yang akan disadari proses yang berjalan. Pastikan stempel waktu yang dilaporkan proses setelah pemuatan ulang.

Jika beberapa layanan memverifikasi klien, sebarkan ke masing-masing. Memperbarui satu titik akhir dan membiarkan yang lain dengan salinan lama menghasilkan kegagalan yang hanya muncul pada pengguna yang mendarat di titik kedua. Simpan daftar singkat titik akhir itu di runbook yang sama. Setelah peluncuran, periksa tanggal daftar yang dilaporkan tiap titik akhir alih-alih menganggap salinannya sudah sampai.

Buat tenggat berikutnya terlihat sebelum lewat

Interval publikasi yang lebih panjang menurunkan frekuensi insiden ini tanpa menciptakan proses. Pilih interval dari kebijakan operator, lalu pasang peringatan pada kolom pembaruan berikutnya daftar yang disebarkan dengan waktu tunggu yang cukup untuk membuat ulang dan menyebarkan. Pasang peringatan pada salinan yang disebarkan, bukan pada host CA, karena salinan yang disebarkan itulah yang gagal.

Setelah penyebaran, verifikasi kedua arah: pengguna yang diizinkan terhubung, dan identitas tercabut yang dikenal masih gagal. Pemeriksaan kedua itulah yang menangkap pembuatan ulang yang tidak lengkap, dan hanya perlu satu perintah terhadap profil uji yang Anda simpan justru untuk tujuan ini.

Artikel terkait