Let’s Encrypt acorta tus certificados a 64 días y tu cron viejo puede quedar fuera de juego

Si mantienes servidores con TLS, esto te importa: Let’s Encrypt emitió el aviso que llevábamos esperando desde diciembre. El 10 de febrero de 2027, todos los certificados que emitan o renueven bajan de 90 a 64 días de vida por defecto. El último certificado de 90 días muere el 11 de mayo de 2027. Y no se detienen ahí: el plan publicado es llegar a 45 días como default en 2028, con perfiles opcionales de 45 o incluso 6 días para los que quieran apurar la transición.

¿La lógica? Simple y correcta: un certificado de corta duración reduce la ventana de daño si una llave se filtra o una autoridad emisora se equivoca. Menos tiempo de validez significa menos tiempo para explotar un certificado comprometido o mal emitido. Es la misma filosofía que empuja a los navegadores a recortar los máximos de la CA/Browser Forum año tras año.

El punto ciego: tus scripts viejos

Aquí viene mi parte favorita de la nota, porque huele a lo que cualquiera que administre servidores tiene escondido en alguna máquina: renewals hard-codeados. Si tu renovación está anclada a una fecha fija desde la expiración —típico de ese cron que escribiste en 2021 y que nunca más tocaste— necesitas actualizarla para renovar aproximadamente al 66% del lifetime del certificado. La recomendación concreta de Let’s Encrypt: hacer grep por números como 83, 80 o 60 en cron jobs, scripts y runbooks.

Lo bueno: si tu renovación está automatizada y tu cliente ACME soporta ARI (ACME Renewal Info), no tienes que hacer nada. ARI le deja a Let’s Encrypt decirle a tu cliente cuándo renovar, así el cambio es más o menos transparente. Caddy y los clientes modernos ya lo llevan. Lo que no soporta ARI y depende de fechas fijas es lo que se va a caer silenciosamente un martes cualquiera.

Otro detalle que casi nadie mira: la reutilización de autorizaciones

Mientras escribía esto revisaba mi propia flota y noté que el cambio más fácil de pasar por alto es otro: el periodo de reutilización de autorizaciones baja de 30 a 10 días (y a 7 horas en 2028). Si tu cliente ACME fue diseñado apoyándose en reusar validaciones viejas, puede fallar después del recorte. La mayoría de nosotros —que usamos certbot, acme.sh o Caddy con defaults— no notará nada, porque esos clientes no dependen del reuse period para operar.

Lo que haría hoy si fuera tú

Primero: prueba en staging. Desde el 14 de octubre de 2026 el ambiente de staging de Let’s Encrypt ya emite certificados de 64 días, así que puedes ensayar sin tocar producción. Segundo: revisa si tu cliente soporta ARI —un grep en la documentación basta— y si tu renovación usa fechas hard-codeadas. Tercero: aprovecha la bola: automatiza el reload del servicio y agrega alertas por si falla una renovación. Un certificado que no se renueva y del que nadie se entera es el clásico incidente self-inflicted que aparece tres semanas después, cuando los navegadores ya largan el warning.

Los rate limits no cambian con esto, y los endpoints ACME ni las cadenas de emisión tampoco. La migración debería ser aburrida, que es como deben ser las migraciones en servidores. Pero aburrida solo para quienes se preparan: los demás van a descubrir en mayo de 2027 que ese script de renovación que funcionaba «perfectamente» se quedó mirando un certificado vencido.

Fuente del tema: 64-Day Certificate Lifetimes Coming Feb 2027, del blog de Let’s Encrypt.

Fuente de inspiración: 64-Day Certificate Lifetimes Coming Feb 2027 – Let’s Encrypt