cert8.db is geen wegwerpcache: controleer de eigenaar van de opslag

Een oude supportthread zegt dat je een bestand met de naam cert8.db moet verwijderen, en de VPN werkt weer. Die volgorde is vaker toeval dan een reparatie. Het bestand is een certificaatdatabase, en het verwijderen ervan verandert blijvende beveiligingstoestand op manieren die een geslaagde start niet laat zien.

Een vastgelopen login is geen cacheprobleem

Een browsercache bewaart kopieën van bronnen; een certificaatdatabase bewaart vertrouwensbeslissingen, certificaten en de sleutels die daarbij horen. De tweede verwijderen lijkt meer op het resetten van een identiteit dan op het wissen van geschiedenis. Als de client tijdens het inloggen vastliep, is het nuttige bewijs welk proces welk profiel opende en wat het logde, niet welk bestand een forumbericht verwijderde. Het vastlopen reproduceren en het clientlog lezen duurt langer dan een bestand verwijderen, en het is de enige weg naar een echte oorzaak.

De bestandsnaam draagt ook geschiedenis: NSS onderscheidt de oude cert8.db en key3.db van de SQLite cert9.db en key4.db. Noteer de logregel die je voor het vastlopen zag, want dat is het enige blijvende bewijs dat je hebt.

Welk profiel de client werkelijk opent

Identificeer de client, de authenticatiemethode en de opslag die hij leest. Er zijn hier drie inlogroutes: browserondersteund, ingebedde browser en native client, en ze hoeven geen profiel te delen. Een database met de juiste naam in een andere map is geen bewijs dat het vastgelopen proces die heeft geopend. Op Linux staat de NSS-opslag meestal onder ~/.pki/nssdb van de gebruiker of in een profielmap per toepassing. Beide indelingen kunnen op één machine bestaan, dus controleer beide als de migratie recent is.

Noem wat de opslag bevat voordat je hem wijzigt: certutil -L -d sql:$HOME/.pki/nssdb drukt de certificaten af, en hetzelfde gereedschap met -K laat zien of er sleutels zijn.

Als de opdracht meldt dat de database niet kan worden geopend, heb je het profiel gevonden dat het gereedschap gebruikt, maar niet noodzakelijk dat de VPN gebruikte.

Maak een back-up van het profiel voor elke reparatie

Sluit de getroffen toepassingen en kopieer vervolgens de hele profielmap met de goedgekeurde back-upmethode. Certificaat- en sleuteldatabases zijn verwante maar aparte toestand, en één willekeurig bestand opslaan is geen herstelplan voor de hele identiteit. Bescherm de kopie, want het profiel kan privésleutels bevatten. Noteer wat je waar hebt geback-upt, zodat een mislukte reparatie een weg terug heeft.

Bevestig daarna de exacte omvang van de reparatie met de beheerder. Een volledige reset van de opslag, het verwijderen van één bekend verouderd certificaat en een reparatie van een browserprofiel zijn drie verschillende wijzigingen met drie verschillende risico’s.

Log na de reparatie in en inspecteer de opslag

Log na een geautoriseerde reparatie in bij de VPN en bevestig dat het servercertificaat nog steeds wordt gevalideerd zoals bedoeld. Controleer dat de identiteiten die de workflow nodig heeft er nog zijn en dat er geen onverwachte vertrouwensanker is verschenen. Een reparatie die de verbinding laat werken door meer te vertrouwen dan voorheen is geen reparatie.

Houd waarneming en instructie gescheiden: één verwijdering en één geslaagde start zijn geen algemene oplossing.

Keert het vastlopen terug, leg dan het clientlog en het gebruikte profiel vast voordat je iets anders wijzigt. Dat vastleggen maakt van een gok een diagnose.