cert8.db er ikkje ein eingongscache: kontroller eigaren av lageret

Ein gammal støttetråd seier at du skal sletta ei fil som heiter cert8.db, og VPN verkar igjen. Den rekkjefølgja er oftare eit samantreff enn ein reparasjon. Fila er ein sertifikatdatabase, og å fjerna ho endrar varig tryggleikstilstand på måtar ein vellukka oppstart ikkje avdekkjer.

Ei frosen innlogging er ikkje eit cacheproblem

Ein nettlesarcache lagrar kopiar av ressursar; ein sertifikatdatabase lagrar tillitsavgjerder, sertifikat og nøklane som høyrer til. Å sletta den andre er nærare ei tilbakestilling av identitet enn ei sletting av historikk. Viss klienten fraus under innlogging, er det nyttige beviset kva prosess som opna kva profil og kva ho logga, ikkje kva fil eit foruminnlegg fjerna. Å gjenskapa frysinga og lesa klientloggen tek lengre tid enn å sletta ei fil, og det er den einaste vegen til ei reell årsak.

Filnamnet ber også historie: NSS skil dei gamle cert8.db og key3.db frå SQLite-baserte cert9.db og key4.db. Skriv ned logglinja du såg før frysinga, for det er det einaste varige beviset du har.

Kva profil klienten faktisk opnar

Identifiser klienten, autentiseringsmetoden og lageret han les. Her finst tre innloggingsvegar: nettlesarassistert, innebygd nettlesar og opphavleg klient, og dei treng ikkje dela profil. Ein database med rett namn i ei anna mappe er ikkje bevis for at den frosne prosessen opna han. På Linux ligg NSS-lageret vanlegvis under ~/.pki/nssdb til brukaren eller i ei programprofilmappe. Begge oppsetta kan finnast på same maskin, så kontroller begge viss migreringa er nyleg.

List opp kva lageret inneheld før du endrar det: certutil -L -d sql:$HOME/.pki/nssdb skriv ut sertifikata, og same verktøy med -K viser om det finst nøklar.

Viss kommandoen melder at databasen ikkje kan opnast, har du funne profilen verktøyet brukar, men ikkje nødvendigvis den VPN brukte.

Ta tryggleikskopi av profilen før kvar reparasjon

Lat att dei råka programma, og kopier deretter heile profilmappa med den godkjende tryggleikskopimetoden. Sertifikat- og nøkkeldatabasar er skyld, men skild tilstand, og å lagra éi vilkårleg fil er ikkje ein attopprettingsplan for heile identiteten. Vern om kopien, for profilen kan innehalda private nøklar. Skriv ned kva du tryggleikskopierte og kvar, slik at ein mislukka reparasjon har ein veg tilbake.

Stadfest deretter det nøyaktige omfanget av reparasjonen med vedlikehaldaren. Ei full tilbakestilling av lageret, fjerning av eitt kjent utdatert sertifikat og reparasjon av ein nettlesarprofil er tre ulike endringar med tre ulike risikoar.

Etter reparasjonen, logg inn og undersøk lageret

Etter ein autorisert reparasjon, logg inn på VPN og stadfest at servercertifikatet framleis blir validert som tenkt. Kontroller at identitetane arbeidsflyten treng framleis finst, og at ingen uventa tillitsanker har dukka opp. Ein reparasjon som får sambandet til å verka ved å stola meir enn før, er ikkje ein reparasjon.

Hald observasjon og instruksjon skilde: éi sletting og éin vellukka oppstart er ikkje ei generell løysing.

Kjem frysinga attende, fang klientloggen og profilen som blir brukt før du endrar noko anna. Den registreringa er det som gjer ei gissing til ein diagnose.