El ecosistema de certificados digitales va a cambiar de forma drástica en los próximos años. El CA/Browser Forum —el organismo que reúne a las principales autoridades de certificación (CA) y a los fabricantes de navegadores— ha aprobado un plan para reducir progresivamente la vida útil máxima de los certificados TLS hasta apenas 47 días a partir de 2029.
Detrás de este cambio está una idea sencilla, pero contundente: los certificados largos son cada vez menos fiables y la única forma de mantener la seguridad en la web pasa por revalidar con más frecuencia… y por automatizar por completo su gestión.
Un cambio histórico impulsado por Apple y apoyado por los grandes
La propuesta de acortar aún más la validez de los certificados TLS fue presentada por Apple en el seno del CA/Browser Forum mediante la “Ballot SC-81”. El texto plantea un calendario gradual que termina en 2029 con una vigencia máxima de 47 días. La votación se aprobó en abril de 2025 tras meses de debate con fabricantes de navegadores y autoridades de certificación.
Google, que previamente había defendido un límite de 90 días, apoyó la propuesta de Apple casi de inmediato, consolidando un consenso claro entre los grandes actores del ecosistema de navegadores y sistemas operativos.
Para el sector, el mensaje es inequívoco: la gestión manual del ciclo de vida de los certificados tiene fecha de caducidad.
Calendario de reducción: de 398 días a solo 47
Hasta ahora, el límite práctico más estricto era de 398 días de validez para un certificado TLS de servidor. Ese tope ya era el resultado de anteriores recortes (desde los históricos 3 y 5 años). Con la nueva norma, el CA/Browser Forum fija el siguiente calendario:
| Periodo | Validez máxima certificado TLS | Reutilización máxima de validación de dominio/IP | Reutilización SII (datos de empresa en OV/EV) |
|---|---|---|---|
| Hasta 15/03/2026 | 398 días | 398 días | 825 → 398 días (se acorta el límite) |
| Desde 15/03/2026 | 200 días | 200 días | 398 días |
| Desde 15/03/2027 | 100 días | 100 días | 398 días |
| Desde 15/03/2029 | 47 días | 10 días | 398 días |
Fuente: resumen de la ballot SC-81 y comunicaciones de CAs comerciales.
En la práctica, esto implica que, hacia finales de esta década:
- Un certificado TLS no podrá durar más de 47 días.
- La validación de control del dominio o IP (DCV) que usa la CA para emitirlo solo se podrá reutilizar durante 10 días.
Es decir, cualquier organización que siga pensando en “renovar una vez al año” quedará, sencillamente, fuera de juego.
Por qué se acorta tanto la vida de los certificados
Apple y otros impulsores del cambio argumentan varias razones de fondo:
- La información del certificado envejece mal
La titularidad o el control de un dominio, la infraestructura asociada o el responsable del servicio pueden cambiar con relativa rapidez. Cuanto más tiempo se reutiliza una validación antigua, más probable es que ya no refleje la realidad. - La revocación no funciona tan bien como debería
El sistema tradicional de revocación (CRL y OCSP) es problemático: las listas pueden ser enormes, hay fallos de conectividad, y muchos navegadores, de facto, ignoran o suavizan las comprobaciones de revocación para no penalizar el rendimiento ni la experiencia de usuario. Acortar la vida del certificado reduce el tiempo durante el cual un certificado comprometido puede seguir siendo aceptado. - La experiencia con certificados de corta duración es positiva
En 2023 el propio CA/Browser Forum abrió la puerta a certificados de muy corta duración (por ejemplo, 7 días) que ni siquiera requieren soporte de CRL u OCSP. Esa experiencia ha reforzado la idea de que certificados más cortos + automatización funcionan mejor que certificados largos + revocación tradicional. - El mundo ya se está moviendo hacia automatización
Proveedores como Let’s Encrypt demostraron que es viable emitir certificados de 90 días en masa usando el protocolo ACME, abaratando y automatizando la protección de millones de sitios en todo el mundo.
Con este contexto, la reducción a 47 días no es un capricho, sino la culminación de una tendencia: certificados cada vez más cortos y gestión cada vez más automatizada.
El papel de la automatización: de opción interesante a requisito imprescindible
La propia documentación de distintas CAs comerciales reconoce que, con este calendario, la gestión manual será inviable mucho antes de 2029.
ACME y otras soluciones de gestión del ciclo de vida
El estándar ACME (Automatic Certificate Management Environment) nació precisamente para automatizar la emisión y renovación de certificados, validando el control de dominio y desplegando nuevas credenciales sin intervención humana, mediante clientes como Certbot, acme.sh o integraciones en servidores web y dispositivos de red.
Además del mundo “gratuito” y comunitario, las grandes autoridades de certificación llevan años incorporando sus propias soluciones de automatización:
- Plataformas de gestión del ciclo de vida de certificados (CLM) con inventario centralizado.
- Integraciones ACME para certificados DV, OV e incluso EV, como ya ofrece DigiCert a través de sus plataformas empresariales.
- APIs específicas para despliegue y renovación automatizada en balanceadores, proxies TLS, WAFs o dispositivos IoT.
Quien no tenga hoy automatizado al menos el despliegue y renovación básica de certificados en servidores web, gateways y servicios críticos, tendrá que hacerlo sí o sí antes de 2027… y, con total seguridad, mucho antes de 2029.
Impacto para empresas, proveedores de hosting y administradores de sistemas
El cambio no se limita a “poner un cron para renovar certificados”. Afecta a procesos, herramientas y responsabilidades.
1. Inventario y visibilidad
Muchas organizaciones siguen sin tener un inventario completo de sus certificados: subdominios olvidados, servicios internos, APIs expuestas… Con ciclos de 47 días, cualquier “certificado perdido” es una caída garantizada en cuestión de semanas si no se integra en una plataforma de gestión centralizada.
2. Integración con infraestructuras críticas
Renovar automáticamente en un servidor web es relativamente sencillo. El reto está en:
- Balanceadores y proxies de capa 7.
- Dispositivos de red y firewalls que terminan TLS.
- Aplicaciones legacy o appliances donde la importación del certificado aún es manual.
Cada uno de esos puntos debe poder recibir nuevos certificados de forma automatizada (API, script, integración nativa o, en el peor caso, procedimientos periódicos muy bien orquestados).
3. OV/EV y procesos de compliance
En el caso de los certificados OV y EV, la reducción de la reutilización de la información de identidad del sujeto (SII) de 825 a 398 días no es tan agresiva como en el caso de los dominios, pero obliga igualmente a revisar procesos internos de compliance, KYC y gestión documental.
Las empresas que emiten muchos certificados OV/EV deberán asegurarse de que:
- La documentación corporativa está siempre al día.
- Los procesos con la CA para revalidar la identidad son fluidos y, en lo posible, parcialmente automatizables.
4. Cultura de “short-lived by design”
Finalmente, este cambio empuja a adoptar un enfoque de diseño donde todo lo relacionado con credenciales se asume de corta duración:
- Certificados externos con 47 días de vida máxima.
- Tokens, claves API y secretos gestionados también mediante rotación frecuente.
- Pipelines de CI/CD y despliegue que tratan la renovación de certificados como un evento rutinario, no como una excepción anual.
¿Qué deberían hacer las organizaciones desde hoy?
Aunque los cambios más agresivos llegan en 2029, el impacto práctico empieza ya en 2026. Algunas recomendaciones claras:
- Auditar todos los certificados existentes
- Dominios, subdominios, servicios internos, VPNs, APIs, balanceadores…
- Identificar quién es el responsable de cada uno y qué CA los emite.
- Adoptar ACME o soluciones equivalentes
- Para webs públicas, empezar por ACME con una CA adecuada al caso de uso.
- Para OV/EV, revisar qué opciones de automatización ofrece la CA actual (ACME empresarial, agentes, conectores, etc.).
- Centralizar la gestión y monitorización
- Utilizar plataformas de Certificate Lifecycle Management o, como mínimo, sistemas de monitorización que avisen con suficiente margen antes de cualquier caducidad.
- Rediseñar procesos internos
- Incorporar la emisión y renovación de certificados al ciclo estándar de cambios.
- Formar a equipos de desarrollo, seguridad y operaciones sobre la nueva realidad de ciclos de vida cortos.
- Hablar con las CAs y proveedores
- Ver qué herramientas de automatización ofrecen (ACME, APIs, agentes).
- Revisar contratos y modelos de suscripción para asegurarse de que la emisión frecuente no tenga impacto inesperado en costes.
Preguntas frecuentes sobre la reducción de la vida útil de los certificados TLS
¿Cómo afectará la nueva vida útil de 47 días de los certificados TLS a una pyme con pocos recursos técnicos?
Incluso las pequeñas empresas tendrán que abandonar los procesos manuales de renovación anual. La buena noticia es que existen soluciones gratuitas y comerciales basadas en ACME que permiten automatizar casi por completo la emisión y renovación de certificados, reduciendo el riesgo de caducidades inesperadas y sin necesidad de grandes inversiones en herramientas propias.
¿Qué herramientas existen para automatizar la renovación de certificados TLS en servidores web y balanceadores?
El protocolo ACME está soportado por numerosos clientes (Certbot, acme.sh, lego, etc.) y por muchas CAs, tanto gratuitas como comerciales. Además, los principales servidores web, proxies inversos y balanceadores modernos ya incluyen integraciones o plugins para hablar con una CA vía ACME o API, lo que permite automatizar la renovación y el despliegue sin intervención humana.
¿En qué se diferenciará la gestión de certificados DV, OV y EV con los nuevos plazos de validez?
Los certificados DV se verán más afectados por la reducción de la reutilización de la validación de dominio, obligando a automatizar completamente el control de dominio. En OV y EV, además de esa validación, las organizaciones deberán mantener actualizada la documentación de identidad corporativa, ya que la información de identidad del sujeto solo podrá reutilizarse durante 398 días, lo que implica revisiones periódicas más frecuentes.
¿Podré seguir utilizando certificados wildcard con estos nuevos límites de validez?
Sí, los certificados wildcard seguirán siendo posibles, siempre que la CA los ofrezca y se cumplan los requisitos de validación. Lo que cambia es que su vida útil máxima también se reducirá al mismo calendario (200, 100 y 47 días), por lo que deberán renovarse de forma mucho más frecuente y, por tanto, automatizada, igual que el resto de certificados TLS.
Fuentes:
CA/Browser Forum Ballot SC-81; documentación de Apple y Google sobre reducción de vida útil de certificados; artículos técnicos de digicert y otros proveedores sobre automatización y ACME; documentación pública sobre ACME y Let’s Encrypt; entradas de referencia en Wikipedia y en portales especializados en PKI y TLS.
