Let’s Encrypt, la autoridad de certificación más usada del mundo para HTTPS, se prepara para volver a recortar a la mitad la vida útil de sus certificados.
Para 2028, todos los certificados estándar de Let’s Encrypt tendrán una validez máxima de 45 días, frente a los 90 días actuales.
No es un experimento aislado de Let’s Encrypt, sino parte de un giro de toda la industria. El cambio viene impulsado por el CA/Browser Forum, el organismo que marca las reglas entre navegadores y autoridades de certificación. Tras una propuesta inicial de Apple, el foro ha acordado que los certificados públicos (excepto los certificados raíz) tengan un límite máximo de 47 días. Let’s Encrypt se está alineando con ese requisito y, de paso, endurece algunas de sus propias políticas.
Para operadores, equipos DevOps y SRE, el mensaje es bastante claro:
Los certificados de vida corta son el futuro, y la renovación totalmente automatizada deja de ser opcional.
De 90 a 45 días: hoja de ruta del cambio
Let’s Encrypt emite hoy certificados con una validez de 90 días. Esa duración se reducirá en varias fases, dando a todo el ecosistema unos años para adaptarse:
Fase 1 – Perfil opcional de pruebas (13 de mayo de 2026)
- El perfil ACME
tlsserverpasará a emitir certificados con 45 días de validez. - Es un perfil opt-in, pensado para early adopters y entornos de test que quieran comprobar sus herramientas antes de que los límites se apliquen por defecto.
Fase 2 – Menos vida útil en el perfil clásico (10 de febrero de 2027)
- El perfil ACME por defecto, el perfil “classic”, empezará a emitir certificados de 64 días.
- El periodo de reutilización de autorizaciones (el tiempo durante el cual se puede reutilizar una validación de dominio) se reducirá a 10 días.
Fase 3 – Límite definitivo de 45 días (16 de febrero de 2028)
- El perfil clásico se actualizará de nuevo para emitir certificados de 45 días.
- La ventana de reutilización de autorizaciones se reducirá de forma drástica a 7 horas.
A partir de ese momento, cualquier certificado nuevo de Let’s Encrypt será, de facto, de vida corta. Los usuarios irán viendo la nueva duración según les toque el siguiente ciclo de renovación tras cada fecha.
Autorización de dominio: de 30 días a solo 7 horas
La validez del certificado no es lo único que se recorta. Let’s Encrypt también va a reducir el tiempo durante el que se puede reutilizar la prueba de control de un dominio.
Situación actual:
- Cuando un cliente demuestra que controla un dominio (mediante HTTP-01, TLS-ALPN-01 o DNS-01), esa autorización se puede reutilizar durante 30 días para emitir certificados adicionales para ese dominio.
Situación en 2028:
- Ese periodo de reutilización bajará a solo 7 horas.
En la práctica, significa que:
- Si el cliente ACME valida un dominio pero no llega a emitir el certificado dentro de esas 7 horas, tendrá que revalidar el dominio.
- Cualquier flujo de emisión frágil o demasiado manual quedará en evidencia rápidamente.
Para clientes ACME modernos, que funcionan de forma continua y automatizada, esto no debería ser un problema. Para despliegues manuales o semimanuales sí es una señal de alarma.
Por qué la industria empuja hacia certificados más cortos
Desde el punto de vista de la seguridad y de la PKI, acortar la vida de los certificados soluciona problemas crónicos:
- Menor impacto si se compromete la clave privada
Si alguien roba una clave privada, solo puede suplantar al sitio mientras el certificado siga siendo válido. Con certificados más cortos, esa ventana se limita por diseño, incluso si los mecanismos de revocación fallan o no se comprueban bien. - Menos dependencia de mecanismos de revocación poco fiables
CRL y OCSP llevan años en el punto de mira: son complejos, lentos y los clientes no siempre los respetan. Si los certificados se caducan rápido, hay menos presión sobre estos sistemas y menos “certificados zombie” circulando tras una intrusión. - La rotación frecuente de claves deja de ser una rareza
Con certificados de 45 días, la rotación es casi continua. Eso encaja con las buenas prácticas actuales en entornos cloud y de microservicios, donde las credenciales se tratan como elementos efímeros y no como recursos estáticos.
En resumen, el cambio aumenta la exigencia operativa, pero eleva el nivel de seguridad de la web pública.
ACME Renewal Information (ARI): que el propio CA te diga cuándo renovar
Para evitar que estos nuevos límites se traduzcan en un festival de certificados caducados, Let’s Encrypt impulsa el uso de ACME Renewal Information (ARI).
Con ARI, la autoridad de certificación puede indicar al cliente ACME cuándo debe renovar un certificado concreto, en lugar de que el cliente use reglas fijas del tipo “renueva siempre a los 60 días”.
En un mundo de certificados de 45 días, ese tipo de lógica estática es peligrosa:
- Un intervalo de renovación de 60 días ya no tiene sentido: el certificado habrá caducado antes.
- Un enfoque más seguro es renovar más o menos a dos tercios de la vida del certificado (≈ día 30 para uno de 45 días) o, idealmente, seguir las señales de ARI enviadas por el propio CA.
Para los operadores, las tareas concretas son:
- Comprobar si su cliente ACME (Certbot, acme.sh, integraciones en paneles de control, etc.) soporta ya ARI.
- Activar ARI en cuanto esté disponible y abandonar intervalos de renovación rígidos pensados para 90 días.
Las renovaciones manuales, en la práctica, están sentenciadas
Let’s Encrypt es muy claro en este punto: las renovaciones manuales no son una buena idea, y con estos cambios lo serán aún menos.
Con certificados de 45 días y ventanas de validación mucho más cortas, los procesos manuales:
- Son más frecuentes.
- Son más propensos al error humano.
- Tienen más probabilidades de acabar en un certificado caducado en producción.
En la práctica, cualquier entorno que siga dependiendo de un administrador entrando a mano a “renovar el certificado” es ahora un candidato perfecto a sufrir mensajes tipo “Tu conexión no es privada” en el navegador.
La única estrategia realista a futuro pasa por:
- Emisión y renovación 100 % automatizadas, incluyendo el despliegue de los certificados en servidores web, balanceadores de carga, proxies y APIs.
- Monitorización y alertas específicas sobre caducidad y fallos de renovación, en lugar de esperar a que los usuarios reporten el problema.
DNS-PERSIST-01: automatizar con menos dolor el reto DNS
Uno de los puntos más delicados de la automatización ACME siempre ha sido la validación de control del dominio. Todos los métodos actuales exigen que el cliente ACME interactúe en tiempo real con la infraestructura:
- HTTP-01: servir un token concreto por HTTP.
- TLS-ALPN-01: realizar un handshake TLS específico.
- DNS-01: crear o actualizar registros TXT en DNS.
Para organizaciones que no quieren dar a un cliente automático acceso amplio a servidores web o a la gestión DNS, esto puede ser un problema.
Para reducir esa fricción, Let’s Encrypt y otros actores están trabajando en un método nuevo llamado DNS-PERSIST-01:
- Se basa en un registro TXT persistente en DNS para demostrar el control del dominio.
- Ese registro no tiene que cambiar en cada renovación.
- Una vez configurado, se pueden renovar certificados de forma automática sin actualizar DNS en cada ciclo.
Let’s Encrypt espera que DNS-PERSIST-01 esté disponible alrededor de 2026, lo que facilitaría que entornos más conservadores adopten una automatización completa sin dar tanto acceso a sistemas sensibles.
Qué implica esto para operadores y plataformas
Para un público técnico —proveedores de hosting, plataformas SaaS, equipos DevOps, ingenieros de plataforma— las conclusiones son bastante directas:
- Si ya usas emisión y renovación automatizada con ACME, vas bien encaminado, pero conviene:
- Revisar que la lógica de renovación no dependa de ciclos de 60 días.
- Seguir de cerca el soporte de ARI en tu cliente y activarlo cuando sea posible.
- Si todavía usas renovaciones manuales o procesos semi-automatizados, estás a contrarreloj. La combinación de certificados de 45 días y autorizaciones reutilizables solo durante 7 horas acabará exponiendo cualquier debilidad en esos flujos.
- Si gestionas una plataforma que automatiza HTTPS para tus propios clientes, tendrás que:
- Verificar que tus clientes ACME gestionan bien tiempos de vida más cortos y ventanas de validación más estrictas.
- Reforzar la observabilidad y las alertas en torno al estado de los certificados y de las renovaciones.
La parte positiva es que, una vez que el ecosistema se adapte, la capa TLS de la web será más robusta, menos expuesta a compromisos de larga duración y más fácil de razonar desde la seguridad.
En resumen, el paso de Let’s Encrypt hacia certificados de 45 días no es solo un ajuste de configuración: es un cambio estructural en la forma en la que la web gestiona la confianza, la identidad y el cifrado a gran escala.
