A revogação de certificados falha: qual host não alcança o quê

Os certificados podem estar dentro do período de validade e mesmo assim a VPN relatar uma falha de autenticação, e alguém conclui que o certificado foi revogado. São três factos diferentes. Os dados de revogação têm de ser obtidos pelo dispositivo que faz a validação, a partir de um ponto de publicação indicado dentro do próprio certificado. Quando esse dispositivo não alcança o ponto, a verificação falha por motivos alheios ao estado do certificado.

O validador é dono do caminho de obtenção

Comece por identificar o validador. Quando um portátil verifica o certificado da gateway, é o portátil que obtém os dados; quando a gateway verifica um certificado de cliente, é a gateway que o faz. Um serviço de autenticação no back-end pode acrescentar um terceiro validador com a sua própria posição na rede. Cada um tem uma rota diferente para a Internet e uma configuração de proxy diferente. Provas recolhidas na estação de trabalho de um administrador nada dizem sobre um servidor dentro de uma DMZ.

Registe o certificado, o validador, a hora da tentativa e o código de estado exato antes de alterar seja o que for.

Leia o ponto de publicação a partir do certificado

O certificado indica onde reside o seu estado. Leia esses campos em vez de adivinhar um endereço de CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

A primeira extensão lista pontos de distribuição de CRL e a segunda lista métodos de acesso à informação da autoridade, que podem abranger o estado OCSP e a obtenção do certificado do emissor. São mecanismos diferentes, e um respondedor OCSP não é um ficheiro CRL. O host de publicação é muitas vezes um servidor web comum e não a máquina da CA, porque um emissor offline pode assinar uma CRL que outro servidor distribui. Uma regra de firewall descrita como acesso à CA é, por isso, demasiado vaga para implementar ou rever.

Teste a obtenção a partir do dispositivo que valida

Execute o teste de obtenção no ambiente que faz realmente a validação, com material de certificado aprovado e sem chaves privadas.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

A execução do certutil verifica a cadeia e indica que obtenções de URL tiveram êxito ou falharam, enquanto a chamada curl testa um endereço de publicação a partir do mesmo host e devolve apenas um código de estado. Uma obtenção falhada a partir de um endereço alcançável aponta para problemas de conteúdo ou de assinatura; um erro de ligação aponta para encaminhamento, DNS ou proxy. Guarde ambos os resultados, porque uma obtenção bem-sucedida não prova que toda a cadeia é utilizável. Substitua o host e o caminho de exemplo pelo ponto de distribuição encontrado no certificado.

Separe dados em falta de estado revogado

Quatro desfechos parecem iguais vistos de fora: o ponto está inacessível, a lista está desatualizada, a lista está assinada pelo emissor errado ou o certificado está mesmo revogado. Só o último é um resultado de estado, e só ele justifica retirar o acesso. A colocação em cache complica ainda mais o quadro, porque dados obtidos antes podem esconder um caminho de publicação avariado até à atualização seguinte. Desativar a verificação de revogação, apagar certificados alheios ou reiniciar a gateway substituem o diagnóstico por atividade.

Depois da correção, force uma nova autenticação e confirme que a obtenção de estado pretendida tem êxito. Onde existir uma identidade de teste controlada, confirme que continua a ser rejeitada, porque disponibilidade que elimina a verificação não é uma reparação.