El nombre del certificado no coincide o ha caducado: cómo distinguirlo

Dos fallos de VPN se ven idénticos desde la silla del usuario y necesitan arreglos opuestos. Una discrepancia de nombre dice que el certificado es válido pero emitido para otra cosa. Un error de caducidad dice que el certificado no es válido en este momento. Ninguno de los dos es un problema de contraseña, y restablecer las credenciales es la hora más desperdiciada en ambos casos. Lea la etapa que falla antes de tocar nada.

El texto del error es el diagnóstico

El cliente le dice qué comprobación falló, incluso cuando el mensaje es escueto. Una discrepancia nombra el nombre de host que esperaba y el nombre que encontró. Un error de caducidad menciona fechas de validez o una hora. Esas dos frases apuntan a partes distintas del certificado.

Léalas en la etapa donde aparecen. Un fallo durante el apretón de manos es un problema de certificado; un fallo después de levantar el túnel es un problema de enrutamiento o de credenciales. Retener la etapa es lo que evita que la investigación derive hacia ajustes no relacionados.

Si el fallo varía entre intentos, tiene una tercera posibilidad: más de un nodo detrás del mismo nombre.

Comprobaciones de nombre: qué compara el cliente

El cliente compara la identidad que estaba configurado para esperar con los nombres del certificado, que viven en la extensión subjectAltName. Una IP sin procesar en el perfil, un alias que el certificado no enumera o un nombre que solo resuelve al mismo servidor, todos fallan esta comprobación. Llegar a la máquina correcta no es lo mismo que presentar la identidad correcta.

Inspeccione el certificado que el servidor presenta realmente, en lugar de un archivo de un intento anterior. El comando de abajo pide el nombre que configuró, así que la respuesta incluye el 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 de un emisor de confianza puede seguir siendo para otro servicio. Mantenga activadas las comprobaciones de nombre del cliente, porque confiar en una CA no autoriza todos los nombres que esa CA haya firmado alguna vez. Desactivar la comprobación convierte un error de configuración en una exposición.

Caducidad: qué reloj se lee

La validez es un par de marcas de tiempo, y el verificador las compara con su propio reloj. Un dispositivo con el reloj equivocado informa de un certificado válido como caducado o como aún no válido, y el arreglo es el reloj, no el certificado. Una diferencia de visualización de zona horaria no es lo mismo que una hora de fondo equivocada.

Compare las fechas del certificado con UTC en el cliente antes de concluir nada:

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

Si las fechas realmente han pasado, renueve a través del emisor. Si existe un reemplazo pero aún no ha pasado a ser válido, siga la transición admitida en lugar de mover el reloj para acomodarlo. Retrasar la fecha de un dispositivo para satisfacer un certificado es una decisión con consecuencias mucho más allá del túnel.

Por qué arreglar uno expone el otro

La validación ejecuta una secuencia de comprobaciones, y el primer fallo detiene el informe. Arregle el nombre y el cliente puede entonces decirle que la cadena está incompleta o que el certificado ha caducado. Eso no significa que la primera comprobación fuera innecesaria. Significa que la cadena tenía más de un problema, así que espere el segundo error en lugar de leerlo como prueba de que el primer arreglo era incorrecto.

Varios nodos empeoran esto. Un servicio equilibrado por carga puede presentar certificados distintos de miembros distintos, así que una prueba que pasa dos veces y falla una le habla de la flota, no de su cliente. Mantenga la dirección del par y la hora del intento en el diagnóstico.

Ese detalle es lo que convierte un ticket inestable en uno reproducible.

Demuéstrelo con una conexión nueva

Después de la reparación, abra una conexión nueva en lugar de reanudar una antigua, y confirme que la etapa que antes fallaba ahora pasa. Luego confirme que el túnel realmente transporta tráfico, porque un apretón de manos correcto no es una ruta que funcione.

Conserve la etapa exacta del error y los detalles del certificado con el ticket.

Ese registro es lo que evita que la siguiente persona restablezca contraseñas de cuenta por un problema de certificado. Identidad y validez son preguntas separadas, y RFC 5280 es la referencia de cómo se evalúa la segunda.