Let's Encrypt baja a 64 días sus certificados: qué cambia

Let's Encrypt anunció que el 10 de febrero de 2027 deja de emitir certificados de 90 días por defecto y pasa a 64. Si administrás tus propios servidores, no es una noticia para leer y archivar: hay una ventana de pruebas que abre la semana próxima y scripts viejos que pueden fallar sin que nadie se entere.

Los certificados de 64 días de Let's Encrypt son la nueva duración por defecto del perfil classic de su CA pública y gratuita. Sirven para cifrar con TLS sitios, APIs y servicios, y los emite para cualquier operador que automatice con ACME. Reemplazan a los de 90 días a partir del 10 de febrero de 2027. Son un paso intermedio hacia los 45 días previstos para febrero de 2028.

¿Cuándo empieza Let's Encrypt a emitir certificados de 64 días?

La emisión en producción empieza el 10 de febrero de 2027. Antes, el 14 de octubre de 2026, el entorno de staging pasa a emitir certificados de 64 días para que puedas probar tus renovaciones. Según el anuncio oficial de Let's Encrypt, el último certificado de 90 días vencería alrededor del 11 de mayo de 2027.

El perfil shortlived, de 6 días, sigue disponible para quien quiera ir más lejos. Esas fechas del perfil tlsserver, de 2027 y de 2028 ya figuraban en el plan publicado en diciembre de 2025. Lo nuevo de esta semana es el calendario concreto del paso intermedio.

¿Por qué Let's Encrypt acorta la vida de los certificados?

Lo hace para limitar el daño de una clave privada comprometida y para que la revocación funcione mejor, y también para alinearse con las reglas del sector. Let's Encrypt explicó que la reducción ayuda a "limiting the scope of compromise, and making certificate revocation technologies more efficient". Es una exigencia de los Baseline Requirements del CA/Browser Forum, que obligan a todas las CA públicas.

• Menos tiempo de exposición. Si te roban una clave o se emite un certificado por error, el certificado deja de ser válido solo, sin depender de que alguien revise una CRL.
• El calendario del sector. Según la ballot SC-081v3 del CA/Browser Forum, el máximo permitido baja a 200 días en marzo de 2026, a 100 en marzo de 2027 y a 47 en marzo de 2029 (resumen de TLS Radar). Let's Encrypt va por delante de ese techo.
• Tendencia clara. Cualquier proceso de renovación manual tiene fecha de caducidad, en todas las CA, no solo en Let's Encrypt.

¿Qué scripts de renovación se rompen con certificados de 64 días?

Se rompen los que renuevan en una cantidad fija de días desde la emisión y los que no tienen alertas. Let's Encrypt recomienda renovar a aproximadamente dos tercios de la vida del certificado, que en este caso es alrededor del día 43. Un job que renueva "a los 60 días" deja 4 días de margen. Uno que renueva a los 80 u 83 días directamente corre después del vencimiento.

• Cron con días hardcodeados. Buscá en tus scripts y pipelines valores como 60, 80 u 83. El anuncio oficial pide reemplazarlos por "dos tercios de la vida" y no por un número fijo.
• Renovaciones manuales. Let's Encrypt las desaconseja porque habrá que hacerlas más seguido. Con 64 días son unas seis por año, y con 45 días serán más de ocho.
• Servicios que no recargan. Renovar el archivo no alcanza si Nginx, HAProxy, Postfix o tu aplicación siguen sirviendo el certificado viejo en memoria. Verificá que exista un deploy hook o un reload automático.
• Falta de alertas. Con ciclos más cortos hay más ocasiones de que una renovación falle sin que nadie lo note. La guía oficial recomienda agregar alertas de falla de renovación.
• DNS-01 sin API. Si hoy actualizás TXT a mano, el cambio en la reutilización de autorizaciones te va a pegar (ver la sección siguiente).

¿Qué es la reutilización de autorizaciones y por qué baja a 10 días?

La reutilización de autorizaciones es el período en que Let's Encrypt acepta una validación de dominio ya hecha sin pedirte otro desafío. Baja de 30 a 10 días con el cambio de febrero de 2027 y a 7 horas en 2028. En la práctica, casi cada renovación va a exigir probar de nuevo el control del dominio.

• HTTP-01. El puerto 80 (o el endpoint del desafío) tiene que estar accesible en cada renovación. Si tu firewall o un redirect lo bloquea "salvo cuando renuevo a mano", ya no te sirve.
• DNS-01. Necesitás un plugin o una API de tu proveedor de DNS con credenciales de alcance mínimo. Si la zona no tiene API, es el momento de evaluar delegar el desafío con un CNAME a una zona que sí la tenga.
• DNS-PERSIST-01. Let's Encrypt mencionó este método nuevo, previsto para 2026, que permite dejar un registro TXT estático entre renovaciones. Todavía no lo cuento como algo que puedas usar hoy: revisá la documentación oficial para ver su estado actual.

¿Qué es ARI y por qué conviene activarlo?

