Caducidad de certificados SSL/TLS: por qué sigue tumbando sitios web

Cuando un certificado TLS caduca, los navegadores dejan de confiar en la conexión y muestran un aviso a pantalla completa en lugar de su web. Las APIs, las aplicaciones móviles y las integraciones que se conectan al mismo host suelen fallar directamente, porque sus clientes rechazan un certificado caducado sin preguntar a nadie. El sitio puede estar funcionando perfectamente, pero para los visitantes está caído.

La renovación lleva años automatizada, así que ¿por qué sigue ocurriendo? Porque la automatización cubre los certificados que alguien se acordó de automatizar. Las caídas por caducidad suelen venir de los olvidados: un subdominio creado para una campaña, un balanceador de carga con un certificado subido a mano, un servidor de correo o una tarea de renovación que lleva semanas fallando en silencio.

Además, la vigencia de los certificados es cada vez más corta, lo que significa que cada proceso de renovación se pone a prueba con más frecuencia.

La vigencia de los certificados se reduce

El CA/Browser Forum fija las reglas que siguen las autoridades de certificación reconocidas por los navegadores. En abril de 2025 aprobó la votación SC-081v3, y los TLS Baseline Requirements vigentes (sección 6.3.2) establecen este calendario para la vigencia máxima de un certificado:

• emitidos antes del 15 de marzo de 2026: un máximo de 398 días,
• emitidos desde el 15 de marzo de 2026: un máximo de 200 días,
• emitidos desde el 15 de marzo de 2027: un máximo de 100 días,
• emitidos desde el 15 de marzo de 2029: un máximo de 47 días.

En la práctica, esto significa que en 2029 un certificado renovado a mano habría que sustituirlo aproximadamente cada 6 o 7 semanas. Cualquier certificado que se siga renovando a mano, a partir de un recordatorio en el calendario, se convierte en un riesgo de caída recurrente.

Tampoco conviene contar con los recordatorios de la autoridad de certificación. Let's Encrypt, por ejemplo, dejó de enviar sus correos de aviso de caducidad el 4 de junio de 2025.

Por qué fallan las renovaciones

Las causas habituales son prosaicas:

• Falla la validación. La validación HTTP se rompe tras un cambio de redirección o de cortafuegos; la validación DNS se rompe tras un cambio de proveedor de DNS o porque ha caducado un token de API.
• La renovación se completa pero el servicio no se recarga, de modo que el servidor web sigue sirviendo el certificado antiguo.
• Los certificados se copiaron a mano a un balanceador de carga, una CDN, un dispositivo o un servidor de correo al que no llega la automatización.
• Nadie es responsable del host. Los servidores de preproducción y los subdominios antiguos de marketing suelen tener certificados pero ningún responsable. Consulte servidores de pruebas olvidados.
• Ha vencido la cuenta o el pago de un certificado comercial.
• La cadena intermedia está incompleta, algo que algunos clientes rechazan incluso antes de la caducidad.

Cómo comprobar usted mismo la caducidad de un certificado

Para un único host, openssl muestra las fechas que el servidor presenta realmente:

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

Fíjese en notAfter. Compruebe cada nombre por separado, incluidos www, los hosts de API y los de correo. Para un servidor de correo con STARTTLS:

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate

Para encontrar hosts que quizá haya olvidado, busque %.example.com en los registros de Certificate Transparency en crt.sh. Ahí aparece cada certificado emitido para su dominio, incluidos los de subdominios que nadie recuerda. Nuestro artículo sobre los registros de Certificate Transparency explica cómo interpretar los resultados.

Cómo evitar que caduquen los certificados

1. Automatice la emisión y la renovación con ACME siempre que sea posible, y haga que la tarea de renovación recargue después el servicio.
2. Renueve con bastante antelación, lo suficiente para tener tiempo de corregir una validación fallida.
3. Configure alertas para las renovaciones fallidas, no solo para las correctas. Una tarea cron que termina con error y no avisa a nadie es la causa clásica.
4. Mantenga un inventario de todos los hosts con certificado, elaborado a partir de los resultados de Certificate Transparency, no de memoria.
5. Vigile desde fuera. Compruebe el certificado que el servidor presenta realmente, porque eso es lo que ven los clientes. Un registro interno que diga "renovado" no es lo mismo.
6. Elimine lo que ya no usa. Un subdominio que ya no sirve nada debería perder su registro DNS y su certificado.

Si un certificado ya ha caducado

• Renuévelo o vuelva a emitirlo, despliéguelo y recargue el servicio.
• Confirme con openssl s_client desde fuera de su red que se sirve la nueva fecha notAfter.
• Compruebe que se sirve la cadena completa, no solo el certificado final.
• Revise los clientes dependientes: puede que las aplicaciones móviles, las integraciones de socios y los webhooks necesiten un reintento.
• Averigüe por qué no saltó la alerta y corríjalo.

Lista de comprobación

• Inventario de todos los hosts con certificado, incluidos los de correo y API.
• Automatización ACME con recarga del servicio.
• Alertas ante renovaciones fallidas.
• Comprobación externa de la caducidad en cada host.
• Preparación para vigencias de 100 y 47 días.

Los dominios también caducan, con consecuencias muy distintas. Consulte qué ocurre cuando caduca su dominio.

Cómo le ayuda Datahorses

Datahorses vigila su empresa desde fuera y comprueba los certificados que presentan realmente sus servidores, incluidas la caducidad, las cadenas rotas y los certificados autofirmados, con recordatorios 30, 14 y 3 días antes de que caduque un certificado o un dominio. No entramos en sus sistemas ni necesitamos ningún acceso. Consulte lo que vigilamos y el panel de ejemplo para ver cómo se presenta.