cert8.db is gjin weismytcache: kontrolearje de eigner fan it opslachplak

In âld stipe-tried seit dat jo in bestân mei de namme cert8.db fuortsmite moatte, en dan wurket de VPN wer. Dy folchoarder is faker tafal as in reparaasje. It bestân is in sertifikaatdatabase, en it fuortsmitsjen feroaret bliuwende befeiligingstastân op manieren dy’t in slagge start net sjen lit.

In beferzen oanmelding is gjin cacheprobleem

In browser-cache bewarret kopyen fan boarnen; in sertifikaatdatabase bewarret fertrouwensbesluten, sertifikaten en de kaaien dy’t dêrby hearre. It twadde fuortsmite is tichter by it weromsetten fan in identiteit as by it wiskjen fan skiednis. As de kliïnt by it oanmelden beferze, is it nuttige bewiis hokker proses hokker profyl iepene en wat it logge, net hokker bestân in forumberjocht fuortsmiten hat. It beferzen werhelje en it kliïntlog lêze duorret langer as it fuortsmitsjen fan in bestân, en it is it iennige paad nei in echte oarsaak.

De bestânsnamme draacht ek skiednis: NSS ûnderskiedt de âlde cert8.db en key3.db fan de SQLite cert9.db en key4.db. Skriuw de logrigel op dy’t jo foar it beferzen seagen, want dat is it iennige bliuwende bewiis dat jo hawwe.

Hokker profyl iepenet de kliïnt eins

Stel fêst hokker kliïnt it is, hokker autentikaasjemetoade dy brûkt en hokker opslachplak dy lêst. Hjir binne trije oanmeldroutes: mei help fan de browser, ynboude browser en native kliïnt, en dy hoege gjin profyl te dielen. In database mei de goede namme yn in oare map is gjin bewiis dat it beferzen proses dy iepene hat. Op Linux sit it NSS-opslachplak meast ûnder ~/.pki/nssdb fan de brûker of yn in profylmap per applikaasje. Beide yndielings kinne op ien masjine bestean, kontrolearje dus beide as de migraasje resint is.

List op wat it opslachplak befettet foar’t jo it feroarje: certutil -L -d sql:$HOME/.pki/nssdb printsje de sertifikaten, en itselde helpmiddel mei -K lit sjen oft der kaaien binne.

As it kommando seit dat de database net iepen kin wurde, hawwe jo it profyl fûn dat it helpmiddel brûkt, net needsaaklik dat fan de VPN.

Meitsje in reservekopy fan it profyl foar elke reparaasje

Slút de troffen applikaasjes, kopiearje dan de hiele profylmap mei de goedkarde reservekopymetoade. Sertifikaat- en kaaidatabases binne ferbûn mar aparte tastân, en it bewarjen fan ien willekeurich bestân is gjin herstelplan foar de hiele identiteit. Beskermje de kopy, want it profyl kin partikuliere kaaien befetsje. Skriuw op wat jo reservekopiearre hawwe en wêr, sadat in mislearre reparaasje in paad werom hat.

Befêstigje dan de krekte omfang fan de reparaasje mei de behearder. In folsleine weromset fan it opslachplak, it fuortheljen fan ien bekend ferâldere sertifikaat en in browserprofylreparaasje binne trije ferskillende feroarings mei trije ferskillende risiko’s.

Nei de reparaasje, meld jo oan en ynspektearje it opslachplak

Nei in autorisearre reparaasje, meld jo oan by de VPN en befêstigje dat it sertifikaat fan de tsjinner noch altyd wurdt falidearre sa’t bedoeld. Kontrolearje dat de identiteiten dy’t de wurkstream nedich hat der noch binne en dat der gjin ûnferwachte fertrouwensanker ferskynd is. In reparaasje dy’t de ferbining wurkje lit troch mear te fertrouwen as earder is gjin reparaasje.

Hâld de observaasje en de ynstruksje apart: ien fuortsmitsjen folge fan ien slagge start is gjin algemiene oplossing.

As it beferzen weromkomt, fetsje it kliïntlog en it brûkte profyl foar’t jo eat oars feroarje. Dat ferslach is wat in gissing yn in diagnoaze feroaret.