cert8.db är inte en engångscache: kontrollera ägaren till lagret
Att radera cert8.db ändrar beständigt säkerhetstillstånd, inte en sidcache. Hitta profilen som klienten öppnar, säkerhetskopiera och reparera bara det som är godkänt.
En gammal supporttråd säger att man ska radera en fil som heter cert8.db, och VPN fungerar igen. Den ordningen är oftare en slump än en reparation. Filen är en certifikatdatabas, och att ta bort den ändrar beständigt säkerhetstillstånd på sätt som en lyckad start inte avslöjar.
En fryst inloggning är inte ett cacheproblem
En webbläsarcache lagrar kopior av resurser; en certifikatdatabas lagrar förtroendebeslut, certifikat och nycklarna som hör till. Att radera den andra ligger närmare en återställning av identitet än en rensning av historik. Om klienten frös under inloggningen är det användbara beviset vilken process som öppnade vilken profil och vad den loggade, inte vilken fil ett foruminlägg tog bort. Att återskapa frysningen och läsa klientloggen tar längre tid än att radera en fil, och det är den enda vägen till en verklig orsak.
Filnamnet bär också historia: NSS skiljer de gamla cert8.db och key3.db från SQLite-baserade cert9.db och key4.db. Skriv ner loggraaden du såg före frysningen, för det är det enda varaktiga beviset du har.
Vilken profil klienten faktiskt öppnar
Identifiera klienten, dess autentiseringsmetod och lagret den läser. Här finns tre inloggningsvägar: webbläsarstödd, inbäddad webbläsare och inbyggd klient, och de behöver inte dela profil. En databas med rätt namn i en annan katalog är inte bevis för att den frysta processen öppnade den. På Linux ligger NSS-lagret vanligtvis under användarens ~/.pki/nssdb eller i en programprofilmapp. Båda uppläggen kan finnas på samma maskin, så kontrollera båda om migreringen är ny.
Lista vad lagret innehåller innan du ändrar det: certutil -L -d sql:$HOME/.pki/nssdb skriver ut certifikaten, och samma verktyg med -K visar om nycklar finns.
Om kommandot rapporterar att databasen inte kan öppnas har du hittat profilen som verktyget använder, men inte nödvändigtvis den VPN använde.
Säkerhetskopiera profilen före varje reparation
Stäng de berörda programmen och kopiera sedan hela profilmappen med den godkända säkerhetskopieringsmetoden. Certifikat- och nyckeldatabaser är besläktat men åtskilt tillstånd, och att spara en godtycklig fil är inte en återställningsplan för hela identiteten. Skydda kopian, eftersom profilen kan innehålla privata nycklar. Skriv ner vad du säkerhetskopierade och var, så att en misslyckad reparation har en väg tillbaka.
Bekräfta sedan reparationens exakta omfattning med underhållaren. En fullständig återställning av lagret, borttagning av ett känt föråldrat certifikat och en reparation av en webbläsarprofil är tre olika ändringar med tre olika risker.
Logga in och granska lagret efter reparationen
Efter en auktoriserad reparation, logga in på VPN och bekräfta att serverns certifikat fortfarande valideras som avsett. Kontrollera att identiteterna arbetsflödet behöver finns kvar och att ingen oväntad förtroendeankare dykt upp. En reparation som får anslutningen att fungera genom att lita mer än tidigare är ingen reparation.
Håll observation och instruktion åtskilda: en radering och en lyckad start är ingen allmän lösning.
Om frysningen återkommer, fånga klientloggen och profilen som används innan du ändrar något annat. Den registreringen är det som gör en gissning till en diagnos.