cert8.db n’est pas un cache jetable : vérifiez le propriétaire du magasin

Un ancien fil d’assistance conseille de supprimer un fichier nommé cert8.db, et le VPN se remet à fonctionner. Cette séquence est plus souvent une coïncidence qu’une réparation. Le fichier est une base de certificats, et le retirer modifie un état de sécurité persistant d’une manière qu’un lancement réussi ne révèle pas.

Une connexion figée n’est pas un problème de cache

Un cache de navigateur stocke des copies de ressources ; une base de certificats stocke des décisions de confiance, des certificats et les clés associées. Supprimer la seconde relève davantage d’une réinitialisation d’identité que d’un effacement d’historique. Si le client s’est figé pendant la connexion, la preuve utile est quel processus a ouvert quel profil et ce qu’il a journalisé, pas quel fichier un message de forum a supprimé. Reproduire le blocage et lire le journal du client prend plus de temps que supprimer un fichier, et c’est la seule voie vers une cause réelle.

Le nom du fichier porte aussi une histoire : NSS distingue les anciens cert8.db et key3.db des cert9.db et key4.db de SQLite. Notez la ligne de journal vue avant le blocage, car c’est la seule preuve durable dont vous disposez.

Quel profil le client ouvre-t-il réellement

Identifiez le client, sa méthode d’authentification et le magasin qu’il lit. Trois voies de connexion existent ici : assistée par navigateur, navigateur intégré et client natif, et elles n’ont pas à partager un profil. Une base portant le bon nom dans un autre répertoire ne prouve pas que le processus figé l’a ouverte. Sous Linux, le magasin NSS se trouve généralement sous ~/.pki/nssdb de l’utilisateur ou dans un répertoire de profil propre à l’application. Les deux dispositions peuvent coexister sur une machine, vérifiez donc les deux si la migration est récente.

Listez le contenu du magasin avant de le modifier : certutil -L -d sql:$HOME/.pki/nssdb affiche les certificats, et le même outil avec -K indique si des clés sont présentes.

Si la commande signale que la base ne peut pas être ouverte, vous avez trouvé le profil utilisé par l’outil, pas nécessairement celui qu’a utilisé le VPN.

Sauvegardez le profil avant toute réparation

Fermez les applications concernées, puis copiez tout le répertoire de profil avec la méthode de sauvegarde approuvée. Les bases de certificats et de clés sont un état lié mais distinct, et sauvegarder un fichier arbitraire n’est pas un plan de restauration pour toute l’identité. Protégez la copie, car le profil peut contenir des clés privées. Notez ce que vous avez sauvegardé et où, afin qu’une réparation ratée ait un chemin de retour.

Confirmez ensuite la portée exacte de la réparation avec le mainteneur. Une réinitialisation complète du magasin, le retrait d’un certificat obsolète connu et une réparation de profil de navigateur sont trois changements différents avec trois risques différents.

Après la réparation, connectez-vous et inspectez le magasin

Après une réparation autorisée, connectez-vous au VPN et confirmez que le certificat du serveur est toujours validé comme prévu. Vérifiez que les identités nécessaires au flux de travail sont toujours présentes et qu’aucune ancre de confiance inattendue n’est apparue. Une réparation qui fait fonctionner la connexion en faisant davantage confiance qu’avant n’est pas une réparation.

Gardez l’observation et la consigne séparées : une suppression suivie d’un lancement réussi n’est pas une solution générale.

Si le blocage revient, capturez le journal du client et le profil utilisé avant de changer quoi que ce soit d’autre. C’est ce relevé qui transforme une supposition en diagnostic.