La cuenta atrás para una auténtica “revolución silenciosa” en la gestión de certificados TLS ya ha comenzado. El CA/Browser Forum ha aprobado oficialmente un calendario para reducir de forma gradual la vida útil máxima de los certificados hasta dejarla en apenas 47 días en 2029. Un cambio que, sobre el papel, mejora la seguridad de la web… pero que, en la práctica, impacta de lleno en el día a día de administradores de sistemas, responsables de plataformas y equipos DevOps de todo el mundo.
La pregunta ya no es si afectará, sino si las organizaciones están preparadas para un escenario donde renovar certificados manualmente dejará de ser viable.
De 398 días a 47: el nuevo calendario que lo cambia todo
Hasta ahora, los certificados TLS de servidor público podían tener una validez máxima de 398 días. Eso ya obligaba a tener cierto control de expiraciones, pero muchas organizaciones seguían apoyándose en procesos manuales, hojas de cálculo o recordatorios dispersos.
Con la nueva decisión del CA/Browser Forum, ese margen se irá estrechando en varias fases:
- Hasta el 15 de marzo de 2026
- Vida útil máxima del certificado TLS: 398 días.
- Reutilización de la validación de dominio/IP: 398 días.
- A partir del 15 de marzo de 2026
- Vida útil máxima: 200 días.
- Reutilización de validación de dominio/IP: 200 días.
- A partir del 15 de marzo de 2027
- Vida útil máxima: 100 días.
- Reutilización de validación de dominio/IP: 100 días.
- A partir del 15 de marzo de 2029
- Vida útil máxima: 47 días.
- Reutilización de validación de dominio/IP: 10 días.
En la práctica, esto significa que, a partir de 2029, los equipos de sistemas tendrán que asumir ciclos de renovación de certificados de en torno a 45 días para mantener un colchón de seguridad. Sin automatización, el riesgo de expiraciones imprevistas y caídas de servicio será enorme.
Por qué se acorta tanto la vida de los certificados
El razonamiento del CA/Browser Forum y de gigantes como Apple o Google sigue una línea clara: cuanto más tiempo está en circulación un certificado, menos fiable es la información que contiene.
- La propiedad o control de un dominio puede cambiar con el tiempo.
- Las validaciones antiguas (por correo, DNS o HTTP) pierden valor conforme pasan los meses.
- El sistema de revocación clásico (CRL, OCSP) es imperfecto y, muchas veces, ignorado por los propios navegadores.
Acortar la vida útil reduce el impacto de un compromiso: si una clave privada se filtra o un dominio cambia de manos, el certificado asociado tendrá una ventana de uso mucho más breve. En paralelo, se obliga de facto a las organizaciones a revalidar con más frecuencia la información de dominio y organización, evitando certificados “zombis” basados en validaciones antiguas.
Apple, impulsora principal de esta reducción agresiva, ha defendido abiertamente que la industria lleva años mandando el mismo mensaje: sin gestión automatizada del ciclo de vida de certificados, el modelo actual no es sostenible. Y con este calendario, ese mensaje pasa de ser una recomendación a ser una condición de supervivencia operativa.
El fin de los “certificados de pegar y olvidar”
Para el mundo de los sysadmin, el cambio es profundo. Se acaba la era del certificado que se compra, se instala una vez al año y se olvida hasta que el navegador empieza a lanzar avisos rojos.
Con ciclos de 200, 100 y finalmente 47 días:
- Los inventarios manuales de certificados serán una fuente constante de errores.
- Las renovaciones “a mano” en docenas o cientos de servidores serán un cuello de botella.
- El impacto de un simple olvido (no renovar un certificado en una API interna, un balanceador o un appliance remoto) puede significar interrupciones periódicas.
Además, la reducción del período de reutilización de validación de dominio/IP a solo 10 días en 2029 complica cualquier proceso manual: no solo habrá que renovar certificados constantemente, sino también repetir validaciones con mucha más frecuencia. En términos operativos, es un escenario incompatible con “tickets puntuales” o tareas esporádicas.
Automatizar o caer: el nuevo mandato para las infraestructuras TLS
En este contexto, la conclusión es clara: no usar mecanismos de automatización para la renovación de certificados se convierte en una auténtica locura operacional.
Para los equipos de sistemas y DevOps, esto se traduce en varios frentes de trabajo:
- Adoptar ACME de forma generalizada
- Integrar clientes ACME (como
certbot,acme.sh,legoo soluciones comerciales) en todos los puntos donde se gestionen certificados: servidores web, proxies inversos, balanceadores, gateways de API, dispositivos de seguridad, etc. - Aprovechar que algunas CAs avanzadas ya soportan ACME no solo para DV, sino también para certificados OV y EV mediante extensiones como ARI (ACME Renewal Information).
- Integrar clientes ACME (como
- Centralizar la visibilidad del ciclo de vida
- Un panel único donde ver todos los certificados, su fecha de expiración, el tipo (DV/OV/EV), la CA emisora y el estado de automatización.
- Alertas y dashboards integrados con sistemas de monitorización (Prometheus, Grafana, Zabbix, etc.) y herramientas de notificación (Slack, Teams, correo, PagerDuty…).
- Integrar la automatización en la propia infraestructura
- Orquestadores como Ansible, Terraform, Puppet o Chef para desplegar y actualizar configuraciones de certificados de forma repetible.
- Actualización automatizada de certificados en servicios que no se integran fácilmente con ACME directo, mediante scripts o hooks.
- Diseñar la infraestructura pensando en rotaciones frecuentes
- Evitar configuraciones donde un certificado se “embebe” en múltiples appliances sin un mecanismo claro de actualización.
- Minimizar servicios que requieran intervención manual o ventanas de mantenimiento para cambiar certificados.
- Normalizar el uso de certificados de corta vida, incluso antes de 2029, para “probar” los procesos de renovación frecuente.
Impacto en entornos híbridos, legacy y edge
Los sysadmin saben bien que no toda la infraestructura está lista para esta nueva realidad.
- En entornos legacy, dispositivos antiguos o sistemas que no soportan bien ACME pueden convertirse en puntos débiles.
- En despliegues multi-cloud e híbridos, donde coexisten servicios en on-premise, nubes públicas y edge, la gestión de certificados ya era compleja; con ciclos de 47 días, la complejidad se multiplica.
- Equipos devops y de sistemas tendrán que revisar APIs internas, microservicios, túneles TLS, VPNs y dispositivos de red que usan certificados para autenticación mutua, no solo los típicos sitios web públicos.
La reducción drástica de la validez obliga a hacer un inventario exhaustivo de todos los lugares donde se usa TLS y a responder a una pregunta incómoda: ¿cuántos certificados de mi organización dependen aún de alguien conectándose por SSH y ejecutando tres comandos a mano?
El sistema de revocación en entredicho… y la vida corta como parche
El CA/Browser Forum también reconoce indirectamente otra realidad: el sistema de revocación clásico no es fiable. Tanto CRL como OCSP tienen problemas de rendimiento, disponibilidad y adopción, y muchos navegadores han optado por ignorarlos en escenarios de fallo para no degradar la experiencia del usuario.
La solución adoptada es pragmática: si no se puede confiar en la revocación, se reduce la vigencia del certificado. Así, incluso si la revocación no se aplica correctamente, el impacto temporal de un certificado comprometido será mucho menor.
En esta línea, ya se aprobaron en 2023 los certificados de corta duración (7 días), que directamente no requieren soporte de CRL u OCSP. La tendencia está clara: menos depender de revocación en tiempo real, más apoyo en una caducidad rápida y en automatización.
¿Y el coste para las empresas?
Una preocupación habitual de los clientes de las autoridades de certificación es si este cambio implicará pagar más por renovar certificados más a menudo. Los principales proveedores, sin embargo, han aclarado que su modelo se basa en suscripciones anuales o plurianuales, no en facturar cada emisión individual.
En otras palabras: si una organización ya tiene una suscripción activa con una CA, podrá emitir y renovar certificados dentro de ese período sin coste adicional por cada rotación, siempre que se ajuste a los límites del contrato.
De hecho, muchas CAs observan que, una vez se adopta la automatización, los propios clientes tienden a acortar voluntariamente los ciclos de vida, porque deja de ser un problema operativo y mejora la postura de seguridad.
¿Están los equipos de sistemas preparados?
Para los medios y comunidades de administradores de sistemas, la cuestión de fondo es estratégica:
- ¿Siguen existiendo certificados gestionados en hojas de cálculo?
- ¿Hay servicios críticos que dependen de un único técnico que “se acuerda” de renovarlos?
- ¿Está extendido ACME más allá del típico proxy de entrada?
- ¿Hay infraestructura donde una caducidad TLS implique dejar inaccesible no solo una web, sino procesos internos, backups o integraciones con terceros?
Con el calendario aprobado por el CA/Browser Forum, el tiempo de margen se acaba. Los próximos años, especialmente el salto a 100 días en 2027 y, sobre todo, a 47 días en 2029, serán una prueba de fuego para la madurez de los procesos de automatización TLS en empresas grandes y pequeñas.
La reducción de la vida útil de los certificados TLS es, sin duda, una mejora en seguridad. Pero también es una llamada directa a los sysadmin: ha llegado definitivamente la era en la que la gestión del ciclo de vida de certificados debe ser tan automatizada como las propias aplicaciones.
Preguntas frecuentes sobre la nueva vida útil de los certificados TLS
¿Cómo afectará la reducción a 47 días a los certificados de mis servidores?
En la práctica, obligará a diseñar procesos de renovación automática. No bastará con renovar una vez al año: cada servidor o servicio que use TLS necesitará una integración con un sistema de emisión y despliegue automatizado (ACME, pipelines DevOps o plataformas de gestión del ciclo de vida de certificados).
¿Es viable seguir renovando certificados manualmente con la nueva normativa?
Técnicamente sí, pero operativamente es inviable para la mayoría de organizaciones. Con validez máxima de 47 días y validación de dominio reutilizable solo durante 10, los procedimientos manuales acabarán provocando expiraciones, caídas de servicio y una carga de trabajo insostenible para los equipos de sistemas.
¿Qué pasos deberían dar los administradores de sistemas desde hoy?
Realizar un inventario completo de certificados, identificar los que no están automatizados, implantar clientes ACME allí donde sea posible, integrar alertas de expiración en los sistemas de monitorización y probar ciclos de renovación más cortos (por ejemplo, 60 o 90 días) antes de que las nuevas reglas sean obligatorias.
¿La reducción de la vida útil afecta igual a certificados DV, OV y EV?
Sí en cuanto a la duración máxima del certificado TLS. Sin embargo, hay diferencias en la información que se valida y se puede reutilizar: los certificados OV y EV, que incluyen datos de la organización (SII), verán reducida también la vigencia de esa validación, lo que obligará a revisar con más frecuencia los datos corporativos asociados a los certificados.
Fuente: Certificados SSL por 47 días y Digicert
