Let's Encrypt anunció el 7 de octubre que a partir del 10 de febrero de 2027 todos los certificados nuevos o renovados tendrán por defecto una validez de 64 días en lugar de los 90 actuales, salvo que el suscriptor ya haya elegido una vigencia más corta (45 o 6 días). La entidad no va a revocar los certificados de 90 días ya emitidos: el último de ellos caducará solo el 11 de mayo de 2027. Desde el 14 de octubre se puede probar el cambio en el entorno de staging, antes de que afecte a nada en producción.
El motivo que da la propia autoridad es reducir la ventana de exposición si se compromete una clave o se emite un certificado por error: cuanto menos dura un certificado, menos tiempo queda para que un fallo sea explotable antes de que caduque solo. Es la misma lógica que llevó al sector, empujado por Google y Apple, a acortar vigencias en los últimos años, y 64 días es la antesala de los 45 que Let's Encrypt ya tiene anunciados para 2028.
Afecta a cualquiera que emita certificados con Let's Encrypt, que es la autoridad por defecto de Caddy, Traefik, certbot y la inmensa mayoría de paneles de reverse proxy de un homelab. Si la renovación automática funciona bien, el cambio es invisible: Caddy y el cliente ACME de Traefik ya renuevan bastante antes de la caducidad por diseño. El problema puede aparecer en integraciones configuradas hace tiempo con un cron manual que renueva "faltando pocos días" para caducar: con 64 días de vigencia esa ventana se reduce a la mitad, y un fallo puntual del renovador (DNS caído, un rate limit, un script roto) tiene menos margen antes de que el certificado caduque de verdad.
Conviene revisar que cada renovación se dispare a dos tercios de la vigencia del certificado, no a un número fijo de días antes de caducar — es justo la recomendación que da Let's Encrypt en su propio anuncio. Quien use certbot con un cron a mano debería comprobar que ese margen sigue teniendo sentido con 64 días en vez de 90, y probarlo contra staging antes de febrero.
Fuentes: letsencrypt.org · linuxiac.com
