cert8.db no és una memòria cau d’un sol ús: comproveu el propietari del magatzem
Suprimir cert8.db canvia l’estat de seguretat persistent, no la memòria cau d’una pàgina. Trobeu el perfil que obre el client, feu-ne una còpia i repareu només el que estigui aprovat.
Un fil de suport antic diu que suprimiu un fitxer anomenat cert8.db i el VPN torna a funcionar. Aquesta seqüència és una coincidència més sovint que una reparació. El fitxer és una base de dades de certificats, i eliminar-lo canvia l’estat de seguretat persistent de maneres que un arrencament correcte no revela.
Una connexió blocada no és un problema de memòria cau
La memòria cau del navegador desa còpies de recursos; la base de dades de certificats desa decisions de confiança, certificats i les claus que els acompanyen. Suprimir la segona s’acosta més a reiniciar una identitat que a esborrar l’historial. Si el client es va bloquejar durant l’inici de sessió, l’evidència útil és quin procés va obrir quin perfil i què va registrar, no quin fitxer va eliminar una publicació d’un fòrum. Reproduir el bloqueig i llegir el registre del client triga més que suprimir un fitxer, i és l’únic camí cap a una causa real.
El nom del fitxer també porta història: NSS distingeix els antics cert8.db i key3.db dels cert9.db i key4.db d’SQLite. Anoteu la línia de registre que vau veure abans del bloqueig, perquè és l’única evidència duradora que teniu.
Quin perfil obre realment el client
Identifiqueu el client, el mètode d’autenticació i el magatzem que llegeix. Aquí hi ha tres camins d’inici de sessió: assistit pel navegador, navegador incrustat i client natiu, i no cal que comparteixin perfil. Una base de dades amb el nom correcte en un altre directori no demostra que el procés bloquejat l’hagués obert. A Linux, el magatzem NSS sol viure sota ~/.pki/nssdb de l’usuari o en un directori de perfil per aplicació. Les dues disposicions poden coexistir en una màquina, així que comproveu-les totes dues si la migració és recent.
Lliste que conté el magatzem abans de canviar-lo: certutil -L -d sql:$HOME/.pki/nssdb imprimeix els certificats, i la mateixa eina amb -K mostra si hi ha claus.
Si l’ordre informa que la base de dades no es pot obrir, heu trobat el perfil que fa servir l’eina, no necessàriament el que va fer servir el VPN.
Feu una còpia de seguretat del perfil abans de qualsevol reparació
Tanqueu les aplicacions afectades i després copieu tot el directori del perfil amb el mètode de còpia aprovat. Les bases de dades de certificats i de claus són estat relacionat però distint, i desar un fitxer arbitrari no és un pla de recuperació per a tota la identitat. Protegiu la còpia, perquè el perfil pot contenir claus privades. Anoteu què heu copiat i on, perquè una reparació fallida tingui camí de tornada.
Després confirmeu l’abast exacte de la reparació amb el mantenidor. Reiniciar tot el magatzem, retirar un certificat obsolet conegut i reparar el perfil del navegador són tres canvis diferents amb tres riscos diferents.
Després de la reparació, inicieu sessió i inspeccioneu el magatzem
Després d’una reparació autoritzada, inicieu sessió al VPN i confirmeu que el certificat del servidor encara es valida com cal. Comproveu que les identitats que necessita el flux de treball hi són i que no ha aparegut cap àncora de confiança inesperada. Una reparació que fa funcionar la connexió confiant més que abans no és una reparació.
Manteniu l’observació i la instrucció separades: una supressió seguida d’un arrencament correcte no és una solució general.
Si el bloqueig torna, captureu el registre del client i el perfil en ús abans de canviar res més. Aquest registre és el que converteix una conjectura en un diagnòstic.