Los certificados de 64 días de Let’s Encrypt sustituirán a los certificados de 90 días para los pedidos nuevos y renovados del perfil predeterminado classic Los pedidos de perfil el 10 de febrero de 2027. Los proveedores de alojamiento web y las agencias deben eliminar los intervalos de renovación fijos, confirmar la compatibilidad con ACME Renewal Information, automatizar la implementación y las recargas de los servicios, y probar el flujo de trabajo completo en el entorno de pruebas. Los certificados existentes no se revocarán, pero una automatización frágil podría dejar los sitios con certificados HTTPS caducados.
¿Cuándo entrarán en vigor los certificados de 64 días de Let’s Encrypt?
Los certificados de 64 días de Let’s Encrypt entrarán en vigor para los certificados emitidos o renovados con el perfil predeterminado classic de ACME el 10 de febrero de 2027. Según el anuncio de Let’s Encrypt del 7 de octubre de 2026, los certificados válidos existentes seguirán siendo válidos, y la organización espera que el último certificado predeterminado de 90 días caduque el 11 de mayo de 2027.
El cambio en producción no modifica los endpoints de ACME ni las cadenas de emisión de certificados de Let’s Encrypt, según el mismo anuncio de 2026. Por tanto, un cliente ACME moderno debería seguir comunicándose con la autoridad de certificación. El riesgo operativo se encuentra en otro punto: el momento de la renovación, la validación del dominio, la instalación del certificado, las recargas del servidor web y las alertas de errores.
Let’s Encrypt planea otra reducción el 16 de febrero de 2028, cuando los certificados predeterminados classic están previstos que pasen a tener una duración de 45 días. El periodo de reutilización de la autorización se reducirá de 30 días a 10 días el 10 de febrero de 2027, y después a siete horas el 16 de febrero de 2028. En consecuencia, más renovaciones requerirán una validación nueva del dominio.
La tendencia va más allá de una sola autoridad de certificación. Los requisitos del CA/Browser Forum limitarán los certificados de suscriptor de confianza pública a 47 días a partir del 15 de marzo de 2029, mientras que Let’s Encrypt ha seleccionado 45 días como objetivo. Let’s Encrypt afirmó en 2026 que unas duraciones más cortas reducen el periodo durante el cual una clave comprometida o un certificado emitido por error sigue siendo útil.
¿Por qué pueden fallar los scripts de renovación fija tras el cambio?
Los scripts de renovación fija pueden fallar con los certificados de 64 días de Let’s Encrypt cuando presuponen que todos los certificados duran 90 días o esperan 60 días antes de intentar renovarlos. Un retraso de 60 días deja solo cuatro días de validez en 2027, lo que reduce drásticamente el tiempo disponible para recuperarse de errores de validación, implementación o recarga del servicio.
El cálculo deja clara la опасidad. Con la duración de 90 días vigente en 2026, renovar el día 60 deja 30 días para recuperarse. Con la duración de 64 días que comenzará en 2027, el mismo calendario deja cuatro días. Cuando los certificados de 45 días se conviertan en el valor predeterminado en 2028, un script que espere 60 días no se ejecutará hasta 15 días después de la caducidad.
Let’s Encrypt aconsejó específicamente a los operadores de flotas en octubre de 2026 que buscaran en las tareas de cron, los scripts envoltorio y los procedimientos operativos valores codificados como 83, 80 o 60 días. También conviene revisar las plantillas de gestión de la configuración, los valores predeterminados de los paneles de alojamiento, los temporizadores de systemd, las canalizaciones de CI y la documentación copiada entre clientes. El procedimiento operativo olvidado suele ser más peligroso que la entrada de cron visible.
Hay que prestar atención a un caso límite: un comando de renovación puede ejecutarse correctamente mientras el sitio sigue sirviendo el certificado antiguo. Es posible que los archivos nuevos se hayan escrito correctamente, pero Nginx, Apache, HAProxy u otro endpoint TLS no los cargará necesariamente sin una recarga correcta. Sinceramente, la supervisión de la renovación que ignora el certificado presentado a través de la red es solo la mitad de un sistema de supervisión.
Las debilidades de seguridad en otros ámbitos también pueden complicar las operaciones de la flota. Las agencias que gestionan entornos WordPress deberían considerar la automatización de certificados como una capa más, junto con la corrección de problemas como una vulnerabilidad de Elementor que podría crear administradores no autorizados y el control de los riesgos de dependencias introducidos por el código generado por IA.
¿Cómo deberían decidir los clientes ACME cuándo renovar?
Los clientes ACME deberían utilizar ACME Renewal Information cuando sea compatible, ya que ARI permite a la autoridad de certificación proporcionar una ventana de renovación sugerida. Para los sistemas sin ARI, las directrices de Let’s Encrypt de octubre de 2026 recomiendan renovar aproximadamente cuando hayan transcurrido dos tercios de la duración real de cada certificado, en lugar de utilizar un número fijo de días antes de la caducidad.
ACME Renewal Information es un mecanismo de ACME que permite a una autoridad de certificación indicar a un cliente cuándo debe renovar un certificado concreto. ARI pasó a formar parte del IETF Standards Track RFC 9773 en junio de 2025. Sustituye las conjeturas basadas en una duración supuesta por una programación proporcionada por el servidor, que puede distribuir la demanda y adaptarse a los cambios en las políticas de certificados.
Para un certificado de 64 días en 2027, la alternativa de dos tercios sitúa el intento de renovación aproximadamente en el día 42,7, dejando unos 21,3 días antes de la caducidad. Para un certificado de 45 días en 2028, la misma regla fija el intento en el día 30 y deja 15 días. Estas ventanas proporcionan mucho más tiempo de recuperación que una tarea fija en el día 60.
| Perfil o periodo del certificado | Duración | Momento de renovación a los dos tercios | Validez restante |
|---|---|---|---|
| Predeterminado classic antes del 10 de febrero de 2027 | 90 días | Día 60 | 30 días |
| Predeterminado classic desde el 10 de febrero de 2027 | 64 días | Aproximadamente el día 43 | Aproximadamente 21 días |
| Predeterminado classic previsto desde el 16 de febrero de 2028 | 45 días | Día 30 | 15 días |
| Perfil shortlived opcional documentado en septiembre de 2026 | Aproximadamente 160 horas | Aproximadamente 107 horas | Aproximadamente 53 horas |
Compruebe por separado cada versión del cliente ACME y cada panel de control de alojamiento. Que haya un cliente moderno en el portátil de un administrador no demuestra que una imagen de servidor antigua, un dispositivo o una integración del panel sean compatibles con ARI. Pida a los proveedores la versión exacta que implementa RFC 9773 y, después, verifique el comportamiento mediante los registros en lugar de confiar en una casilla de verificación.
¿Certbot gestiona la menor duración de los certificados?
Certbot 4.0.0 y las versiones posteriores utilizan una programación de renovación proporcional adecuada para los certificados de 64 días de Let’s Encrypt. Según la documentación de Certbot disponible el 13 de octubre de 2026, Certbot considera que un certificado está listo para renovarse cuando queda menos de un tercio de su duración; los certificados con una duración de 10 días o menos utilizan un umbral equivalente a la mitad de la duración.
Puede ejecutar certbot renew con frecuencia, porque el comando comprueba la elegibilidad antes de solicitar un certificado. Certbot también admite acciones previas, posteriores y de despliegue, mientras que --dry-run realiza una prueba de renovación basada en el entorno de pruebas. Una acción de despliegue es el lugar adecuado para las operaciones que solo deben ejecutarse después de una renovación correcta, como volver a cargar Nginx.
No dé por hecho que todas las instalaciones de Certbot son automáticas. Los certificados creados con el --manual plugin no se renovarán sin intervención si no se han configurado acciones automatizadas de autenticación, según la documentación de Certbot de 2026. Los desafíos DNS son especialmente propensos a incluir pasos manuales ocultos cuando un proveedor no dispone de una integración de API o las credenciales han caducado.
Revise también los límites de privilegios. Las tareas de renovación pueden necesitar acceso a tokens de API de DNS, directorios de certificados y comandos de recarga, pero unas credenciales demasiado amplias aumentan el impacto de un host comprometido. El mismo principio aparece en amenazas de infraestructura más amplias, incluido el objetivo de la botnet Carbonato: los hosts Docker: las credenciales de automatización deben contar con permisos limitados y supervisión activa.
Lista de comprobación para una migración segura en flotas de alojamiento
Una migración segura a certificados de 64 días de Let’s Encrypt debe probar el descubrimiento, la validación, la emisión, el despliegue, la recarga de servicios y la verificación externa como un único flujo de trabajo. Está previsto que Let’s Encrypt cambie su entorno de pruebas a certificados predeterminados de 64 días el 14 de octubre de 2026, lo que dará tiempo a los equipos de alojamiento para realizar pruebas antes de la transición de producción del 10 de febrero de 2027.
Utilice la siguiente secuencia en una muestra representativa antes de ampliar la prueba a todos los sitios de los clientes:
- Inventarie las rutas y los propietarios de los certificados. Registre en 2026 cada nombre de host, cliente y versión de ACME, perfil, tipo de desafío, proveedor de DNS, ruta de instalación, terminal TLS y equipo responsable.
- Busque supuestos de temporización fijos. Busque en scripts, tareas cron, temporizadores de systemd, ajustes del panel de control y procedimientos operativos cálculos de 90 días y valores como 83, 80 o 60 días identificados por Let’s Encrypt en 2026.
- Confirme ARI o la renovación proporcional. Verifique la compatibilidad con RFC 9773 mediante la documentación y los registros del cliente. Cuando ARI no esté disponible, calcule el momento de activación a partir de la duración real del certificado.
- Pruebe con el entorno de pruebas. Ejecute el flujo completo de validación y despliegue después del 14 de octubre de 2026. Los certificados del entorno de pruebas de Let’s Encrypt no son de confianza pública y utilizan límites de frecuencia independientes y más altos destinados a pruebas y depuración.
- Pruebe las acciones de despliegue. Confirme los permisos de los archivos, la ubicación de la cadena de certificados y que las recargas se realicen correctamente en Nginx, Apache, HAProxy, servidores de correo, equilibradores de carga y cualquier CDN o proxy bajo su control.
- Verifique desde fuera del host. Conéctese a cada nombre de host público e inspeccione el certificado que se sirve realmente, incluida la caducidad, el emisor y los nombres alternativos del sujeto. Los archivos locales por sí solos no demuestran que el despliegue se haya realizado.
- Configure alertas con tiempo suficiente para recuperarse. Supervise las tareas de renovación fallidas y la caducidad de los certificados servidos. Dirija las alertas a un canal atendido, asigne la responsabilidad y pruebe la escalada antes del 10 de febrero de 2027.
Empiece por los sitios más complejos, no por los sencillos: certificados comodín, DNS de horizonte dividido, proxies multirregión, desafíos DNS manuales y servidores con varias capas de terminación TLS. A escala de flota, las pruebas por muestreo no bastan si las configuraciones de los clientes difieren. Un sitio situado detrás de un equilibrador de carga puede superar una comprobación local mientras un backend o una ubicación perimetral siguen sirviendo material obsoleto.
Los límites de frecuencia no deberían justificar el retraso del trabajo. Let’s Encrypt declaró el 24 de febrero de 2026 que las renovaciones siguen exentas de los límites de frecuencia de emisión, por lo que unas duraciones más cortas no requieren asignaciones mayores de límites de frecuencia para los suscriptores. El entorno de pruebas sigue siendo el lugar más seguro para realizar depuraciones repetidas, porque sus certificados no son de confianza y sus límites están diseñados para pruebas.
Preguntas frecuentes
¿Se revocarán los certificados de Let’s Encrypt existentes de 90 días?
Los certificados existentes de Let’s Encrypt de 90 días no se revocarán únicamente por la transición de duración de 2027, según el anuncio de Let’s Encrypt del 7 de octubre de 2026. Let’s Encrypt espera que el último certificado de 90 días del perfil predeterminado caduque el 11 de mayo de 2027.
¿Cambiarán las URL de ACME de Let’s Encrypt en febrero de 2027?
Los terminales de ACME y las cadenas de emisión de Let’s Encrypt no cambiarán como parte del paso a certificados predeterminados de 64 días del 10 de febrero de 2027, según el aviso operativo de 2026 de la autoridad de certificación.
¿Cuánto duran los certificados de corta duración de Let’s Encrypt?
Let’s Encrypt documentó el shortlived perfil de activación voluntaria como válido durante aproximadamente 160 horas, es decir, unos 6,7 días, el 8 de septiembre de 2026. El tlsserver perfil de activación voluntaria proporciona certificados de 45 días.
¿Puedo utilizar un certificado del entorno de pruebas de Let’s Encrypt en un sitio web público?
Los certificados del entorno de pruebas de Let’s Encrypt no son de confianza pública, según el glosario de la organización de 2026. Utilice el entorno de pruebas para comprobar la automatización de la emisión, la validación, el despliegue y la recarga; después, devuelva el cliente de ACME al entorno de producción para obtener un certificado de confianza para los navegadores.