Certificado hoja válido, cadena caducada: lee la profundidad

Compruebas el certificado del servidor, ves meses restantes en el reloj y el cliente sigue rechazando la conexión con un mensaje de caducidad. La fecha que lees pertenece a la hoja, y la queja puede ser sobre algo más profundo en la ruta. La verificación recorre una cadena, y cualquier certificado que este recorrido seleccione puede fallar en su propia ventana de validez. Lee cuál falló antes de renovar nada.

La profundidad nombra el certificado que falló

En el diagnóstico de OpenSSL, la profundidad 0 es el certificado objetivo y la profundidad 1 es el emisor que lo firmó, con números superiores que continúan hacia el ancla de confianza. Una caducidad informada en la profundidad 1 no queda contradicha por un notAfter vigente en la hoja, así que volver a comprobar el certificado visible nunca explicará el error.

Anota la huella del certificado fallido junto con su sujeto, porque certificados distintos pueden llevar el mismo nombre de CA. La firma cruzada produce exactamente esa situación: la misma autoridad aparece más de una vez, con fechas de validez diferentes, y el verificador eligió la que no esperabas. Una etiqueta familiar no es un identificador, y una huella es lo que distingue dos objetos que comparten nombre.

Fíjate también en los productos con más de un rol de certificado. En OpenVPN Access Server, los certificados que protegen las interfaces web son distintos de los que se usan para las conexiones VPN, así que un navegador que abre la página de administración no demuestra nada sobre la ruta del túnel.

Las entradas de confianza no son lo mismo que los candidatos de cadena

Entrega al verificador las dos entradas por separado y de forma explícita. El archivo de confianza contiene las anclas que aceptas; el paquete no confiable contiene certificados intermedios ofrecidos para construir la ruta. Mezclarlos es como la gente promociona por accidente un intermedio a raíz y luego se pregunta por qué el mismo error les sigue entre máquinas.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Desactivar la ruta y el almacén predeterminados con -no-CApath -no-CAstore mantiene honesta la prueba: el resultado depende entonces de los archivos que nombraste, no de lo que la estación de trabajo confía por casualidad. La referencia de verificación de OpenSSL documenta estas opciones y el diagnóstico que producen.

-show_chain imprime la cadena construida cuando la verificación tiene éxito, lo que resulta útil para confirmar que la ruta es la que pretendías. Cuando falla, conserva la profundidad y el sujeto informados; esos dos campos dicen al siguiente lector qué certificado inspeccionar.

Lo que esto no hace es reproducir la política de cada cliente. Un pin, una restricción de propósito o una comprobación de identidad específica del cliente vive en el cliente, no en este comando. Esos son los ajustes que hay que inspeccionar cuando la verificación pasa en el servidor y la conexión sigue fallando. Mantén los dos diagnósticos separados, o renovarás un certificado sano persiguiendo un error de pinning.

Qué demuestra la comprobación y qué deja fuera

Esta es una comprobación de ruta y propósito contra un archivo de confianza que tú aportaste. Para una comprobación de nombre HTTPS, añade el nombre de host esperado mediante la opción adecuada; para una conexión VPN, conserva las comprobaciones de identidad configuradas del cliente y usa el material de confianza que ese cliente lee realmente.

Lo que un servidor envía es un conjunto de candidatos, no la ruta que tu cliente acabará construyendo. La confianza local y las reglas de construcción de la biblioteca dan forma ambas al resultado, y por eso la misma respuesta puede verificar en una máquina y fallar en otra. Compara el almacén de confianza mantenido y la implementación TLS del cliente que falla con los de un cliente que funciona antes de suponer una evaluación idéntica. Una diferencia ahí explica muchos informes de «solo falla este portátil».

Para ver la ventana de cada certificado en lugar de uno a la vez, imprímelos como conjunto:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Ese segundo comando lista sujetos y emisores sin decodificar cada archivo a mano, y así es como detectas un intermedio cuya fecha ha pasado mientras la hoja todavía parece bien.

Repara la ruta sin debilitar la verificación

Cuando se suministra un intermedio caducado o un certificado cruzado obsoleto, obtén la cadena actualmente soportada del emisor y despliégala mediante el flujo de certificados documentado del servicio. Cuando al cliente le falta el ancla mantenida prevista, actualiza su configuración de confianza gestionada o el software del cliente. Resiste el atajo de marcar cada certificado del paquete como raíz solo para silenciar el mensaje.

El tratamiento de la raíz merece una nota, porque los resúmenes a menudo lo exageran. RFC 5280 trata el ancla como una entrada que queda fuera de la ruta prospectiva, mientras que OpenSSL documenta comprobaciones de validez que incluyen su certificado CA raíz. Ambas afirmaciones son ciertas para sus propios sistemas; generalizar el comportamiento de caducidad de la raíz de una biblioteca a todos los clientes produce respuestas erróneas con seguridad.

Tras el cambio, fuerza una autenticación nueva en el cliente afectado y confirma que el mensaje de caducidad concreto ha desaparecido. Renueva la hoja solo si la hoja misma es inadecuada. Desactivar las comprobaciones de tiempo o restaurar un certificado cruzado histórico no produce una ruta actual válida; solo retrasa el siguiente fallo.