cert8.db nu este un cache de unică folosință: verificați proprietarul depozitului

Un fir vechi de asistență spune să ștergi un fișier numit cert8.db și VPN-ul începe să funcționeze. Acea secvență este mai des o coincidență decât o reparație. Fișierul este o bază de date de certificate, iar eliminarea lui modifică starea de securitate persistentă în moduri pe care o pornire reușită nu le dezvăluie.

O autentificare blocată nu este o problemă de cache

Cache-ul browserului stochează copii ale resurselor; baza de date de certificate stochează decizii de încredere, certificate și cheile asociate. Ștergerea celei de-a doua este mai aproape de resetarea unei identități decât de ștergerea istoricului. Dacă clientul s-a blocat la autentificare, dovada utilă este care proces a deschis ce profil și ce a înregistrat, nu ce fișier a eliminat o postare de forum. Reproducerea blocajului și citirea jurnalului clientului durează mai mult decât ștergerea unui fișier și este singura cale către o cauză reală.

Numele fișierului poartă și istorie: NSS distinge vechile cert8.db și key3.db de cert9.db și key4.db bazate pe SQLite. Notați linia de jurnal pe care ați văzut-o înainte de blocaj, pentru că este singura dovadă durabilă pe care o aveți.

Ce profil deschide de fapt clientul

Identificați clientul, metoda lui de autentificare și depozitul pe care îl citește. Există trei căi de autentificare: asistată de browser, browser încorporat și client nativ, și nu trebuie să partajeze un profil. O bază de date cu numele corect în alt director nu dovedește că procesul blocat a deschis-o. Pe Linux, depozitul NSS se află de obicei sub ~/.pki/nssdb al utilizatorului sau într-un director de profil pe aplicație. Ambele aranjamente pot coexista pe aceeași mașină, așa că verificați-le pe amândouă dacă migrarea este recentă.

Înainte de a-l modifica, enumerați ce conține depozitul: certutil -L -d sql:$HOME/.pki/nssdb tipărește certificatele, iar același instrument cu -K arată dacă există chei.

Dacă comanda raportează că baza de date nu poate fi deschisă, ați găsit profilul folosit de instrument, dar nu neapărat pe cel folosit de VPN.

Faceți o copie de siguranță a profilului înainte de orice reparație

Închideți aplicațiile afectate, apoi copiați întregul director de profil prin metoda de backup aprobată. Bazele de date de certificate și chei sunt stare înrudită, dar distinctă, iar salvarea unui fișier arbitrar nu este un plan de recuperare pentru toată identitatea. Protejați copia, pentru că profilul poate conține chei private. Notați ce și unde ați salvat, ca o reparație eșuată să aibă o cale de întoarcere.

Apoi confirmați cu întreținătorul amploarea exactă a reparației. Resetarea completă a depozitului, eliminarea unui certificat cunoscut învechit și repararea unui profil de browser sunt trei modificări diferite cu trei riscuri diferite.

După reparație, autentificați-vă și inspectați depozitul

După o reparație autorizată, autentificați-vă la VPN și confirmați că certificatul serverului este încă validat conform intenției. Verificați că identitățile de care are nevoie fluxul de lucru sunt încă prezente și că nu a apărut o ancoră de încredere neașteptată. O reparație care face conexiunea să funcționeze încrezându-se mai mult decât înainte nu este o reparație.

Țineți observația și instrucțiunea separate: o ștergere urmată de o pornire reușită nu este o soluție generală.

Dacă blocajul revine, capturați jurnalul clientului și profilul folosit înainte de a schimba orice altceva. Acea înregistrare este ce transformă o presupunere într-un diagnostic.