Cómo comprobar la caducidad de un certificado SSL y recibir alertas

Para saber cuándo caduca un certificado SSL tienes tres opciones: pulsar el candado del navegador, ejecutar un comando openssl o leer la salida del handshake de curl. Cada una lleva menos de un minuto y te da la fecha notAfter del certificado que el servidor presenta ahora mismo. Esa es la parte fácil. La difícil es que los certificados ya viven 90 días, pronto 47, así que una fecha comprobada el trimestre pasado no dice nada de hoy. Esta guía cubre primero la comprobación puntual y después cómo poner la fecha bajo vigilancia diaria, para que una renovación rota te llegue a ti antes que a tus usuarios. Hablamos del certificado, no del nombre de dominio: la caducidad del dominio es cosa del registro y tiene su propio calendario.

Leer la fecha de caducidad en el navegador

Pulsa el candado (o el icono de información del sitio) a la izquierda de la dirección. En Chrome, abre «La conexión es segura» y después «El certificado es válido»; en Firefox, «Conexión segura», «Más información» y «Ver certificado»; en Safari, «Mostrar certificado». El visor muestra un periodo de validez con dos fechas. La segunda, «Válido hasta» o «Not after», es la caducidad. El navegador la muestra en tu zona horaria, pero el certificado la guarda en UTC: un certificado que «caduca a la 01:59» puede estar ya muerto para un usuario dos husos más al este.

Esto basta para comprobar un sitio ajeno o responder a un compañero que ha visto un aviso. No basta para comprobar tu propia infraestructura, porque un navegador solo muestra un hostname a la vez, y solo el que se te ha ocurrido.

Comprobar con openssl y curl en la línea de comandos

El comando openssl que hay que conocer

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

La salida da notBefore, notAfter, el emisor y el sujeto. Conserva la opción -servername: envía el hostname en el handshake TLS (SNI), y sin ella un servidor que aloja varios sitios te entrega su certificado por defecto, que puede ser distinto del sitio que querías comprobar. Muchos misterios del tipo «en mi máquina el certificado está bien» vienen de comprobar sin SNI.

Probar un umbral en un script

openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -checkend 1209600 \
  || echo "example.com caduca en menos de 14 días"

-checkend recibe un número de segundos (14 días aquí) y devuelve un código de salida distinto de cero si el certificado habrá caducado para entonces. Ese código de salida es lo que necesita un cron o un paso de CI.

curl y un archivo local

curl -vI https://example.com 2>&1 | grep -iE "expire date|issuer"

curl imprime las fechas del certificado que ha negociado, útil en una máquina sin openssl. Para un archivo de certificado en un pipeline de despliegue, antes incluso de servirlo:

openssl x509 -in cert.pem -noout -enddate

Por qué una comprobación puntual ya no basta

La vida de los certificados lleva diez años acortándose, y el CA/Browser Forum ha votado los siguientes pasos.

Certificado	Vida máxima
Let's Encrypt (por defecto)	90 días
Cualquier certificado público desde marzo de 2026	200 días
Cualquier certificado público desde marzo de 2027	100 días
Cualquier certificado público desde marzo de 2029	47 días

A 47 días nadie renueva a mano. La renovación está automatizada, y la automatización falla en silencio: un desafío DNS se rompe tras una migración de DNS, alguien añade un registro CAA que excluye al emisor, un token de API caduca, un subdominio sobrevive a la persona que lo llevaba. El cron escribe un error que nadie lee, y el certificado viejo sigue funcionando hasta el día en que deja de hacerlo. La guía sobre renovaciones de Let's Encrypt fallidas lista las causas; la de qué pasa cuando caduca un certificado describe los daños. El punto aquí es más simple: con certificados cortos, lo que se vigila es la renovación, y el único testigo fiable es el certificado servido visto desde fuera.

Poner la fecha de caducidad bajo vigilancia con Domain Sentinel

Añade el dominio a tu watchlist y activa la monitorización del certificado TLS. Deja el hostname vacío para comprobar el propio dominio, o escribe www o api si el HTTPS se sirve ahí. A partir de entonces, Domain Sentinel se conecta a ese host cada día, lee el certificado como lo haría un navegador y guarda una instantánea cuando algo cambia: emisor, fechas, huella. Recibes un correo 14, 7, 3 y 1 día antes de la caducidad, y una alerta en la siguiente comprobación si el certificado ha caducado, es autofirmado, está emitido para otro nombre o viene de un emisor distinto del anterior. Un botón «Comprobar ahora» lanza la misma comprobación bajo demanda.

Los límites, dichos claramente: un hostname por dominio vigilado, sin descubrimiento automático de tus subdominios y sin renovar en tu lugar. El inventario de tus hostnames públicos (sitio, www, api, mail) lo construyes tú, la guía de monitorización de Certificate Transparency muestra cómo, y añades cada uno. Tampoco es monitorización de uptime: se lee el certificado, no se comprueba que la página cargue, una distinción que explica la comparación entre monitorización DNS y de uptime.

Qué significan los umbrales de alerta para tus certificados

Los umbrales están fijados en 14, 7, 3 y 1 día, y la ausencia de una alerta a 30 días es deliberada. Let's Encrypt renueva un certificado de 90 días cuando quedan 30: una alerta a 30 días saltaría en cada ciclo sano y te enseñaría a ignorarla. Catorce días significa que la renovación que debía ocurrir no ocurrió, y que aún tienes dos semanas.

Tu certificado	Cómo leer las alertas
Certificado de un año, renovado a mano	14 días dan margen para una renovación manual; trata la alerta de 7 días como urgente
Certificado de 90 días, automatizado	Cualquier alerta significa que la automatización se rompió; la alerta de cambio de emisor es tu confirmación de que una renovación ocurrió de verdad
Certificado de 47 días	Misma lógica con menos margen: revisa el job de renovación el día que llega la alerta de 14 días

Hazlo ahora

Ejecuta el comando openssl contra tu hostname principal y lee notAfter. Lista todos los hostnames que sirven HTTPS, incluidos los que habías olvidado, y añade cada uno a una watchlist con la monitorización TLS activada. Después deja de comprobar fechas a mano: con certificados de 90 días, lo que hay que vigilar no es el calendario, es la renovación.