El nuevo ciclo de vida del SSL/TLS

Durante años, los certificados SSL/TLS mantuvieron una vigencia de años (pasando gradualmente de 8 a 5, 3, 2 años y finalmente 398 días).

Sin embargo, las decisiones del CA/Browser Forum (CAB Forum), el consorcio que reúne a navegadores como Google Chrome, Mozilla Firefox y Apple Safari junto a las Autoridades de Certificación (CAs) globales, han iniciado un cambio radical, la reducción drástica de la caducidad a unos 6 meses (200 días), con un horizonte de apenas 47 días hacia finales de década.

A esta carrera por reducir la ventana temporal de exposición se suma una realidad incómoda, los errores humanos y de software en las propias Autoridades de Certificación, donde fallos que van desde números de serie predecibles o carentes de entropía hasta omisiones en la validación de dominio han forzado revocaciones masivas de certificados de emergencia en cuestión de horas. Hace tan solo 1 semana el pilar SSL se tambaleó con el incidente de eMudhra, documentado en octubre de 2026 por investigadores independientes y reportado en los canales de seguridad de Cloudflare, Mozilla, Google y Apple. Ocho certificados intermedios emitidos por la CA global eMudhra fueron generados con claves privadas débiles y triviales, al punto de que una de ellas era simplemente el número 4.

1. La reducción de caducidad a 200 días (~6 meses)

A través de iniciativas impulsadas originalmente por Google y formalizadas en el CA/Browser Forum (mediante la propuesta Ballot SC-081 y los Baseline Requirements actualizados), se fijó el calendario obligatorio de acortamiento de vida útil para todos los certificados de confianza pública:

¿Por qué forzar una caducidad tan corta?

1. Reducción de la ventana de exposición: Si la clave privada de un servidor se filtra o es robada en un ataque, un certificado antiguo le daba al atacante hasta 13 meses para interceptar o suplantar tráfico sin ser detectado. A 200 días (y luego 47), esa ventana se minimiza radicalmente.
2. Eliminación del criptoanálisis legado: Permite a la industria desplegar nuevos algoritmos (como criptografía post-cuántica) de manera homogénea en toda la web en cuestión de meses, sin esperar años a que venzan los certificados viejos.
3. Muerte definitiva de la renovación nanual: Con renovaciones obligatorias cada 6 meses (y pronto cada 45 días), renovar mediante tickets o procesos humanos es una garantía segura de caídas de servicio (outages). La automatización vía ACME (Automated Certificate Management Environment) se convierte en el único estándar viable.

2. El incidente de eMudhra

El 19 de octubre de 2026, Cloudflare y los principales mantenedores de navegadores recibieron un aviso críticom¡, ocho certificados intermedios subordinados a las raíces de eMudhra contenían claves privadas recuperables.

¿Qué ocurrió técnicamente?

• Fallo criptográfico: En lugar de generar números aleatorios con alta entropía criptográfica mediante hardware seguro (HSM), los certificados intermedios (creados en abril de 2025) se generaron mediante una rutina defectuosa.
• Espacio de búsqueda: Para deducir las claves privadas no hacían falta supercomputadores. Se requerían como máximo 256 intentos; de hecho, una de las claves equivalía simplemente al número entero 4. Para demostrar la vulnerabilidad sin lugar a dudas, el investigador Wayne Thayer firmó el mensaje "We have a problem here" utilizando de forma demostrativa cada una de las ocho claves intermedias.
• El peligro: Una CA intermedia con plena confianza pública tiene la potestad de emitir certificados válidos para cualquier dominio en Internet (google.com, itdo.com, etc.). Quien poseyera esa clave trivial podía ejecutar ataques de intermediario (Man-in-the-Middle) e interceptar o modificar tráfico HTTPS cifrado sin que los navegadores mostraran advertencia alguna.

3. Por qué la revocación falló en servidores y CLI

Tras el reporte, eMudhra revocó los ocho certificados el 18 de octubre de 2026, y navegadores como Chrome, Firefox y Safari desplegaron bloqueos de emergencia vía listas de revocación push (CRLSets, OneCRL).

En el ecosistema de servidores, pipelines y contenedores, el escenario fue distinto:

1. Navegadores vs. CLI/Backend: Mientras que un navegador actualiza su lista de revocación en segundo plano, herramientas de línea de comandos como curl, git, python3 y llamadas internas de microservicios no verifican CRL ni OCSP por defecto.
2. Imágenes docker y runtimes desactualizados: Millones de contenedores en producción ejecutan paquetes ca-certificates estáticos. Lenguajes como Go (que lanzó parches de urgencia 1.27.3 / 1.26.10 bajo CVE-2026-111943), Node.js, Python (certifi) y Java distribuyen sus propios almacenes de certificados (trust stores).
3. El despliegue de mitigaciones en Cloudflare: Como explicó Cloudflare en su reporte técnico, tuvieron que parchear con urgencia desde Cloudflare Tunnel (cloudflared) y WARP / 1.1.1.1 hasta la infraestructura de Edge y Zero Trust Gateway para evitar que las conexiones salientes hacia servidores de origen o APIs externas aceptaran certificados forjados.

4. Guía práctica para proteger tu Infraestructura en 2026

Frente a la reducción de plazos a 200 días y las revocaciones imprevistas, los equipos de infraestructura y DevSecOps deben aplicar tres directrices:

1. Migración obligatoria al Protocolo ACME

Deja de comprar certificados manuales con validación por correo electrónico o subida manual de archivos. Implementa clientes automatizados como Certbot, Lego o gestores nativos de proxy (Caddy, Traefik, Cloudflare SSL for SaaS) configurados para renovar cuando falten 30 días para la expiración.

2. Inspección completa de la cadena (Fullchain)

El acortamiento de tiempos no perdona errores de configuración de cadena. En Nginx o Apache, asegúrate de servir siempre el archivo fullchain.pem (el certificado leaf más los certificados intermedios), evitando referencias exclusivas a cert.pem.

3. Monitorización externa con alertas de revocación (OCSP/CRL)

No basta con monitorizar la fecha de caducidad en el calendario. Es imprescindible monitorizar el estado de revocación mediante consultas OCSP (Online Certificate Status Protocol) automáticas. Si una CA comete un error interno y revoca un lote de certificados, tus alertas deben notificarte antes de que los navegadores bloqueen el acceso a tus usuarios.

Referencias:
· Cloudflare Cryptography & Security Blog (2026). 8 eMudhra certificates are compromised. Here's what you need to know.
· Dennis Jackson / Mozilla Security (2026). eMudhra Intermediate CA Compromise Tracking & Test Endpoints.
· CA/Browser Forum (2025/2026). Ballot SC-081: Reducing Certificate Validity to 200, 100, and 47 Days.
· IETF RFC 8555. Automatic Certificate Management Environment (ACME).
· ITDO Blog (Chiyana Simões). La vulnerabilidad no estaba en tu web.