Monitorización de caducidad del certificado SSL: no te enteres por el cliente

La monitorización de caducidad del certificado SSL es la comprobación automática y periódica de cuántos días le quedan al certificado TLS de un sitio, con un aviso que llega con tiempo suficiente para renovarlo. Cuando un certificado caduca, los navegadores sustituyen la página por una advertencia a pantalla completa, así que los formularios, los logins y el checkout dejan de funcionar y el tráfico cae casi de inmediato.

Los certificados rara vez caducan en el sitio principal que todo el mundo vigila. Caducan en el sitio heredado de otra agencia, en un subdominio que nadie apuntó, un fin de semana. Con demasiada frecuencia, el cliente se da cuenta antes que la agencia.

Qué ven los visitantes y los rastreadores

En Chrome la página muestra "La conexión no es privada" con el código de error NET::ERR_CERT_DATE_INVALID. Firefox muestra "Advertencia: riesgo potencial de seguridad a continuación" con SEC_ERROR_EXPIRED_CERTIFICATE. La mayoría de la gente se va. Si el sitio envía una cabecera Strict-Transport-Security (HSTS), los navegadores ni siquiera ofrecen la opción de continuar, así que para los visitantes recurrentes el sitio sencillamente no es accesible.

La analítica se queda plana, porque la página nunca carga y el script de seguimiento no llega a ejecutarse. Los formularios de pago y de captación de leads fallan. Las llamadas de servidor a servidor, como los webhooks de una pasarela de pago, rechazan el certificado y suelen registrar el error en algún sitio que nadie mira. Googlebot se encuentra errores al descargar las páginas y, si el problema dura días y no horas, el rastreo se ralentiza y pueden caer páginas del índice.

Cómo caducan los certificados a pesar de la renovación automática

Los certificados de Let's Encrypt duran 90 días, y la renovación suele ser una tarea programada que ejecuta Certbot o el panel del hosting. Falla de unas cuantas maneras previsibles.

Se rompe la propia tarea. Una actualización de paquetes, un cambio en el entorno de Python o un disco lleno hacen que certbot renew termine con un error que acaba en /var/log/letsencrypt/ y en ningún otro sitio. Además, Let's Encrypt dejó de enviar los emails de aviso de caducidad en 2025, así que el recordatorio en el que mucha gente confiaba ya no llega.

La validación deja de pasar. El reto HTTP-01 necesita que /.well-known/acme-challenge/ sea accesible en el puerto 80. Una regla de redirección nueva, un WAF o un cambio en el firewall pueden bloquearlo. En el caso de DNS-01, mover el DNS a otro proveedor rompe las credenciales de API que usaba la renovación.

El certificado se renueva pero nunca se carga. Nginx y Apache siguen sirviendo el certificado que cargaron al arrancar hasta que se recargan. Certbot lo resuelve con un deploy hook como --deploy-hook "systemctl reload nginx"; si nunca se configuró, el archivo en disco está al día mientras los visitantes reciben el caducado.

El edge y el origen no coinciden. Cuando Cloudflare o un balanceador de carga terminan el TLS, hay dos certificados con dos fechas de caducidad. El que ven los visitantes está en el edge, pero con el modo Full (strict) activo, un certificado de origen caducado rompe la conexión que hay detrás.

Los subdominios se olvidan. Un certificado para example.com y www.example.com no cubre shop.example.com ni staging.example.com, y cada uno puede tener su propio certificado y su propia tarea de renovación.

Puedes ejecutar certbot renew --dry-run para probar el proceso de renovación sin sustituir nada.

Comprobar a mano la caducidad del certificado SSL

En el navegador, haz clic en el icono a la izquierda de la barra de direcciones, abre los detalles del certificado y lee la fecha de "Válido hasta" o "Caduca el".

Desde la línea de comandos:

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

Esto muestra notBefore, notAfter y el emisor. Incluye siempre -servername; sin él, un servidor que aloja varios sitios en una misma IP puede devolver su certificado por defecto en lugar del de tu hostname.

Ya que estás, revisa dos cosas más. El emisor debería ser el que esperas, porque un cambio suele indicar que se ha reconfigurado el hosting o la CDN. Y la cadena debería estar completa: un certificado intermedio que falta o un hostname que no aparece en los Subject Alternative Names del certificado provocan la misma advertencia del navegador que una caducidad, aunque queden meses.

Por sitio, esto lleva un minuto. Con treinta clientes, sus subdominios y unos cuantos entornos de staging, se convierte en una tarea que se salta en las semanas de más carga. La checklist de monitorización web para agencias recoge las demás comprobaciones periódicas que corren la misma suerte.

Monitorización SSL y de dominios en Deltio

Deltio comprueba el certificado de cada sitio que añades, muestra en el dashboard los días que quedan y el emisor, y te avisa por Slack y email antes de la caducidad y cuando un certificado no es válido. La caducidad del dominio se revisa en el mismo sitio, lo cual importa porque un dominio vencido tumba a la vez el certificado, la web y el correo. El uptime y los cambios de robots.txt y del sitemap funcionan en la misma cuenta, así que el SSL es una línea más dentro de una visión completa de cada sitio de cliente y no una herramienta aparte, el enfoque que describimos en cómo monitorizar los cambios en las webs de tus clientes. Un certificado caducado equivale en la práctica a una caída, y por eso también aparece en nuestra comparativa alternativa a UptimeRobot.