Let’s Encrypt reduce a 64 días los certificados TLS en 2027

Let's Encrypt baja a 64 días la vida de sus certificados TLS en febrero de 2027

Let's Encrypt, la autoridad certificadora gratuita operada por la Internet Security Research Group (ISRG) y que hoy protege a más de 500 millones de sitios web según datos publicados por la propia organización, anunció que recortará la vida útil de sus certificados TLS de 90 a 64 días a partir del 10 de febrero de 2027. El movimiento es parte de una hoja de ruta que apunta a 45 días en 2028 y que, en la práctica, vuelve obligatorio el protocolo ACME Renewal Information (ARI) para cualquier equipo que aún renueve con scripts de intervalo fijo.

Para la mayoría de operaciones que ya automatizan con clientes ACME modernos, el cambio será transparente. Para quienes todavía dependen de cron jobs con offsets hardcodeados como "renovar 60 días antes del vencimiento", febrero de 2027 será un deadline técnico con consecuencias inmediatas: certificados vencidos, sitios caídos y horas de guardia quemadas.

Qué cambia exactamente y desde cuándo

El recorte ya tiene fecha de pruebas. Desde el 14 de octubre de 2026 cualquier operador puede solicitar certificados de 64 días en el entorno de staging de Let's Encrypt, una ventana de cuatro meses para validar que la cadena de renovación funciona antes del despliegue en producción el 10 de febrero de 2027, según detalla el anuncio recogido por Ars Technica.

La decisión llega en paralelo al cronograma del CA/Browser Forum, el organismo que define las reglas para todas las autoridades certificadoras comerciales. El foro ya redujo la validez máxima regulatoria a 200 días en marzo de 2026, y prevé nuevas bajadas a 100 días en marzo de 2027 y a 47 días en marzo de 2029, según la hoja de ruta replicada en cobertura especializada de TechCrunch y analizada por Tech Times. Let's Encrypt no se alinea con el estándar: lo adelanta. Cuando en 2028 baje a 45 días, sus certificados serán más cortos que el límite regulatorio vigente en ese momento.

Por qué 64 días y no 90: la lógica criptográfica detrás

La motivación no es comercial sino de seguridad. Cuanto más breve es la vida útil de un certificado, menor es la ventana en la que una clave privada robada o un certificado emitido por error puede ser explotado. Antes del lanzamiento de Let's Encrypt a mediados de 2016 —financiado originalmente por patrocinadores como Cisco, Akamai y Google Chrome—, el estándar de la industria eran certificados de uno a tres años que se renovaban manualmente. Los 90 días de Let's Encrypt ya fueron una ruptura con esa inercia: forzaron la automatización que el mercado no había construido por sí solo.

Una década después, el problema ya no es la automatización, sino la resiliencia frente a claves comprometidas. Bajar a 64 días recorta la ventana de exposición en 26 días respecto al estándar actual. Para 2028, con 45 días, la reducción será de 45 días, casi la mitad del ciclo original.

ARI: el protocolo que separa a los que están listos de los que no

Aquí está la parte que de verdad importa a un founder. La transición no se trata solo de "renovar más seguido": se trata de cómo decide el cliente ACME cuándo renovar. La mayoría de despliegues heredados sigue un patrón determinista — un cron que se dispara a una fracción fija del ciclo — que dejará de funcionar en el momento en que la vida útil caiga por debajo del doble de ese intervalo. Si un script renueva a los 60 días, un certificado de 64 días deja apenas 4 días de margen para corregir errores antes del vencimiento.

La solución es ACME Renewal Information (ARI), un estándar que permite a la autoridad certificadora decirle al cliente cuándo es el momento óptimo de renovar según sus condiciones operativas reales: carga del servidor, congestión de red, certificados revocados o necesidad de reemisión anticipada. En lugar de calcular un offset fijo, el cliente pregunta al CA cuál es la ventana sugerida y la respeta. LWN describe el comportamiento esperado: "renovar a aproximadamente dos tercios del ciclo de vida actual del certificado", una métrica que solo puede calcularse dinámicamente.

Los clientes ACME más extendidos —certbot, acme.sh, Caddy, Lego— ya ofrecen soporte de ARI en sus versiones recientes, aunque el nivel de adopción real en despliegues corporativos suele ser bajo. El riesgo no es teórico: un certificado que vence en producción es un corte de servicio que se traduce en pérdida de ingresos, caída de ranking SEO y tickets de soporte acumulados.

Qué significa esto para tu startup

Si tu producto sirve tráfico HTTPS —SaaS, API, e-commerce, fintech, salud digital, cualquier cosa con un dominio público— dependes de Let's Encrypt o de un competidor suyo. El cambio del 10 de febrero de 2027 no es optativo, y la buena noticia es que tiene solución técnica conocida y probada.

Acciones concretas para implementar antes de febrero de 2027:

• Audita tu cliente ACME hoy mismo. Verifica versión y soporte de ARI en tu herramienta de renovación. La documentación de cada cliente indica cómo activarlo; no asumas que "funciona" solo porque el certificado se renueva.
• Mide tu ventana real de renovación. Si tu script actual dispara a 60 días del ciclo, tienes margen para un solo reintento. Con 64 días útiles eso es demasiado ajustado: cualquier rate limit del CA, fallo de red o problema de DNS te deja sin tiempo.
• Monta un dashboard de vencimientos. Aunque el cliente ACME renueve solo, necesitas visibilidad. Una métrica mínima: "días hasta el próximo vencimiento" en tu sistema de monitoring. Datadog, Grafana, Prometheus o un simple cron con curl a la API del CA sirve.
• Habilita ARI y deja que el CA decida. Es la única manera de sobrevivir al recorte de 2028 sin reescribir la automatización cada vez que Let's Encrypt baje el plazo de nuevo.
• Prueba el entorno de staging desde el 14 de octubre. Es la fecha en que Let's Encrypt empieza a emitir certificados de 64 días en staging. Quien automatice la validación ahora llegará a febrero sin incidentes.

El cronograma completo es claro: 200 días (marzo 2026, regulatorio) → 100 días (marzo 2027, regulatorio) → 64 días (febrero 2027, Let's Encrypt) → 45 días (2028, Let's Encrypt) → 47 días (marzo 2029, regulatorio). Cada paso reduce el margen de error humano. Los equipos que sigan con scripts de offset fijo pagarán el costo en incidentes; los que migren a ARI, probablemente no notarán la transición.

Fuentes

• Let's Encrypt cuts certificate lifetimes to 64 days starting February 2027 (fuente original)
• Let's Encrypt to reduce certificate lifetimes
• Post-Quantum TLS Certificates: Let's Encrypt Plans Merkle Tree Rollout
• The evolution of the Let's Encrypt certificate authority