cert8.db não é um cache descartável: verifique o dono do armazém

Um tópico de suporte antigo manda apagar um arquivo chamado cert8.db e o VPN volta a funcionar. Essa sequência é mais vezes coincidência do que correção. O arquivo é um banco de certificados, e removê-lo altera estado de segurança persistente de formas que uma inicialização bem-sucedida não revela.

Um login travado não é problema de cache

O cache do navegador guarda cópias de recursos; o banco de certificados guarda decisões de confiança, certificados e as chaves associadas. Apagar o segundo está mais perto de redefinir uma identidade do que de limpar o histórico. Se o cliente travou durante o login, a evidência útil é qual processo abriu qual perfil e o que registrou, não qual arquivo uma postagem de fórum removeu. Reproduzir o travamento e ler o log do cliente leva mais tempo do que apagar um arquivo, e é o único caminho para uma causa real.

O nome do arquivo também carrega história: o NSS distingue os antigos cert8.db e key3.db dos cert9.db e key4.db do SQLite. Anote a linha de log que viu antes do travamento, porque é a única evidência duradoura que você tem.

Qual perfil o cliente realmente abre

Identifique o cliente, o método de autenticação e o armazém que ele lê. Existem três caminhos de login aqui: assistido pelo navegador, navegador embutido e cliente nativo, e eles não precisam compartilhar perfil. Um banco com o nome correto em outro diretório não prova que o processo travado o abriu. No Linux, o armazém NSS costuma ficar sob ~/.pki/nssdb do usuário ou em um diretório de perfil por aplicação. Os dois arranjos podem coexistir na mesma máquina, então verifique ambos se a migração for recente.

Liste o que o armazém contém antes de alterá-lo: certutil -L -d sql:$HOME/.pki/nssdb imprime os certificados, e a mesma ferramenta com -K mostra se há chaves.

Se o comando informar que o banco não pode ser aberto, você encontrou o perfil usado pela ferramenta, não necessariamente o que o VPN usou.

Faça cópia de segurança do perfil antes de qualquer reparo

Feche as aplicações afetadas e copie todo o diretório do perfil pelo método de backup aprovado. Bancos de certificados e chaves são estado relacionado mas distinto, e salvar um arquivo arbitrário não é um plano de recuperação para toda a identidade. Proteja a cópia, porque o perfil pode conter chaves privadas. Anote o que e onde você fez backup, para que um reparo malsucedido tenha caminho de volta.

Depois confirme o escopo exato do reparo com o mantenedor. Redefinir todo o armazém, remover um certificado obsoleto conhecido e reparar um perfil de navegador são três mudanças diferentes com três riscos diferentes.

Após o reparo, faça login e inspecione o armazém

Após um reparo autorizado, faça login no VPN e confirme que o certificado do servidor ainda é validado como pretendido. Verifique se as identidades de que o fluxo de trabalho precisa continuam presentes e se não apareceu uma âncora de confiança inesperada. Um reparo que faz a conexão funcionar confiando mais do que antes não é um reparo.

Mantenha observação e instrução separadas: uma remoção seguida de uma inicialização bem-sucedida não é uma solução geral.

Se o travamento voltar, capture o log do cliente e o perfil em uso antes de mudar qualquer outra coisa. Esse registro é o que transforma um palpite em diagnóstico.