Discordancia de nome ou caducidade do certificado: como distinguilas

Dous fallos de VPN parecen idénticos desde a cadeira do usuario e requiren correccións opostas. Unha discordancia de nome indica que o certificado é válido pero emitido para outra cousa. Un erro de caducidade indica que o certificado non é válido neste momento. Ningún dos dous é un problema de contrasinal, e restablecer as credenciais é a hora máis desaproveitada en ambos os casos. Lea a etapa que falla antes de tocar nada.

O texto do erro é o diagnóstico

O cliente indica cal comprobación fallou, mesmo cando a mensaxe é escueta. Unha discordancia nomea o nome de host que esperaba e o nome que atopou. Un erro de caducidade menciona datas de validez ou unha hora. Esas dúas frases apuntan a partes distintas do certificado.

Léaas na etapa na que aparecen. Un fallo durante a negociación é un problema de certificado; un fallo despois de levantar o túnel é un problema de encamiñamento ou de credenciais. Conservar a etapa é o que evita que a investigación derive cara a axustes sen relación.

Se o fallo varía entre intentos, tes unha terceira posibilidade: máis dun nodo detrás do mesmo nome.

Comprobacións de nome: que compara o cliente

O cliente compara a identidade que está configurado para esperar cos nomes do certificado, que están na extensión subjectAltName. Un IP sen procesar no perfil, un alias que o certificado non lista, ou un nome que simplemente resolve ao mesmo servidor fallan todos esta comprobación. Chegar á máquina correcta non é o mesmo que presentar a identidade correcta.

Inspecciona o certificado que o servidor presenta de verdade en lugar dun ficheiro dun intento anterior. A orde de abaixo pide o nome que configuraches, así que a resposta inclúe o certificado que vería un cliente real.

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

Un certificado dun emisor de confianza pode ser aínda para outro servizo. Mantén activas as comprobacións de nome do cliente, porque confiar nunha CA non autoriza todos os nomes que esa CA asinou algunha vez. Desactivar a comprobación converte un erro de configuración nunha exposición.

Caducidade: de quen é o reloxo que se le

A validez é un par de marcas de tempo, e o verificador compáraas co seu propio reloxo. Un dispositivo cuxo reloxo está mal informa dun certificado válido como caducado ou como aínda non válido, e a corrección é o reloxo, non o certificado. Unha diferenza de visualización de fuso horario non é o mesmo que unha hora subxacente incorrecta.

Compara as datas do certificado con UTC no cliente antes de concluír nada:

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

Se as datas realmente pasaron, renova a través do emisor. Se existe un substituto pero aínda non é válido, segue a transición admitida en lugar de mover o reloxo para acomodalo. Antedatar un dispositivo para satisfacer un certificado é unha decisión con consecuencias moi por riba do túnel.

Por que arranxar un expón o outro

A validación executa unha secuencia de comprobacións, e o primeiro fallo detén o informe. Arranxa o nome e o cliente pode entón dicirche que a cadea está incompleta ou que o certificado caducou. Iso non significa que a primeira comprobación fose innecesaria. Significa que a cadea tiña máis dun problema, así que espera o segundo erro en lugar de lelo como proba de que o primeiro arranxo era incorrecto.

Varios nodos empeoran isto. Un servizo con balanceo de carga pode presentar certificados distintos de membros distintos, así que unha proba que pasa dúas veces e falla unha está a falarche da frota e non do teu cliente. Conserva o enderezo do par e a hora do intento no diagnóstico.

Ese detalle é o que converte un ticket intermitente nun reproducible.

Demóstrao cunha conexión nova

Despois da reparación, abre unha conexión nova en lugar de retomar unha antiga, e confirma que a etapa que fallaba agora pasa. Despois confirma que o túnel transporta tráfico de verdade, porque unha negociación correcta non é unha ruta que funcione.

Conserva a etapa exacta do erro e os detalles do certificado co ticket.

Ese rexistro é o que impide que a seguinte persoa restableza contrasinais de conta por un problema de certificado. Identidade e validez son cuestións separadas, e a RFC 5280 é a referencia de como se avalía a segunda.