Let’s Encrypt reducirá la validez de sus certificados TLS a 64 días desde el 10 de febrero de 2027

Let’s Encrypt, la autoridad de certificación gratuita más utilizada para habilitar HTTPS, anunció que recortará la vigencia por defecto de sus certificados TLS de 90 a 64 días a partir del 10 de febrero de 2027. La organización indica que existe un plan posterior para reducirla nuevamente a 45 días en 2028.

Qué cambia y cuándo entra en vigor

A partir del 10 de febrero de 2027, todos los certificados emitidos o renovados por Let’s Encrypt tendrán una validez de 64 días, salvo que el usuario elija explícitamente alguna de las opciones más cortas que la CA ya ofrece (por ejemplo, 45 días o 6 días). Los certificados existentes seguirán siendo válidos hasta su fecha de caducidad: la última emisión con 90 días expirará en las fechas ya establecidas y la organización ha confirmado que no revocará certificados válidos durante la transición.

Pruebas en staging y preparación

Para facilitar la adaptación, Let’s Encrypt habilitará certificados de 64 días en su entorno de staging el 14 de octubre de 2026. Ese entorno permite a administradores y desarrolladores verificar que sus procesos de renovación (clientes ACME, scripts y automatizaciones) funcionan correctamente antes del cambio en producción.

Impacto para administradores y qué deben revisar

La reducción de la validez mejora la seguridad, porque acorta el tiempo durante el cual una clave privada robada o un certificado mal emitido puede ser utilizado por un atacante. Sin embargo, exige renovaciones más frecuentes, por lo que los responsables de sitios y servidores deben comprobar su infraestructura de gestión de certificados:

• Clientes ACME modernos: Si su ACME client soporta ACME Renewal Info (ARI), la adaptación debería ser transparente; ARI permite que la CA indique cuándo conviene renovar en lugar de depender de calendarios fijos.
• Sistemas automatizados: Para instalaciones que ya usan herramientas automatizadas (por ejemplo, Certbot, acme.sh u otros clientes compatibles), la mayoría no requerirá cambios si usan los comportamientos recomendados por el cliente.
• Cron y scripts con intervalos fijos: Administradores que dependan de tareas programadas con valores rígidos (por ejemplo, renovaciones planificadas a X días antes de expiración) deben revisar y actualizar esos cron jobs. Let’s Encrypt recomienda programar la renovación después de haber transcurrido aproximadamente dos tercios del periodo de validez, en lugar de usar números concretos que pueden dejar de ser fiables con certificados más cortos.
• Valores codificados: Compruebe configuraciones y scripts en busca de valores como 83, 80 o 60 días hardcodeados; con la vigencia recortada esos umbrales pueden provocar renovaciones fallidas o retrasadas.

Cambios en la reutilización de autorizaciones de dominio

Let’s Encrypt también reducirá el tiempo durante el cual una autorización de dominio previamente completada puede reutilizarse: pasará de 30 días a 10 días y, en 2028, se prevé un nuevo recorte hasta unas pocas horas (la organización ha mencionado un objetivo de siete horas). Esto afecta a flujos ACME que dependen de volver a usar autorizaciones previas para emitir certificados sin volver a validar el control del dominio.

Qué deben hacer los equipos técnicos ahora

1. Probar la renovación en el entorno de staging de Let’s Encrypt (desde la fecha indicada) para detectar fallos antes del cambio en producción.
2. Actualizar scripts y cron jobs que contengan intervalos fijos; preferir la lógica de “renovar a los dos tercios de la vida” o usar ARI cuando el cliente lo soporte.
3. Verificar si el ACME client reutiliza autorizaciones de dominio y actualizarlo o ajustar flujos si depende del periodo de 30 días.
4. Documentar el nuevo calendario de renovaciones y monitorizar las alertas de expirar en los paneles de control o herramientas de gestión de certificados.

Let’s Encrypt ha indicado que los endpoints ACME, límites de emisión y cadenas de certificación no cambiarán con esta transición. Para proyectos y servidores con renovación automatizada bien configurada, el impacto será mínimo; para sistemas con procesos manuales o scripts rígidos, la revisión y ajuste son necesarios para evitar interrupciones en HTTPS.

Lee también:

• BTR (Spectre v2) permite leer memoria del kernel en varias versiones de CloudLinux; la corrección llegará con los kernels de los proveedores
• FBI anuncia un nuevo arresto relacionado con el presunto grupo ShinyHunters tras la filtración del portal de empleo

Fuente: Linuxiac