cert8.db non é unha caché dun só uso: comprobe o propietario do almacén

Un fío de soporte antigo di que se borre un ficheiro chamado cert8.db e o VPN volve funcionar. Esa secuencia é unha coincidencia máis veces que unha solución. O ficheiro é unha base de datos de certificados, e eliminalo cambia o estado de seguridade persistente de formas que un arranque correcto non revela.

Un inicio de sesión conxelado non é un problema de caché

A caché do navegador garda copias de recursos; a base de datos de certificados garda decisións de confianza, certificados e as chaves asociadas. Borrar a segunda achégase máis a restablecer unha identidade que a limpar o historial. Se o cliente se conxelou durante o inicio de sesión, a evidencia útil é que proceso abriu que perfil e que rexistrou, non que ficheiro eliminou unha publicación dun foro. Reproducir o bloqueo e ler o rexistro do cliente leva máis tempo que borrar un ficheiro, e é o único camiño cara a unha causa real.

O nome do ficheiro tamén leva historia: NSS distingue os antigos cert8.db e key3.db dos cert9.db e key4.db de SQLite. Anote a liña de rexistro que viu antes do bloqueo, porque é a única evidencia duradeira que ten.

Que perfil abre realmente o cliente

Identifique o cliente, o seu método de autenticación e o almacén que le. Aquí existen tres rutas de inicio de sesión: asistida por navegador, navegador integrado e cliente nativo, e non teñen que compartir perfil. Unha base de datos co nome correcto noutro directorio non demostra que o proceso bloqueado a abrise. En Linux, o almacén NSS adoita estar baixo ~/.pki/nssdb do usuario ou nun directorio de perfil por aplicación. Ambas as disposicións poden convivir nunha máquina, así que comprobe as dúas se a migración é recente.

Enumere que contén o almacén antes de cambialo: certutil -L -d sql:$HOME/.pki/nssdb imprime os certificados, e a mesma ferramenta con -K mostra se hai chaves.

Se a orde informa que a base de datos non se pode abrir, atopou o perfil que usa a ferramenta, non necesariamente o que usou o VPN.

Faga unha copia de seguridade do perfil antes de calquera reparación

Peche as aplicacións afectadas e despois copie todo o directorio do perfil co método de copia aprobado. As bases de datos de certificados e chaves son estado relacionado pero distinto, e gardar un ficheiro arbitrario non é un plan de recuperación para toda a identidade. Protexa a copia, porque o perfil pode conter chaves privadas. Anote que copiou e onde, para que unha reparación fallida teña camiño de volta.

Despois confirme o alcance exacto da reparación co mantenedor. Restablecer todo o almacén, retirar un certificado obsoleto coñecido e reparar un perfil de navegador son tres cambios distintos con tres riscos distintos.

Tras a reparación, inicie sesión e inspeccione o almacén

Tras unha reparación autorizada, inicie sesión no VPN e confirme que o certificado do servidor segue validándose como se pretende. Comprobe que as identidades que necesita o fluxo de traballo seguen presentes e que non apareceu un áncora de confianza inesperado. Unha reparación que fai funcionar a conexión confiando máis que antes non é unha reparación.

Manteña a observación e a instrución separadas: un borrado seguido dun arranque correcto non é unha solución xeral.

Se o bloqueo volve, capture o rexistro do cliente e o perfil en uso antes de cambiar nada máis. Ese rexistro é o que converte unha conxectura nun diagnóstico.