cert8.db no es una caché desechable: compruebe el propietario del almacén

Un hilo de soporte antiguo dice que se borre un archivo llamado cert8.db y el VPN vuelve a funcionar. Esa secuencia es una coincidencia más veces que una solución. El archivo es una base de datos de certificados, y eliminarlo cambia el estado de seguridad persistente de formas que un arranque correcto no revela.

Un inicio de sesión congelado no es un problema de caché

La caché del navegador guarda copias de recursos; la base de datos de certificados guarda decisiones de confianza, certificados y las claves asociadas. Borrar la segunda se acerca más a restablecer una identidad que a limpiar el historial. Si el cliente se congeló durante el inicio de sesión, la evidencia útil es qué proceso abrió qué perfil y qué registró, no qué archivo eliminó una publicación de un foro. Reproducir el bloqueo y leer el registro del cliente lleva más tiempo que borrar un archivo, y es el único camino hacia una causa real.

El nombre del archivo también lleva historia: NSS distingue los antiguos cert8.db y key3.db de los cert9.db y key4.db de SQLite. Anote la línea de registro que vio antes del bloqueo, porque es la única evidencia duradera que tiene.

Qué perfil abre realmente el cliente

Identifique el cliente, su método de autenticación y el almacén que lee. Aquí existen tres rutas de inicio de sesión: asistida por navegador, navegador integrado y cliente nativo, y no tienen que compartir perfil. Una base de datos con el nombre correcto en otro directorio no demuestra que el proceso bloqueado la abriera. En Linux, el almacén NSS suele estar bajo ~/.pki/nssdb del usuario o en un directorio de perfil por aplicación. Ambas disposiciones pueden convivir en una máquina, así que compruebe las dos si la migración es reciente.

Enumere qué contiene el almacén antes de cambiarlo: certutil -L -d sql:$HOME/.pki/nssdb imprime los certificados, y la misma herramienta con -K muestra si hay claves.

Si el comando informa que la base de datos no se puede abrir, ha encontrado el perfil que usa la herramienta, no necesariamente el que usó el VPN.

Haga una copia de seguridad del perfil antes de cualquier reparación

Cierre las aplicaciones afectadas y luego copie todo el directorio del perfil con el método de copia aprobado. Las bases de datos de certificados y claves son estado relacionado pero distinto, y guardar un archivo arbitrario no es un plan de recuperación para toda la identidad. Proteja la copia, porque el perfil puede contener claves privadas. Anote qué copió y dónde, para que una reparación fallida tenga camino de vuelta.

Después confirme el alcance exacto de la reparación con el mantenedor. Restablecer todo el almacén, retirar un certificado obsoleto conocido y reparar un perfil de navegador son tres cambios distintos con tres riesgos distintos.

Tras la reparación, inicie sesión e inspeccione el almacén

Tras una reparación autorizada, inicie sesión en el VPN y confirme que el certificado del servidor sigue validándose como se pretende. Compruebe que las identidades que necesita el flujo de trabajo siguen presentes y que no ha aparecido un ancla de confianza inesperado. Una reparación que hace funcionar la conexión confiando más que antes no es una reparación.

Mantenga la observación y la instrucción separadas: un borrado seguido de un arranque correcto no es una solución general.

Si el bloqueo vuelve, capture el registro del cliente y el perfil en uso antes de cambiar nada más. Ese registro es lo que convierte una conjetura en un diagnóstico.