Cómo comprobar cuándo caduca un certificado SSL

La vía rápida: el candado y una comprobación en línea

En cualquier navegador, haz clic en el candado de la barra de direcciones, abre los detalles del certificado y lee "válido desde" y "válido hasta". Eso lleva diez segundos y te dice lo que ve tu propio navegador. Su límite es que solo cubre el certificado que te sirvieron a ti, desde el nodo de borde o servidor al que llegaste, en el momento en que miraste.

Una comprobación SSL en línea hace el mismo saludo desde fuera de tu red y reporta la fecha de caducidad, el emisor, los nombres que cubre el certificado y si la cadena que se sirvió está completa. Los navegadores ocultan ese último punto, así que la comprobación externa te dice algo que el candado no puede.

La vía manual con openssl

Un comando imprime la ventana de validez:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -subject -issuer

El indicador -servername envía SNI, algo que importa porque la mayoría de los servidores alojan varios certificados en una misma dirección y te entregarán el equivocado sin él. La salida da notBefore y notAfter en UTC, además de para quién es el certificado y quién lo emitió.

Para ver toda la cadena que envía el servidor, y no solo la hoja:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Lee el bloque "Certificate chain" al principio: deberías ver la hoja y después uno o más intermedios. Una línea "verify error: unable to get local issuer certificate" significa que el servidor no está enviando el intermedio, algo que muchos navegadores disimulan pero que muchos clientes de API, aplicaciones móviles y sistemas antiguos no perdonan.

Hoja, cadena y qué es lo que caduca

En una conexión HTTPS normal intervienen tres certificados, y cada uno tiene su propia fecha de caducidad:

• La hoja es el certificado emitido para tu dominio. Es el de vida corta, normalmente 90 días si la emisión es automática y hasta cerca de un año si se compró, y es a lo que la gente se refiere cuando dice "el certificado".
• El intermedio firma la hoja y el servidor tiene que enviarlo junto con ella. Dura años, y es precisamente porque cambia tan pocas veces por lo que su caducidad pilla desprevenidos a los equipos.
• La raíz vive en el almacén de confianza del cliente, no en tu servidor. Cuando una raíz caduca o deja de ser de confianza, los dispositivos más antiguos que nunca recibieron la actualización empiezan a fallar mientras que los actuales van bien, lo que produce una caída que parece imposible desde tu propio portátil.

Así que valida la cadena, no solo la fecha de la hoja. Una hoja con dos meses por delante pero con una cadena rota ya está fallando para algunos clientes.

Por qué la caducidad es la caída evitable más común

La caducidad de un certificado es un fallo excepcionalmente dañino. Falla por completo en lugar de gradualmente, porque el navegador rechaza la conexión de plano y muestra una advertencia a pantalla completa en lugar del sitio. El momento en que ocurre quedó fijado el día en que se emitió el certificado, y nadie estaba vigilando esa fecha. Además, tumba a la vez todo lo que usa ese nombre, no solo el sitio web: APIs, backends de aplicaciones móviles, webhooks e integraciones. Los callbacks de pago fallidos y las integraciones rotas a menudo cuestan más que la caída visible.

También es totalmente evitable, por lo que es el fallo que más vale la pena automatizar con una comprobación.

Cómo falla la renovación automática de todos modos

La emisión automatizada eliminó la mayoría de las caducidades e introdujo un conjunto de fallos más difíciles de ver:

• La renovación se ejecutó pero nada se recargó. Un certificado nuevo queda en el disco mientras el servidor web sigue sirviendo el antiguo desde memoria hasta que se recarga.
• El reto de validación se rompió. Una regla de redirección, un cambio de firewall o una nueva CDN delante del origen bloquea la ruta del reto HTTP, así que la renovación sigue fallando durante semanas sin ningún síntoma visible.
• La validación por DNS perdió sus credenciales. Un token de API se rotó o caducó y el reto de DNS ya no puede crear su registro.
• El temporizador de renovación no se está ejecutando. Un contenedor se reconstruyó sin la tarea de cron o el temporizador de systemd, o la máquina se migró y el programa no la acompañó.
• Solo se renovó un nodo. Detrás de un balanceador de carga, un servidor tiene el certificado nuevo y otro sigue sirviendo el antiguo, así que los fallos parecen intermitentes.
• Los correos de renovación llegaron a alguien que ya no está. La versión con certificado comprado del mismo problema.
• El certificado se renovó pero no para todos los nombres. Un subdominio añadido más tarde falta en el certificado nuevo, así que ese nombre de host concreto falla.

Cada uno de estos casos es invisible desde dentro del sistema de renovación y evidente desde fuera. Ese es el argumento a favor de comprobar el saludo real en lugar de confiar en los propios registros de la automatización.

Automatizar la comprobación

Leer una fecha te da la respuesta de hoy, y todo el problema de la caducidad es que llega un día que nadie eligió comprobar. La monitorización periódica de certificados realiza el saludo real desde fuera con un intervalo, avisa un número determinado de días antes de notAfter, y detecta los problemas de cadena y de nombre de host que un recordatorio en el calendario nunca detectaría. HostTracker avisa por correo, SMS, llamada de voz, Slack, Telegram y más, así que el aviso llega a alguien antes que la caducidad. La monitorización de dominio y TLS ejecuta la comprobación de forma continua, la herramienta de comprobación SSL hace una puntual, y cómo comprobar si un puerto está abierto trata el caso de un saludo que falla antes incluso de que se ofrezca un certificado.