Mesmo nome de arquivo ca.crt, certificado diferente: o que comparar

Dois perfis trazem ambos um arquivo chamado ca.crt, um túnel sobe e o outro falha com um erro de cadeia. Abrir os dois arquivos lado a lado raramente resolve a questão, e desativar a verificação resolve-a na direção errada. A pergunta que o erro na verdade faz é mais estreita: qual certificado cada processo carrega como sua âncora de confiança, e são os dois o mesmo objeto? Responda a isso primeiro e o resto do diagnóstico ganha direção. O nome do arquivo é um rótulo de empacotamento, e o caminho escrito no perfil também não é autoritativo, então tudo depende do que o processo realmente lê.

Encontre o certificado que o cliente realmente carrega

OpenVPN aceita a autoridade em duas formas, e a forma decide quais bytes importam. Um perfil pode apontar para um arquivo externo com ca, ou incorporar o certificado num bloco <ca> no próprio perfil. Quando existem ambos, o bloco incorporado ganha e o arquivo ao lado do perfil nunca é aberto.

Leia o perfil que falha e descubra qual forma ele usa antes de comparar qualquer coisa. Uma cópia tirada de um diretório vizinho, ou do pacote de onde veio o outro perfil, não lhe diz nada sobre aquilo em que este processo confia. O mesmo vale para o caminho na configuração: ele é resolvido em relação ao local onde o cliente foi iniciado, que nem sempre é o diretório que está a ver. Leia o perfil, não a pasta.

Os certificados são identificados pelo seu conteúdo: a chave pública, o sujeito e o emissor, a janela de validade e a assinatura sobre tudo isso. Dois arquivos com bytes idênticos são o mesmo certificado seja qual for o nome, e dois arquivos com o mesmo nome podem ser autoridades sem relação. O nome é um rótulo de empacotamento, não uma identidade.

Tire a impressão digital das duas cópias com openssl

Uma impressão digital é um hash sobre a codificação DER do certificado, a forma que a assinatura cobre, portanto as terminações de linha e o texto do cabeçalho não a podem afetar. Calcule-a para cada arquivo e terá duas cadeias hexadecimais separadas por dois pontos que ou coincidem ou não. Não é preciso ler mais nada no certificado para responder à pergunta da comparação.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

É tentador apontar openssl ao próprio perfil, mas ele lê o primeiro bloco de certificado que aparece no arquivo, e um perfil normalmente traz <cert> antes de <ca>. Extraia o bloco da autoridade e depois tire a impressão digital do arquivo extraído, porque é essa a cópia que o cliente usará de facto.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Impressões digitais idênticas significam que o material de confiança é o mesmo e que o erro de cadeia tem outra causa, o que é outra investigação. Impressões digitais diferentes significam certificados diferentes, e é aí que começa a secção seguinte.

Leia uma discrepância antes de supor um ataque

Impressões digitais diferentes significam certificados diferentes e nada mais. Uma reemissão, uma rotação, uma autoridade renomeada ou um pacote desatualizado produzem todos arquivos diferentes com histórias completamente legítimas. Qual deles pertence à implantação é uma pergunta para o operador ou para o registo de implantação, não para a hora de modificação do arquivo. Os arquivos de arquivo copiam carimbos de data e hora, pelo que um arquivo mais recente não é automaticamente a âncora correta.

Uma raiz que se assina a si mesma é normal, portanto encontrar uma não é prova de um problema. A tarefa do verificador é construir um caminho desde o certificado do servidor até à âncora que lhe foi entregue, e um erro de cadeia normalmente significa que esse caminho não pôde ser concluído.

Verifique se a âncora do perfil que falha é uma autoridade de onde a implantação ainda emite. Se a impressão digital não coincide com nada no registo de implantação, o perfil está simplesmente desatualizado, e nenhum ajuste do lado do cliente o corrigirá.

Repare a confiança sem desativar a verificação

A correção a curto prazo é desativar a verificação ou adicionar cada certificado da cadeia como âncora. Ambas fazem a mensagem desaparecer, e ambas mudam quais servidores o cliente aceitará a partir de então. Volte a ativar a verificação, instale a âncora pretendida e teste novamente.

Se a cadeia agora é construída mas aparece outro erro, isso é progresso: a verificação do nome, as datas de validade e a revogação são verificações separadas com mensagens separadas. Mantenha o par de impressões digitais e o texto original do erro juntos no ticket, para que a pessoa seguinte veja qual âncora foi carregada e qual era esperada. Um par de impressões digitais é suficientemente pequeno para colar numa nota de passagem, e a ocorrência seguinte passa então a levar cinco minutos em vez de uma tarde.

Obtenha a autoridade correta pelo mesmo canal autenticado que entregou o perfil. Retirar um certificado do servidor porque o seu sujeito parece familiar é um ato diferente, e alarga silenciosamente aquilo em que o cliente confiará.