Incompatibilidade de nome ou expiração do certificado: distingui-las

Duas falhas de VPN parecem idênticas da cadeira do utilizador e exigem correções opostas. Uma incompatibilidade de nome diz que o certificado é válido mas emitido para outra coisa. Um erro de expiração diz que o certificado não é válido neste momento. Nenhuma delas é um problema de palavra-passe, e repor as credenciais é a hora mais desperdiçada em ambos os casos. Leia a etapa que falha antes de tocar em qualquer coisa.

O texto do erro é o diagnóstico

O cliente diz-lhe qual verificação falhou, mesmo quando a mensagem é breve. Uma incompatibilidade nomeia o nome de anfitrião esperado e o nome encontrado. Um erro de expiração menciona datas de validade ou uma hora. Essas duas frases apontam para partes diferentes do certificado.

Leia-as na etapa em que aparecem. Uma falha durante o handshake é um problema de certificado; uma falha depois de o túnel estar ativo é um problema de encaminhamento ou de credenciais. Reter a etapa é o que impede a investigação de derivar para definições não relacionadas.

Se a falha varia entre tentativas, tem uma terceira possibilidade: mais do que um nó atrás do mesmo nome.

Verificações de nome: o que o cliente compara

O cliente compara a identidade que está configurado para esperar com os nomes no certificado, que estão na extensão subjectAltName. Um IP em bruto no perfil, um alias que o certificado não lista, ou um nome que apenas resolve para o mesmo servidor — todos falham esta verificação. Alcançar a máquina certa não é o mesmo que apresentar a identidade certa.

Inspecione o certificado que o servidor realmente apresenta em vez de um ficheiro de uma tentativa anterior. O comando abaixo pede o nome que configurou, por isso a resposta inclui o certificado que um cliente real veria.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Um certificado de um emissor de confiança pode ainda ser para outro serviço. Mantenha as verificações de nome do cliente ativas, porque confiar numa CA não autoriza todos os nomes que essa CA alguma vez assinou. Desativar a verificação transforma um erro de configuração numa exposição.

Expiração: de quem é o relógio que se lê

A validade é um par de marcas temporais, e o verificador compara-as com o seu próprio relógio. Um dispositivo com o relógio errado reporta um certificado válido como expirado ou como ainda não válido, e a correção é o relógio, não o certificado. Uma diferença de apresentação de fuso horário não é o mesmo que uma hora subjacente errada.

Compare as datas do certificado com UTC no cliente antes de concluir seja o que for:

openssl x509 -in cert.pem -noout -dates
date -u

Se as datas realmente passaram, renove através do emissor. Se existir um substituto mas ainda não for válido, siga a transição suportada em vez de mover o relógio para o acomodar. Recuar a data de um dispositivo para satisfazer um certificado é uma decisão com consequências muito para além do túnel.

Porque corrigir um expõe o outro

A validação executa uma sequência de verificações, e a primeira falha interrompe o relatório. Corrija o nome e o cliente pode então dizer-lhe que a cadeia está incompleta ou que o certificado expirou. Isso não significa que a primeira verificação fosse desnecessária. Significa que a cadeia tinha mais do que um problema, por isso espere o segundo erro em vez de o ler como prova de que a primeira correção estava errada.

Vários nós pioram isto. Um serviço com balanceamento de carga pode apresentar certificados diferentes de membros diferentes, por isso um teste que passa duas vezes e falha uma está a falar-lhe da frota e não do seu cliente. Retenha o endereço do par e a hora da tentativa no diagnóstico.

É esse detalhe que transforma um ticket intermitente num ticket reproduzível.

Prove-o com uma conexão nova

Depois da reparação, abra uma conexão nova em vez de retomar uma antiga, e confirme que a etapa que falhava agora passa. Depois confirme que o túnel transporta realmente tráfego, porque um handshake bem-sucedido não é uma rota a funcionar.

Retenha a etapa exata do erro e os detalhes do certificado com o ticket.

Esse registo é o que impede a pessoa seguinte de repor palavras-passe de conta por um problema de certificado. Identidade e validade são questões separadas, e a RFC 5280 é a referência para a forma como a segunda é avaliada.