Let’s Encrypt de 90 a 45 días: ARI, perfiles ACME y cómo renovar sin romperte en 2027

El 7 de octubre de 2026 Let’s Encrypt publicó un anuncio que parece menor y no lo es: a partir del 10 de febrero de 2027, todos los certificados que emitan tienen 64 días de validez en lugar de 90. Y en 2028 bajan a 45. No es un ajuste gradual ni opcional: es el valor por defecto para todo el mundo, con la única excepción de quien pida explícitamente un perfil más corto.

Cuando leí el anuncio, mi primer pensamiento no fue “quéDATE bien” sino “qué se rompe”. Porque hay una diferencia enorme entre tener un certificado que dura 90 días y tener uno que dura 64, y la diferencia está en todas las automatizaciones que tienen un 60, un 80 o un 83 hardcodeados. He visto scripts de renovación con --days 60 escritos a mano hace años, y van a seguir funcionando —hasta que dejan de hacerlo de forma silenciosa en algún momento de 2027.

Esta guía es el plan de migración: qué cambia exactamente, cuándo, qué perfiles existen, cómo funciona ARI (la tecnología que hace que la renovación sea inteligente en lugar de adivinar), y los cinco sitios concretos donde tienes que revisar tu configuración antes de febrero de 2027.

---

Índice

