cert8.db er ikke en engangscache: kontroller eieren av lageret

En gammel støttetråd sier at du skal slette en fil som heter cert8.db, og VPN virker igjen. Den rekkefølgen er oftere et sammentreff enn en reparasjon. Filen er en sertifikatdatabase, og å fjerne den endrer varig sikkerhetstilstand på måter en vellykket oppstart ikke avslører.

En frosset innlogging er ikke et cacheproblem

En nettlesercache lagrer kopier av ressurser; en sertifikatdatabase lagrer tillitsbeslutninger, sertifikater og nøklene som hører til. Å slette den andre er nærmere en tilbakestilling av identitet enn en sletting av historikk. Hvis klienten frøs under innlogging, er det nyttige beviset hvilken prosess som åpnet hvilken profil og hva den logget, ikke hvilken fil et foruminnlegg fjernet. Å gjenskape frysing og lese klientloggen tar lengre tid enn å slette en fil, og det er den eneste veien til en reell årsak.

Filnavnet bærer også historie: NSS skiller de gamle cert8.db og key3.db fra SQLite-baserte cert9.db og key4.db. Skriv ned logglinjen du så før frysingen, for det er det eneste varige beviset du har.

Hvilken profil klienten faktisk åpner

Identifiser klienten, autentiseringsmetoden og lageret den leser. Her finnes tre innloggingsveier: nettleserassistert, innebygd nettleser og opprinnelig klient, og de trenger ikke dele profil. En database med riktig navn i en annen mappe er ikke bevis for at den frosne prosessen åpnet den. På Linux ligger NSS-lageret vanligvis under brukerens ~/.pki/nssdb eller i en programprofilmappe. Begge oppsettene kan eksistere på samme maskin, så kontroller begge hvis migreringen er nylig.

List opp hva lageret inneholder før du endrer det: certutil -L -d sql:$HOME/.pki/nssdb skriver ut sertifikatene, og samme verktøy med -K viser om nøkler finnes.

Hvis kommandoen melder at databasen ikke kan åpnes, har du funnet profilen verktøyet bruker, men ikke nødvendigvis den VPN brukte.

Ta sikkerhetskopi av profilen før enhver reparasjon

Lukk de berørte programmene, og kopier deretter hele profilmappen med den godkjente sikkerhetskopimetoden. Sertifikat- og nøkkeldatabaser er beslektet, men adskilt tilstand, og å lagre én vilkårlig fil er ikke en gjenopprettingsplan for hele identiteten. Beskytt kopien, for profilen kan inneholde private nøkler. Skriv ned hva du sikkerhetskopierte og hvor, slik at en mislykket reparasjon har en vei tilbake.

Bekreft deretter reparasjonens nøyaktige omfang med vedlikeholderen. En full tilbakestilling av lageret, fjerning av ett kjent utdatert sertifikat og reparasjon av en nettleserprofil er tre ulike endringer med tre ulike risikoer.

Etter reparasjonen, logg inn og undersøk lageret

Etter en autorisert reparasjon, logg inn på VPN og bekreft at servercertifikatet fortsatt valideres som tiltenkt. Kontroller at identitetene arbeidsflyten trenger fortsatt finnes, og at ingen uventet tillitsanker har dukket opp. En reparasjon som får forbindelsen til å virke ved å stole mer enn før, er ikke en reparasjon.

Hold observasjon og instruksjon atskilt: én sletting og én vellykket oppstart er ikke en generell løsning.

Hvis frysingen kommer tilbake, fang klientloggen og profilen som brukes før du endrer noe annet. Den registreringen er det som gjør en gjetning til en diagnose.