cert8.db Is Not a Throwaway Cache: Check the Store Owner

An old support thread says to delete a file called cert8.db, and the VPN starts working. That sequence is a coincidence more often than a fix. The file is a certificate database, and removing it changes persistent security state in ways a successful launch does not reveal.

A frozen login is not a cache problem

A browser cache stores copies of resources; a certificate database stores trust decisions, certificates, and the keys that go with them. Deleting the second is closer to resetting an identity than to clearing history. If the client froze during sign-in, the useful evidence is which process opened which profile and what it logged, not which file a forum post removed. Reproducing the freeze and reading the client log takes longer than deleting a file, and it is the only path to a real cause.

The filename also carries history: NSS distinguishes legacy cert8.db and key3.db from the SQLite cert9.db and key4.db. Write down the log line you saw before the freeze, because it is the only durable evidence you have.

Which profile does the client actually open

Identify the client, its authentication method, and the store it reads. Three sign-in paths exist here: browser-assisted, embedded browser, and native client, and they do not have to share a profile. A database with the right name in a different directory is not evidence that the frozen process opened it. On Linux, the NSS store usually lives under the user's ~/.pki/nssdb or a per-application profile directory. The two layouts can coexist on one machine, so check both when a migration is recent.

List what the store contains before changing it: certutil -L -d sql:$HOME/.pki/nssdb prints the certificates, and the same tool with -K shows whether keys are present.

If the command reports that the database cannot be opened, you have found the profile the tool uses, not necessarily the one the VPN used.

Back up the profile before any repair

Close the affected applications, then copy the entire profile directory through the approved backup method. Certificate and key databases are related but distinct state, and saving one arbitrary file is not a recovery plan for the whole identity. Protect the copy, because the profile can contain private keys. Record what you backed up and where, so a failed repair has a way back.

Then confirm the repair's exact scope with the maintainer. A full store reset, the removal of one known obsolete certificate, and a browser profile repair are three different changes with three different risks.

After the repair, sign in and inspect the store

After an authorized repair, sign in to the VPN and confirm the server certificate is still validated as intended. Check that the identities the workflow needs are still present, and that no unexpected trust anchor appeared. A repair that makes the connection work by trusting more than before is not a repair.

Keep the observation and the instruction separate: one deletion followed by one successful launch is not a general fix.

If the freeze returns, capture the client log and the profile in use before changing anything else. That record is what turns a guess into a diagnosis.