cert8.db er ikke en engangscache: kontrollér lagerets ejer

En gammel supporttråd siger, at man skal slette en fil med navnet cert8.db, og så virker VPN igen. Den rækkefølge er oftere et sammentræf end en rettelse. Filen er en certifikatdatabase, og fjernelse af den ændrer vedvarende sikkerhedstilstand på måder, som en vellykket opstart ikke afslører.

Et frosset login er ikke et cacheproblem

En browsercache gemmer kopier af ressourcer; en certifikatdatabase gemmer tillidsbeslutninger, certifikater og de nøgler, der hører til. At slette den anden er tættere på at nulstille en identitet end på at rydde historik. Hvis klienten frøs under login, er det nyttige bevis, hvilken proces der åbnede hvilken profil, og hvad den loggede, ikke hvilken fil et forumindlæg fjernede. At genskabe frysningen og læse klientloggen tager længere tid end at slette en fil, og det er den eneste vej til en egentlig årsag.

Filnavnet bærer også historie: NSS skelner mellem de gamle cert8.db og key3.db og SQLite-baserede cert9.db og key4.db. Skriv loglinjen ned, som du så før frysningen, for det er det eneste varige bevis, du har.

Hvilken profil åbner klienten egentlig

Identificér klienten, dens godkendelsesmetode og det lager, den læser. Der findes tre loginveje her: browserassisteret, indlejret browser og native klient, og de behøver ikke dele profil. En database med det rigtige navn i en anden mappe er ikke bevis for, at den frosne proces åbnede den. På Linux ligger NSS-lageret normalt under brugerens ~/.pki/nssdb eller i en programprofilmappe. De to opsætninger kan sameksistere på samme maskine, så kontrollér begge, hvis migreringen er ny.

Liste over, hvad lageret indeholder, før du ændrer det: certutil -L -d sql:$HOME/.pki/nssdb udskriver certifikaterne, og det samme værktøj med -K viser, om der er nøgler.

Hvis kommandoen melder, at databasen ikke kan åbnes, har du fundet den profil, værktøjet bruger, men ikke nødvendigvis den, VPN brugte.

Tag en sikkerhedskopi af profilen før enhver reparation

Luk de berørte programmer, og kopiér derefter hele profilmappen med den godkendte backupmetode. Certifikat- og nøgledatabaser er beslægtet, men adskilt tilstand, og at gemme én vilkårlig fil er ikke en gendannelsesplan for hele identiteten. Beskyt kopien, for profilen kan indeholde private nøgler. Skriv ned, hvad du sikkerhedskopierede og hvor, så en mislykket reparation har en vej tilbage.

Bekræft derefter reparationens præcise omfang med vedligeholderen. En fuld nulstilling af lageret, fjernelse af ét kendt forældet certifikat og reparation af en browserprofil er tre forskellige ændringer med tre forskellige risici.

Efter reparationen, log ind og undersøg lageret

Efter en autoriseret reparation, log ind på VPN og bekræft, at servercertifikatet stadig valideres som tiltænkt. Kontrollér, at de identiteter, arbejdsgangen kræver, stadig er der, og at der ikke er dukket et uventet tillidsanker op. En reparation, der får forbindelsen til at virke ved at stole mere end før, er ikke en reparation.

Hold observation og instruktion adskilt: én sletning efterfulgt af én vellykket opstart er ikke en generel løsning.

Hvis frysningen vender tilbage, fang klientloggen og den anvendte profil, før du ændrer noget andet. Den registrering er det, der gør et gæt til en diagnose.