1. [El calendario: qué cambia y cuándo](#el-calendario-qué-cambia-y-cuándo)
2. [Por qué.reduce los lifetimes y qué significa para ti](#por-qué-se-reducen-los-lifetimes-y-qué-significa-para-ti)
3. [Los perfiles ACME: classic, tlsserver y shortlived](#los-perfiles-acme-classic-tlsserver-y-shortlived)
4. [ARI: la renovación que deja de adivinar](#ari-la-renovación-que-deja-de-adivinar)
5. [Los cinco sitios donde tienes que revisar tu configuración](#los-cinco-sitios-donde-tienes-que-revisar-tu-configuración)
6. [El período de reutilización de autorizaciones](#el-período-de-reutilización-de-autorizaciones)
7. [Monitoreo: lo que Let’s Encrypt te pide a cambio](#monitoreo-lo-que-lets-encrypt-te-pide-a-cambio)
8. [Migración paso a paso](#migración-paso-a-paso)
9. [Conclusión](#conclusión)

---

El calendario: qué cambia y cuándo

Let’s Encrypt.reduce la validez de los certificados en fases, usando los perfiles ACME para que cada suscriptor controle cuándo le afecta. Este es el calendario oficial completo, con las fechas de los anuncios originales:

Fecha	Qué cambia	Perfil afectado	A quién afecta
13 mayo 2026	El perfil tlsserver empieza a emitir certificados de 45 días	tlsserver	Solo quien lo pida explícitamente. Hay que pedirlo explícitamente, para los que adelantan el cambio y para las pruebas
10 febrero 2027	El perfil classic pasa a emitir de 64 días, con período de reutilización de autorización de 10 días	classic (por defecto)	Todos, salvo los que hayan elegido otro perfil
16 febrero 2028	El perfil classic pasa a 45 días, con período de reutilización de 7 horas	classic (por defecto)	Todos los que sigan en el perfil por defecto
15 marzo 2029	La industria limita la vida máxima de los certificados a 47 días	Reglas del CA/Browser Forum	Todas las CAs del Web PKI, no solo Let’s Encrypt

Dos datos del anuncio de octubre de 2026 que conviene tener claros porque suelen malinterpretarse:

El último certificado de 90 días expira el 11 de mayo de 2027. Es decir, hay certificados de 90 días en circulación hasta esa fecha. Si tienes uno emitido hoy, seguirá funcionando hasta su expiración normal.

No se revocan certificados válidos. Let’s Encrypt no va a revocar los certificados de 90 días que ya emitiste; simplemente no emitirá más de esa longitud. Es una transición, no un corte.

Y un dato que afecta a tu planificación: Let’s Encrypt cambió su entorno de staging a 64 días el 14 de octubre de 2026. Si hoy haces un --dry-run contra staging, ya estás probando con la duración real que llegará a producción en febrero de 2027. Eso es deliberado: la recomendación oficial es probar en staging antes de que el cambio llegue a producción, y el staging se adelantó para que pudieras hacerlo.

---

Por qué se reducen los lifetimes y qué significa para ti

Let’s Encrypt explica el motivo en su anuncio: reducir la ventana de compromiso reduce el riesgo de que una clave privada filtrada o un certificado emitido por error causen daño. La lógica es directa: si una clave se compromete, el daño lasts 90 días en lugar de un año. Con 45 días, es menos de la mitad.

Es la dirección correcta. La industria lo confirma: el CA/Browser Forum ya fijó 47 días como máximo para 2029, y Let’s Encrypt quiere llegar ahí antes de que la regulación lo imponga.

Pero el cambio tiene un costo para quien opera. Tres consecuencias concretas:

• Menos margen de error. Un certificado de 64 días con una renovación automática que falla tres veces te deja sin margen. Con 90 días, tres fallos probablemente no te rompían nada.
• Más renovaciones significan más peticiones y más riesgo de rate limit. Una renovación con ARI cuenta como renovación y no consume el límite de 5 certificados por conjunto de nombres. Renewal sin ARI, o basado en fechas, puede contarse como pedido nuevo en algunos casos.
• El período de reutilización de autorizaciones se reduce drásticamente, lo que cambia la economía de las renovaciones. Volvemos a esto en detalle, porque es el cambio con más consecuencias ocultas.

En resumen: la reducción de lifetimes no es un problema para quien tiene una automatización correcta y un monitoreo activo. Es un problema para quien tiene un cron que dice “renovar si faltan 60 días” porque nunca lo revisó, y para quien no tiene ninguna alerta de expiración.

---

Los perfiles ACME: classic, tlsserver y shortlived

Let’s Encrypt permite seleccionar el perfil con el que se emite el certificado desde enero de 2025, y desde el 13 de mayo de 2026 el perfil tlsserver emite ya certificados de 45 días. El perfil determina tanto la validación como el contenido del certificado. Estos son los tres que existen según la documentación oficial de perfiles, actualizada el 4 de octubre de 2026:

Propiedad	classic	tlsserver
Validez	90 días (64 desde feb-2027, 45 desde feb-2028)	45 días
Vida de autorización pendiente	7 días	1 hora
Período de reutilización de autorización	30 días (10 desde feb-2027)	7 horas
Vida de la orden	7 días	2 horas
Common Name	Sí	No
Key Usage con cifrado de clave	Sí (solo en claves RSA)	No
Información de revocación	CRL	Sin CRL (vida corta lo hace innecesario)
Máximo de nombres	100	100
Tipos de identificador	DNS	DNS

Existe además un perfil shortlived de 6 días, mencionado en el anuncio de 2025 como opción para quien quiera el máximo de seguridad y tiene la automatización para sostenerlo.

Qué perfil te sirve a ti: el classic por defecto, sin cambiar nada, salvo que tu automatización esté preparada y quieras el beneficio del perfil tlsserver. Las diferencias prácticas del perfil tlsserver son:

• Certificados más pequeños: sin Common Name y sin Key Usage de cifrado de clave. Los clientes modernos validan por SAN, así que el Common Name es redundante —de hecho lleva años siendo ignorado.
• Sin CRL: con 45 días de vida, la revocación no es un mecanismo práctico. Esto simplifica la cadena de confianza.
• Validación casi instantánea: una hora de vida de autorización significa que la validación tiene que ser automatizada de verdad. Si tu emisión es manual, vas a tener problemas.

Cómo se selecciona el perfil es un detalle del cliente ACME, no del servidor. En certbot la opción es --preferred-profile:

# Ver los perfiles que tu cliente anuncia
sudo certbot certonly --help | grep -A5 profile
# Emitir con el perfil tlsserver
sudo certbot certonly 
  --dns-cloudflare 
  --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini 
  -d tudominio.com -d '*.tudominio.com' 
  --preferred-profile tlsserver

Y para comprobar con qué perfil se emitió un certificado existente, la información está en la propia cadena:

sudo openssl x509 -in /etc/letsencrypt/live/tudominio.com/fullchain.pem -noout -text | grep -E "Not After|Subject:|X509v3 Subject Alternative Name"
# Not After: Nov 26 12:00:00 2026 GMT
# X509v3 Subject Alternative Name:
#     DNS:tudominio.com, DNS:*.tudominio.com

Una diferencia visible entre perfiles: el tlsserver no incluye Common Name, así que subject= sale vacío. Y la fecha Not After te dice de inmediato con qué perfil estás trabajando.

---

ARI: la renovación que deja de adivinar

Este es el mecanismo que hace que la transición sea viable, y merece una explicación clara porque mucha gente todavía lo asocia con “renovar a los 60 días”.

El problema histórico: el cliente ACME no sabe cuándo le conviene renovar. La heurística traditional era “renovar cuando falte un tercio de la vida del certificado”, lo que con 90 días significaba renovar al día 60. Con 64 días sería al día 43; con 45, al día 30. Cada vez que la CA cambia la validez, los clientes con la heurística hardcodeada quedan desfasados.

La solución: ACME Renewal Information (ARI). ARI es una extensión del protocolo ACME donde la CA le dice al cliente en qué ventana concreta debe renovar. El cliente consulta ese dato, calcula su propia ventana de renovación y renueva dentro de ella, dejando que la CA decida el momento exacto.

El anuncio de Let’s Encrypt es explícito:

“Si tus renovaciones están automatizadas y tu cliente soporta ACME Renewal Info (ARI), deberías estar listo, porque ARI permite que Let’s Encrypt le diga a tu cliente cuándo renovar.”

Y también da la instrucción para quien no usa ARI: renovar a aproximadamente dos tercios de la vida del certificado. Con 64 días, eso es alrededor del día 43; con 45 días, del día 30. Y avisa de un detalle que ha causado caídas de producción: “busca números escritos a mano como 83, 80 o 60 en las tareas de cron, los scripts envoltorio y los manuales de procedimientos si no estás seguro”.

El beneficio colateral de ARI es el rate limit. Let’s Encrypt reconoce un pedido como renovación de dos maneras: la preferida es ARI, y la alternativa es que el servidor detecte que el certificado a renovar es una renovación del mismo conjunto de identificadores. Con ARI, la renovación no cuenta contra los límites de “nuevos pedidos por cuenta” ni de “certificados por dominio registrado”, y tampoco contra el límite de 5 certificados por conjunto exacto de nombres.

Esto es importante en la práctica: sin ARI, una renovación mal detectada puede comerte el límite de 5 por conjunto de nombres cada 7 días, y la reposición de ese límite es de uno cada 34 horas. Un solo error de configuración repetido puede dejarte sin poder renovar durante días.

Verificar si tu cliente soporta ARI. No hay un comando universal, pero en certbot puedes comprobar la versión y consultar la documentación:

sudo certbot --version
# certbot 5.8.0
# Ver si el directorio ACME anuncia el recurso de ARI
curl -s https://acme-v02.api.letsencrypt.org/directory | python3 -m json.tool
# {
#     "newNonce": "https://acme-v02.api.letsencrypt.org/new-nonce",
#     "newAccount": "https://acme-v02.api.letsencrypt.org/new-account",
#     "newOrder": "https://acme-v02.api.letsencrypt.org/new-order",
#     ...
#     "renewalInfo": "https://acme-v02.api.letsencrypt.org/renewal-info"
# }

La clave renewalInfo en el directorio del servidor ACME es la señal de que el servidor anuncia soporte de ARI. Si tu cliente puede consumir ese recurso, está soportado.

Los clientes que soportan ARI a día de hoy son las versiones recientes de certbot (la serie 5.x), acme.sh en versiones recientes, lego de Go, cert-manager de Kubernetes y win-acme en Windows. Si usas algo más antiguo, la migración del cliente es el primer paso de todo el plan.

---

Los cinco sitios donde tienes que revisar tu configuración

Esta es la lista concreta. Son los cinco lugares donde un valor escrito a mano te va a pasar por encima en 2027.

1. El cron o timer que llama a la renovación. Si tu script tiene un --days 60 o un --days 80 explícito, cámbialo a la regla de los dos tercios, o mejor: borra el parámetro y deja que el cliente decida con ARI.

# MAL: fijo en 60 dias, incompatible con 45 y con 64
certbot renew --days 60
# BIEN: sin --days, el cliente usa ARI si lo soporta
certbot renew --quiet --deploy-hook "systemctl reload nginx"

2. Los hooks que asumen la fecha de expiración. Un deploy-hook que calcula “expiración menos 30 días” deja de ser una ventana de seguridad razonable cuando el certificado dura 45.

# MAL: asume 90 dias de vida
EXPIRY=$(openssl x509 -enddate -noout -in /etc/letsencrypt/live/$DOMAIN/fullchain.pem | cut -d= -f2)
DAYS_LEFT=$(( ( $(date -d "$EXPIRY" +%s) - $(date +%s) ) / 86400 ))
if [ "$DAYS_LEFT" -lt 30 ]; then echo "renovar"; fi
# BIEN: porcentaje de vida restante, no dias absolutos
LIFETIME=$(openssl x509 -in /etc/letsencrypt/live/$DOMAIN/fullchain.pem -noout -text | grep -oE "Validity.*" )
# mejor: calcular sobre la fecha de emision (Not Before) y Not After
NOT_BEFORE=$(openssl x509 -in /etc/letsencrypt/live/$DOMAIN/fullchain.pem -noout -startdate | cut -d= -f2)
NOT_AFTER=$(openssl x509 -in /etc/letsencrypt/live/$DOMAIN/fullchain.pem -noout -enddate | cut -d= -f2)
TOTAL=$(( $(date -d "$NOT_AFTER" +%s) - $(date -d "$NOT_BEFORE" +%s) ))
LEFT=$(( $(date -d "$NOT_AFTER" +%s) - $(date +%s) ))
PCT=$(( LEFT * 100 / TOTAL ))
if [ "$PCT" -lt 34 ]; then echo "renovar (queda ${PCT}% de vida)"; fi

El porcentaje es invariante al cambio de lifetime, que es justo lo que necesitas. Con ARI esto es redundante, pero si tu cliente no lo soporta, es la alternativa correcta.

3. El monitoreo con umbral fijo. Una alerta que dispara “quedan 14 días” es razonable con 90 y absurda con 45. En porcentaje, o con dos niveles: warning al 50% y critical al 25%.

# Porcentaje de vida restante (ver bloque anterior para NOT_BEFORE/NOT_AFTER)
if [ "$PCT" -lt 50 ]; then NIVEL="WARNING"; fi
if [ "$PCT" -lt 25 ]; then NIVEL="CRITICAL"; fi
echo "Certificado $DOMAIN: ${PCT}% de vida restante - ${NIVEL}"

4. Los runbooks y la documentación. Si tu wiki dice “el certificado se renueva cada 60 días” o “los certificados duran 90 días”, eso ya no es cierto. Documentación desactualizada en un manual de procedimientos es la forma más común de que un incidente se alargue.

5. Los sistemas que asumen que el certificado no cambia. Hay una categoría de software que cachea el certificado al inicio y no lo recarga. Si tu servicio no tiene un deploy-hook que lo recargue, con 90 días tenías hasta tres meses para notarlo; con 45, dos semanas.

# Verificar que el servicio recarga el certificado
sudo systemctl list-timers | grep certbot
sudo journalctl -u certbot-renew --since "30 days ago" --no-pager | tail -20
# Y comprobar que el certificado SERVIDO coincide con el de disco
echo | openssl s_client -connect tudominio.com:443 -servername tudominio.com 2>/dev/null | openssl x509 -noout -enddate
sudo openssl x509 -in /etc/letsencrypt/live/tudominio.com/fullchain.pem -noout -enddate
# Las dos fechas deben coincidir

Esa comparación es el test definitivo de que tu hook funciona. Si las dos fechas difieren, tu servidor está sirviendo un certificado viejo.

---

El período de reutilización de autorizaciones

Este es el cambio con más consecuencias ocultas, y el que casi nadie menciona en los resúmenes del anuncio.

Cuando ACME valida un dominio, ese resultado (la “autorización”) se puede reutilizar para emitir más certificados sin volver a validar. El período durante el cual se puede reutilizar es lo que cambia:

• Hasta febrero de 2027: 30 días (perfil classic), 7 horas (perfil tlsserver).
• Desde febrero de 2027: 10 días (perfil classic).
• Desde febrero de 2028: 7 horas (perfil classic).

Why importa. Si emites un certificado para *.tudominio.com y un día después quieres emitir otro para vault.tudominio.com, con 30 días de reutilización el servidor de Let’s Encrypt ya sabe que controlas la zona y te emite el segundo certificado sin nueva validación. Con 7 horas de reutilización, tienes que volver a validar, lo que significa otro challenge DNS-01, otro registro TXT, otra espera de propagación.

El motivo del cambio es regulatorio y técnico: el CA/Browser Forum exige re-verificar el registro CAA después de 8 horas, y reducir el período de reutilización a 7 horas elimina esa necesidad. El efecto secundario es que se eliminan los “re-checks” de CAA.

Qué significa para tu operación: si tienes un proceso que emite varios certificados seguidos relying en la reutilización de autorizaciones —por ejemplo un script que crea un wildcard y luego varios subdominios en lote— vas a necesitar re-validaciones. Con el plugin de DNS de certbot, la re-validación es automática y el costo es solo la espera de propagación. Si haces validación manual, prepárate para más pasos.

Y un detalle sobre el perfil tlsserver: su período de reutilización ya es de 7 horas, así que adoptar ese perfil te pone hoy en el comportamiento que llegará al perfil classic en 2028. Es otra razón para probar ese perfil si tienes la automatización preparada.

---

Monitoreo: lo que Let’s Encrypt te pide a cambio

El anuncio de octubre de 2026 usa la transición como excusa para algo más importante: automatizar la gestión de certificados, incluyendo la recarga y el despliegue, y añadir alertas por fallos de renovación.

Let’s Encrypt mantiene una página de opciones de monitoreo con servicios externos —Red Sift Certificates (antes Hardenize), UptimeRobot, Datadog SSL Monitoring, TrackSSL, Host-Tracker, CertKit, CertObserver y Chill SSL— y aclara que ninguno está afiliado a ISRG y que la decisión es del usuario. La página fue actualizada el 13 de julio de 2026.

Mi recomendación es no depender de un servicio externo para lo crítico y montar una comprobación local, porque tiene dos ventajas: no depende de un tercero y puede integrado con el sistema de alertas que ya tengas.

La comprobación mínima, en porcentaje de vida restante:

sudo tee /usr/local/bin/check-cert-life > /dev/null
#!/bin/bash
# Verifica el porcentaje de vida restante del certificado en disco
DOMAIN="${1:-tudominio.com}"
CERT="/etc/letsencrypt/live/${DOMAIN}/fullchain.pem"
if [[ ! -f "$CERT" ]]; then
    echo "CRITICO: no existe $CERT"
    exit 2
fi
NB=$(openssl x509 -in "$CERT" -noout -startdate | cut -d= -f2)
NA=$(openssl x509 -in "$CERT" -noout -enddate | cut -d= -f2)
TOTAL=$(( $(date -d "$NA" +%s) - $(date -d "$NB" +%s) ))
LEFT=$(( $(date -d "$NA" +%s) - $(date +%s) ))
PCT=$(( LEFT * 100 / TOTAL ))
echo "Certificado ${DOMAIN}: ${PCT}% de vida restante, expira ${NA}"
if [[ "$PCT" -lt 25 ]]; then
    echo "CRITICO: menos del 25% de vida restante. Revisar la renovacion."
    exit 1
fi
if [[ "$PCT" -lt 50 ]]; then
    echo "WARNING: menos del 50% de vida restante. Revisar la renovacion."
    exit 1
fi
exit 0

sudo chmod +x /usr/local/bin/check-cert-life
sudo /usr/local/bin/check-cert-life tudominio.com
# Certificado tudominio.com: 72% de vida restante, expira Nov 26 12:00:00 2026 GMT

Un porcentaje en lugar de un número de días hace que la alerta sea correcta antes, durante y después de la transición, sin tocar nada. Y los dos niveles (50% y 25%) te dan el tiempo de reacción que con 90 días no tenías.

Para el certificado que se está sirviendo, no el de disco, la verificación es la comparación de fechas del punto 5 de la sección anterior.

---

Migración paso a paso

El plan completo, en orden. Si haces una sola cosa de esta lista, haz la número 1.

1. Sube tu cliente ACME a una versión que soporte ARI. Es el requisito previo de todo lo demás. Con ARI, la mayoría de los problemas de la transición desaparecen solos porque el cliente deja de calcular fechas por su cuenta.

# Ubuntu / Debian
sudo apt update && sudo apt install --only-upgrade certbot
certbot --version
# RHEL / Rocky
sudo dnf upgrade certbot
certbot --version
# Si usas acme.sh
acme.sh --upgrade
acme.sh --version

2. Inventaría todos tus certificados. No sabes cuántos tienes hasta que los buscas. Cada dominio, cada servidor, cada cluster de Kubernetes.

# En cada servidor con certbot
sudo certbot certificates
# Salida: Certificate Name: tudominio.com
#         Domains: tudominio.com *.tudominio.com
#         Expiry Date: 2026-11-26 12:00:00+00:00 (VALID: 89 days)
#         Certificate Path: /etc/letsencrypt/live/tudominio.com/fullchain.pem

El campo VALID: NN days es el que importa: si ves un número cercano a 60 en un certificado que debería tener 90, o un número que no cuadra con la fecha de emisión, algo está mal en tu inventario.

3. Elimina los días hardcodeados. Busca en todos tus scripts, crons y runbooks.

# Buscar numeros sospechosos de dias de renovacion
grep -rnE "days[ =]+(30|45|60|80|83|90)|--days" /etc/cron.d/ /etc/crontab ~/scripts/ ~/runbooks/ 2>/dev/null
# Buscar el patron clasico de calculo sobre fecha de expiracion
grep -rnE "enddate|Not After|expiry" ~/scripts/ /etc/cron.d/ 2>/dev/null

Los números que te dice el anuncio oficial —83, 80 y 60— son los más comunes. El 83 viene de la convención de “renovar cuando quede un tercio” sobre 90 días con margen, el 80 de un margen plano, y el 60 del tercio exacto.

4. Prueba en staging. El staging de Let’s Encrypt ya usa 64 días desde el 14 de octubre de 2026, así que tu --dry-run prueba el comportamiento real:

sudo certbot renew --dry-run
# Si tu cliente soporta ARI, el dry run tambien lo ejercita

5. Verifica que el hook recarga tu servidor web y que el certificado servido coincide con el de disco (el test de las dos fechas del punto 5).

6. Instala el monitoreo por porcentaje (el script de la sección anterior) y conéctalo a tu sistema de alertas.

7. Opcional: adopta el perfil tlsserver si tu automatización es totalmente desatendida. Ganas 45 días de vida en lugar de 64, sin Common Name, sin CRL, y con el comportamiento de re-validación que tendrá el perfil classic en 2028.

8. Repite el inventario cada seis meses hasta 2028. Los certificados emitidos por herramientas que no controlas —un panel de control, un instalador automático, un appliance— reaparecen sin avisar.

---

Conclusión

El 10 de febrero de 2027 tus certificados de Let’s Encrypt van a durar 64 días, y el 16 de febrero de 2028, 45. La razón es buena: reducir la ventana de compromiso de una clave privada filtrada. El riesgo es que las automatizaciones que nadie revisó se quedan con un margen que ya no existe.

La buena noticia es que el problema tiene una solución limpia, y esa solución es ARI: la CA le dice al cliente cuándo renovar y el cliente obedece. Si actualizas tu cliente ACME, dejas de calcular fechas y el resto de la transición se resuelve solo.

La mala noticia es que ARI solo cubre la renovación. Todo lo demás —el hook que recarga el servidor web, el monitoreo que te avisa, la documentación que dice la verdad— sigue siendo tuyo. Y con 45 días de vida, el margen para descubrir que algo no está funcionando se reduce a semanas.

Así que la tarea concreta, si te llevas una sola cosa de este post: busca el número 60 en tus scripts de renovación y quítalo. Esa es la línea que más veces va a romper en 2027, y quitarla toma dos minutos.

---

Preguntas frecuentes

---

Lee también

• Let’s Encrypt con certbot: HTTPS gratis para tus servicios 2026 — la guía base de emisión y renovación que hay que migrar.
• Certificado wildcard con DNS-01: un solo certificado para todas tus apps — el caso donde los certificados se renuevan más y el rate limit importa más.
• Hardening TLS en Nginx y Apache: guía 2026 — configurar bien lo que queda después de la renovación.
• Exponer servicios de tu home lab a internet: 6 vías explicadas — el contexto de por qué hay tantos certificados que renovar.