cert8.db bukan cache sekali guna: periksa pemilik storan

Satu utas sokongan lama menyuruh memadam fail bernama cert8.db dan VPN mula berfungsi semula. Urutan itu lebih kerap kebetulan daripada pembaikan. Fail itu ialah pangkalan data sijil, dan memadamnya mengubah keadaan keselamatan berterusan dengan cara yang tidak ditunjukkan oleh pelancaran yang berjaya.

Log masuk yang tersekat bukan masalah cache

Cache pelayar menyimpan salinan sumber; pangkalan data sijil menyimpan keputusan kepercayaan, sijil dan kunci yang berkaitan. Memadam yang kedua lebih dekat kepada menetapkan semula identiti daripada mengosongkan sejarah. Jika klien tersekat semasa log masuk, bukti berguna ialah proses mana membuka profil mana dan apa yang direkodkannya, bukan fail mana yang dibuang oleh catatan forum. Menghasilkan semula sekatan dan membaca log klien mengambil masa lebih lama daripada memadam fail, dan itulah satu-satunya jalan kepada punca sebenar.

Nama fail juga membawa sejarah: NSS membezakan cert8.db dan key3.db lama daripada cert9.db dan key4.db berasaskan SQLite. Catat baris log yang anda lihat sebelum sekatan, kerana itulah satu-satunya bukti tahan lama yang anda miliki.

Profil mana yang benar-benar dibuka klien

Kenal pasti klien, kaedah pengesahannya dan storan yang dibacanya. Terdapat tiga laluan log masuk di sini: berbantukan pelayar, pelayar terbenam dan klien asli, dan semuanya tidak perlu berkongsi profil. Pangkalan data dengan nama yang betul dalam direktori lain bukan bukti bahawa proses yang tersekat membukanya. Di Linux, storan NSS biasanya berada di bawah ~/.pki/nssdb pengguna atau direktori profil setiap aplikasi. Kedua-dua susun atur boleh wujud bersama pada satu mesin, jadi periksa kedua-duanya jika migrasi baru berlaku.

Senaraikan kandungan storan sebelum mengubahnya: certutil -L -d sql:$HOME/.pki/nssdb mencetak sijil, dan alat yang sama dengan -K menunjukkan sama ada kunci wujud.

Jika arahan melaporkan pangkalan data tidak boleh dibuka, anda telah menemui profil yang digunakan alat itu, bukan semestinya yang digunakan VPN.

Buat sandaran profil sebelum sebarang pembaikan

Tutup aplikasi yang terjejas, kemudian salin seluruh direktori profil dengan kaedah sandaran yang diluluskan. Pangkalan data sijil dan kunci ialah keadaan berkaitan tetapi berasingan, dan menyimpan satu fail sembarangan bukan pelan pemulihan untuk seluruh identiti. Lindungi salinan itu, kerana profil mungkin mengandungi kunci peribadi. Catat apa dan di mana anda membuat sandaran, supaya pembaikan yang gagal mempunyai jalan kembali.

Kemudian sahkan skop sebenar pembaikan dengan penyelia. Menetapkan semula seluruh storan, membuang satu sijil usang yang diketahui dan membaiki profil pelayar ialah tiga perubahan berbeza dengan tiga risiko berbeza.

Selepas pembaikan, log masuk dan periksa storan

Selepas pembaikan yang dibenarkan, log masuk ke VPN dan sahkan sijil pelayan masih disahkan seperti yang dimaksudkan. Periksa bahawa identiti yang diperlukan aliran kerja masih ada dan tiada sauh kepercayaan tidak dijangka muncul. Pembaikan yang membuat sambungan berfungsi dengan mempercayai lebih daripada sebelum ini bukan pembaikan.

Asingkan pemerhatian daripada arahan: satu pemadaman dan satu pelancaran berjaya bukan penyelesaian umum.

Jika sekatan kembali, tangkap log klien dan profil yang digunakan sebelum mengubah apa-apa lagi. Rekod itulah yang mengubah tekaan menjadi diagnosis.