ACME Renewal Information (ARI) es una extensión del protocolo ACME con la que la CA le indica a tu cliente cuándo renovar, sin depender de un calendario fijo. Según el anuncio, si tu cliente ya soporta ARI no necesitás cambios. Además de la ventana normal, permite que Let's Encrypt adelante renovaciones si tiene que revocar o reemplazar certificados.

• Otros clientes. acme.sh, lego, Caddy y el resto tienen distinto nivel de soporte. Revisá la documentación de la versión que tenés instalada, no la de la última release.

¿Los rate limits de Let's Encrypt cambian con renovaciones más frecuentes?

No. Let's Encrypt aclaró que sus rate limits afectan la emisión para dominios nuevos, pero que las renovaciones están exentas. El anuncio oficial agrega que los endpoints ACME y las cadenas de certificados no cambian. La cantidad de renovaciones por día se duplica, según la nota de rate limits de Let's Encrypt, pero eso no debería acercarte a ningún límite si renovás certificados existentes.

¿Cómo probar hoy que tu renovación aguanta 64 días?

Probalo contra el staging de Let's Encrypt a partir del 14 de octubre de 2026, y auditá tu configuración actual antes de esa fecha. Estos pasos sirven para un servidor con Certbot y se adaptan a otros clientes ACME.

1. Automatizá el reload y alertá si falla. Un --deploy-hook que recargue el servicio y un chequeo externo de vencimiento (con días restantes como umbral) cubren la mayoría de los incidentes.

Emití un certificado de prueba en staging. Desde el 14 de octubre vas a poder confirmar que tu flujo completo (desafío, deploy hook, reload) funciona con un certificado de 64 días:

certbot certonly --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --standalone -d staging-test.ejemplo.com

Usá un subdominio de prueba y verificá el flujo real de tu servidor, por ejemplo con --webroot o con el plugin de DNS que uses en producción.

Simulá una renovación. Certbot usa staging con --dry-run:

certbot renew --dry-run

Buscá valores fijos de renovación. Revisá crontabs, timers de systemd, pipelines de CI y scripts propios:

crontab -l
systemctl list-timers | grep -i certbot
grep -rEn "\b(60|80|83)\b" /etc/cron* /opt/scripts 2>/dev/null

El grep es una heurística y va a dar falsos positivos, pero sirve para encontrar candidatos.

Inventariá lo que tenés. Listá certificados y vencimientos:

certbot certificates
openssl x509 -enddate -noout -in /etc/letsencrypt/live/ejemplo.com/fullchain.pem

¿Conviene pasar ya a certificados de 45 días o de 6 días?

Para la mayoría de los servidores propios, no hace falta todavía: el default de 64 días ya exige automatización seria. Los 45 días del perfil tlsserver sirven como ensayo del escenario de 2028. Los de 6 días tienen sentido para infraestructura muy automatizada, con las mismas condiciones de ARI, alertas y reload. Si tu renovación falla un fin de semana, 6 días dejan muy poco margen.

Mi opinión: qué haría con esto

El cambio de 90 a 64 días es chico en sí mismo. Lo que importa es que marca el piso de automatización para los próximos años: 45 días en 2028 y 47 como tope general en 2029. Quienes hoy tienen un cron que "anda desde hace años" son los que más riesgo corren, porque nadie recuerda cómo se configuró. Mi recomendación es no esperar a febrero: revisá los scripts, probá en staging cuando abra y dejá alertas de vencimiento independientes del cliente ACME. Para el resto de las prácticas de acceso con credenciales de vida corta, mirá también la nota sobre la CA de OpenSSH y el acceso SSH por certificados.

Preguntas frecuentes

¿Cuándo pasa Let's Encrypt a certificados de 64 días?

El 10 de febrero de 2027 en producción. En staging, el cambio es el 14 de octubre de 2026.

¿Mis certificados actuales de 90 días se revocan o dejan de funcionar?

No. Los certificados ya emitidos siguen siendo válidos hasta su vencimiento. Let's Encrypt no planea revocarlos por este cambio, y el último de 90 días vencería alrededor del 11 de mayo de 2027.

¿A qué día conviene renovar un certificado de 64 días?

Alrededor del día 43, es decir, aproximadamente dos tercios de su vida, según la recomendación de Let's Encrypt. Eso deja unos 21 días para reintentar si algo falla.

¿Qué pasa si mi cliente ACME no soporta ARI?

Seguirá funcionando mientras renueve a tiempo con su lógica propia. Pierde la ventaja de que la CA le avise cuándo renovar. Lo importante es que el umbral no esté fijado en un número de días pensado para 90.

¿Cuándo llegan los certificados de 45 días por defecto?

El 16 de febrero de 2028, según el calendario publicado por Let's Encrypt. Ya podés probarlos hoy con el perfil opt-in tlsserver.

¿El cambio afecta a los certificados de otras CA?

No directamente, pero todas las CA públicas deben cumplir el calendario del CA/Browser Forum, que baja el máximo a 100 días en marzo de 2027 y a 47 en marzo de 2029. Si pagás certificados comerciales, vas a necesitar automatización igual.

Verificá fechas y detalles en el sitio oficial de Let's Encrypt antes de planificar, porque el calendario puede ajustarse.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting