cert8.db bukan cache sekali pakai: periksa pemilik penyimpanan

Sebuah utas dukungan lama menyebutkan menghapus file bernama cert8.db dan VPN kembali berfungsi. Urutan itu lebih sering kebetulan daripada perbaikan. File tersebut adalah basis data sertifikat, dan menghapusnya mengubah status keamanan persisten dengan cara yang tidak ditunjukkan oleh peluncuran yang berhasil.

Login membeku bukan masalah cache

Cache peramban menyimpan salinan sumber daya; basis data sertifikat menyimpan keputusan kepercayaan, sertifikat, dan kunci yang menyertainya. Menghapus yang kedua lebih dekat ke mengatur ulang identitas daripada membersihkan riwayat. Jika klien membeku saat masuk, bukti yang berguna adalah proses mana membuka profil mana dan apa yang dicatatnya, bukan file mana yang dihapus sebuah kiriman forum. Mereproduksi pembekuan dan membaca log klien lebih lama daripada menghapus file, dan itulah satu-satunya jalan menuju penyebab nyata.

Nama file juga membawa sejarah: NSS membedakan cert8.db dan key3.db lama dari cert9.db dan key4.db berbasis SQLite. Catat baris log yang Anda lihat sebelum pembekuan, karena itu satu-satunya bukti tahan lama yang Anda miliki.

Profil mana yang benar-benar dibuka klien

Identifikasi klien, metode autentikasinya, dan penyimpanan yang dibacanya. Ada tiga jalur masuk di sini: berbantuan peramban, peramban tertanam, dan klien asli, dan semuanya tidak harus berbagi profil. Basis data dengan nama yang tepat di direktori lain bukan bukti bahwa proses yang membeku membukanya. Di Linux, penyimpanan NSS biasanya berada di bawah ~/.pki/nssdb pengguna atau direktori profil per aplikasi. Kedua tata letak dapat hidup berdampingan di satu mesin, jadi periksa keduanya jika migrasi baru saja dilakukan.

Daftar isi penyimpanan sebelum mengubahnya: certutil -L -d sql:$HOME/.pki/nssdb mencetak sertifikat, dan alat yang sama dengan -K menunjukkan apakah ada kunci.

Jika perintah melaporkan basis data tidak dapat dibuka, Anda telah menemukan profil yang digunakan alat itu, bukan tentu yang digunakan VPN.

Cadangkan profil sebelum perbaikan apa pun

Tutup aplikasi yang terdampak, lalu salin seluruh direktori profil dengan metode cadangan yang disetujui. Basis data sertifikat dan kunci adalah status terkait tetapi terpisah, dan menyimpan satu file sembarang bukan rencana pemulihan untuk seluruh identitas. Lindungi salinannya, karena profil dapat memuat kunci privat. Catat apa dan di mana Anda mencadangkan, agar perbaikan yang gagal punya jalan kembali.

Lalu konfirmasi cakupan perbaikan yang tepat dengan pemelihara. Mengatur ulang seluruh penyimpanan, menghapus satu sertifikat usang yang diketahui, dan memperbaiki profil peramban adalah tiga perubahan berbeda dengan tiga risiko berbeda.

Setelah perbaikan, masuk dan periksa penyimpanan

Setelah perbaikan yang diizinkan, masuk ke VPN dan pastikan sertifikat server masih divalidasi sesuai maksud. Periksa bahwa identitas yang dibutuhkan alur kerja masih ada dan tidak muncul jangkar kepercayaan tak terduga. Perbaikan yang membuat koneksi bekerja dengan lebih percaya daripada sebelumnya bukan perbaikan.

Pisahkan pengamatan dan instruksi: satu penghapusan dan satu peluncuran berhasil bukan solusi umum.

Jika pembekuan kembali, tangkap log klien dan profil yang dipakai sebelum mengubah apa pun. Catatan itulah yang mengubah dugaan menjadi diagnosis.