Certificados de 45 días de Let’s Encrypt: cómo elegir el perfil ACME en Caddy, Traefik, certbot, acme.sh y lego

Desde el 13 de mayo de 2026, el perfil tlsserver de Let’s Encrypt emite certificados de 45 días, y el perfil classic, el que usas si no eliges ninguno, pasará de 90 a 64 días el 10 de febrero de 2027 y a 45 días el 16 de febrero de 2028. Elegir el perfil es una línea de configuración en tu cliente ACME (Automatic Certificate Management Environment). Probé esa línea en certbot, Caddy, Traefik, acme.sh y lego contra Pebble, el servidor ACME de pruebas de Let’s Encrypt, y te cuento qué certificado salió con cada uno y qué renovación necesita cada cliente. También tienes la versión en inglés.

Puntos clave

• Let’s Encrypt publicó el calendario el 2 de diciembre de 2025: tlsserver a 45 días el 13 de mayo de 2026, classic a 64 días el 10 de febrero de 2027 y a 45 días el 16 de febrero de 2028.
• Hay tres perfiles en el directorio ACME de producción (lo comprobé el 7 de octubre de 2026): classic, tlsserver y shortlived, este último de 160 horas. El perfil tlsclient dejó de estar disponible el 8 de julio de 2026.
• Los cinco clientes que probé pidieron tlsserver y recibieron un certificado de 45 días exactos, del 7 de octubre al 21 de noviembre de 2026.
• Traefik renueva por defecto 30 días antes de caducar, una regla pensada para 90 días. Con shortlived renovó el certificado en cada reinicio hasta que ajusté certificatesDuration.
• Si tu cliente no usa ARI (ACME Renewal Information), renueva hacia los dos tercios de la vida del certificado, no a un intervalo fijo de 60 días.

Qué cambia y cuándo: el calendario de Let’s Encrypt

Let’s Encrypt acorta la vida de sus certificados por etapas, y las etapas se controlan con perfiles ACME. Las fechas salen de la entrada oficial del 2 de diciembre de 2025^[1], que comprobé de nuevo el 7 de octubre de 2026:

La reutilización de autorización es el tiempo durante el que Let’s Encrypt acepta que ya demostraste el control de un dominio sin volver a validarlo. Hoy son 30 días y bajarán a 7 horas en 2028, así que cada renovación tendrá que superar un reto nuevo. La entrada lo resume así: "This profile is opt-in and can be used by early adopters and for testing."

La consecuencia práctica es que el 10 de febrero de 2027 afecta a todos los que no hayan elegido perfil. Si tu automatización funciona con 64 días, no hace falta tocar nada; si renueva con un intervalo fijo, deja de funcionar antes de lo que crees.

Qué perfiles ofrece Let’s Encrypt hoy

Los perfiles que ves en producción son tres. Puedes comprobarlo tú mismo leyendo el directorio ACME:

curl -s https://acme-v02.api.letsencrypt.org/directory \
  | jq .meta.profiles

El 7 de octubre de 2026 devolvió classic, shortlived y tlsserver, cada uno con un enlace a su sección de la página de perfiles^[2]. Las diferencias que importan:

• classic: el perfil de siempre, hoy a 90 días, con nombre común (Common Name) en el certificado y hasta 100 nombres.
• tlsserver: sigue las recomendaciones actuales del CA/Browser Forum, omite el nombre común y admite hasta 25 nombres. Let’s Encrypt lo recomienda "for subscribers who want smaller certificates and who fully embrace automation".
• shortlived: igual que tlsserver, pero con 160 horas de validez. Es el único perfil que emite certificados para direcciones IP, según el anuncio de disponibilidad general^[3] del 15 de enero de 2026.

El límite de 25 nombres es lo único que puede romper una migración a tlsserver: si emites certificados con más de 25 nombres alternativos, divídelos antes de cambiar.

Cómo probé los perfiles sin gastar el límite de Let’s Encrypt

Para no pedir certificados a producción desde un laboratorio, usé Pebble^[4] 2.10.1, el servidor ACME de pruebas que mantiene el propio Let’s Encrypt. Pebble sabe anunciar perfiles, pero no los impone: los nombres y las validez los fijo yo en su fichero de configuración, y los copié del calendario anterior. Lo que prueba mi laboratorio es que cada cliente envía el perfil y respeta el certificado que recibe, no lo que Let’s Encrypt emite en producción.

El fichero pebble-config.json declara los tres perfiles (en segundos: 90 días, 45 días y 160 horas):

{
  "pebble": {
    "listenAddress": "0.0.0.0:14000",
    "managementListenAddress": "0.0.0.0:15000",
    "certificate": "/cfg/certs/localhost/cert.pem",
    "privateKey": "/cfg/certs/localhost/key.pem",
    "httpPort": 80,
    "tlsPort": 443,
    "keyAlgorithm": "ecdsa",
    "profiles": {
      "classic":    { "description": "90 days",   "validityPeriod": 7776000 },
      "tlsserver":  { "description": "45 days",   "validityPeriod": 3888000 },
      "shortlived": { "description": "160 hours", "validityPeriod": 576000 }
    }
  }
}

Lo levanté con Docker Compose, con PEBBLE_VA_ALWAYS_VALID=1 para que acepte cualquier reto sin tener DNS público (el reto no se prueba en este laboratorio):

services:
  pebble:
    image: ghcr.io/letsencrypt/pebble:latest
    command: ["-config", "/cfg/pebble-config.json"]
    environment:
      PEBBLE_VA_NOSLEEP: "1"
      PEBBLE_VA_ALWAYS_VALID: "1"
    volumes:
      - ./cfg:/cfg:ro

El certificado del propio Pebble (cfg/certs/localhost/cert.pem) sale del repositorio de Pebble y cada cliente tiene que confiar en él. El directorio ACME de Pebble anuncia los perfiles en meta.profiles, igual que el de Let’s Encrypt. Los certificados salen con los nombres certbot.test, caddy.test y similares.

Cómo elegir el perfil en cada cliente ACME

Cada cliente tiene su propia opción y su propio detalle. Todos los certificados que siguen vienen de ejecuciones reales del 7 de octubre de 2026.

certbot 5.8.0

certbot tiene dos opciones: --preferred-profile (pide el perfil y, si el servidor no lo conoce, emite con el de por defecto) y --required-profile (falla si no existe).

certbot certonly --standalone -d certbot.test \
  --server https://pebble:14000/dir \
  --preferred-profile tlsserver

El certificado salió con notBefore=Oct 7 08:48:03 2026 y notAfter=Nov 21 08:48:02 2026, 45 días. Con un perfil que no existe, los dos modos se comportan distinto: --required-profile nosuch abortó con Order includes unrecognized profile name "nosuch", y --preferred-profile nosuch emitió el certificado de 89 días del perfil por defecto de Pebble. El valor se guarda en el fichero de renovación como preferred_profile = tlsserver, así que certbot renew lo reutiliza. Elige --preferred-profile en producción: si Let’s Encrypt retira un perfil, la renovación sigue funcionando.

Caddy 2.11.4

En Caddy el perfil es una opción del emisor acme, y la documentación lo marca como experimental^[5] mientras el borrador del estándar no sea definitivo. Si lo declaras, todas las CA que uses tienen que admitirlo.

caddy.test {
    tls {
        issuer acme {
            dir https://pebble:14000/dir
            trusted_roots /pebble.pem
            profile tlsserver
        }
    }
    respond "ok"
}

En producción quitas dir y trusted_roots y te queda solo profile tlsserver. Caddy emite por defecto con Let’s Encrypt y con ZeroSSL, así que si usas ambas, comprueba que las dos admiten el perfil. El certificado salió del 7 de octubre al 21 de noviembre, 45 días.

El log de Caddy mostró que pidió la información de renovación: "window_start":1793868520,"window_end":1794041320, es decir, del 5 al 7 de noviembre de 2026. Caddy renueva dentro de esa ventana sin que configures nada.

Traefik 3.7.13

En Traefik el perfil es la opción profile del certResolver:

certificatesResolvers:
  le:
    acme:
      email: tu@correo.example
      storage: /acme/acme.json
      profile: tlsserver
      certificatesDuration: 1080
      httpChallenge:
        entryPoint: web

Con profile: tlsserver el certificado salió con 45 días. La línea certificatesDuration: 1080 (en horas, 45 días) importa más de lo que parece. La documentación de Traefik^[6] dice que "By default, Traefik manages 90-day certificates and starts renewing them 30 days before their expiry".

Con el valor por defecto, el log decía Attempt to renew certificates "720h0m0s" before expiry. Con 1080 pasó a "240h0m0s", que es lo que calcula el código de Traefik para certificados de entre 30 y 90 días: renovar 10 días antes y comprobar cada 12 horas.

Con profile: shortlived y sin ajustar el valor, Traefik emitió un certificado de 160 horas. Al reiniciar lo renovó otra vez de inmediato (el log mostró hoursRemaining=143), porque 30 días antes de caducar es siempre ahora para un certificado de 6 días. Si usas shortlived en Traefik, pon certificatesDuration: 160.

acme.sh 3.1.6

acme.sh llama a la opción --cert-profile (o --certificate-profile):

acme.sh --issue --standalone -d acmesh.test \
  --server https://pebble:14000/dir \
  --cert-profile tlsserver

El certificado salió del 7 de octubre al 21 de noviembre de 2026. acme.sh --list añade una columna Profile con tlsserver. La columna Renew marcaba 2026-11-06T17:36:57Z, un momento dentro de la ventana que anunció la ARI de Pebble (del 5 al 7 de noviembre). El perfil se guarda en la configuración del dominio y se reutiliza en las renovaciones.

lego 5.5.2

lego usa --profile, y el mismo comando run sirve para pedir y para renovar:

lego --path /data --server https://pebble:14000/dir \
  --accept-tos --email tu@correo.example \
  --domains lego.test --http run --profile tlsserver

Con tlsserver salió un certificado de 45 días. Con --profile shortlived salió uno del 7 de octubre a las 08:51:28 al 14 de octubre a las 00:51:27, 160 horas. Al repetir el comando, lego respondió Skip renewal: ... the renewal can be performed in 3d7h59m58s, que es la mitad de la vida del certificado. La ayuda de lego describe la regla: "1/3rd of the lifetime left, or 1/2 of the lifetime for short-lived certificates", salvo que fijes --renew-days.

Cómo comprobar el perfil y el momento de renovación

Un certificado no dice con qué perfil se emitió. Lo que sí puedes comprobar es su validez y cuándo lo renovará tu cliente:

openssl x509 -in cert.pem -noout -dates
certbot certificates
acme.sh --list

openssl x509 -noout -dates da las dos fechas y, restando, los días. certbot certificates muestra los días que quedan (con el perfil por defecto de Pebble salió VALID: 89 days, con tlsserver salió VALID: 44 days un minuto después de emitir). Para el momento exacto de renovación, la señal fiable es la ARI, que cada cliente consulta por su cuenta. Caddy la registra en su log y acme.sh la escribe en la salida de --issue.

La entrada de Let’s Encrypt avisa de qué no sirve: "For example, renewing at a hardcoded interval of 60 days will no longer be sufficient." Si programas la renovación a mano con cron, ejecútala a diario y deja que el cliente decida si toca.

Qué perfil elegir ahora

Elige tlsserver en los servicios cuya renovación ya está automatizada y vigilada. Desde el 16 de febrero de 2028 todos tendrán esa vida de 45 días, y hoy te deja descubrir fallos con margen. Mantén classic donde dependes de herramientas que esperan el nombre común o más de 25 nombres. Reserva shortlived para casos con un motivo, como un certificado para una dirección IP, y comprueba antes que la renovación (y el reinicio del servidor que carga el certificado) funciona sin intervención.

Si gestionas los certificados con Nginx Proxy Manager, revisa antes qué cliente ACME lleva y si admite perfiles; tienes la guía de instalación de Nginx Proxy Manager. Para un servicio con Caddy delante, Forgejo con Caddy es un ejemplo completo, y si usas Traefik tienes la instalación de Traefik con Docker Compose.

Preguntas frecuentes

¿Tengo que hacer algo antes del 10 de febrero de 2027?

Solo si tu renovación depende de un intervalo fijo, como un cron mensual. Con un cliente que renueva solo no tienes que cambiar nada, pero conviene probar antes con tlsserver: si algo falla con 45 días, fallará también con 64.

¿Los certificados de 45 días ya valen para producción?

Sí. El perfil tlsserver emite certificados reales desde el 13 de mayo de 2026 y está en el directorio de producción. Es un perfil opt-in, así que ningún certificado cambia hasta que lo pidas.

¿Qué hago si mi cliente no admite perfiles?

Espera a actualizarlo, porque sin perfil pedirás siempre el de por defecto. Mientras tanto, classic seguirá funcionando: pasará a 64 días en febrero de 2027 y no necesitas cambiar nada si renuevas a diario.

Conclusión

El cambio a 45 días es una decisión de configuración: una línea por cliente, con una opción distinta en cada uno (--preferred-profile, profile, --cert-profile, --profile). Mi prueba contra Pebble confirma que los cinco clientes la envían y que el certificado resultante dura 45 días, pero también que la renovación de Traefik hay que ajustarla a mano.

Prueba tlsserver en un servicio secundario esta semana. Cuando llegue el 10 de febrero de 2027 ya sabrás qué falla.

Fuentes: [1] Decreasing Certificate Lifetimes to 45 Days (Let’s Encrypt)^[1], [2] Perfiles de Let’s Encrypt^[2], [3] Let’s Encrypt: 6-day and IP address certificates now available^[3], [4] Pebble en GitHub^[4], [5] Documentación de los certResolvers ACME de Traefik^[6], [6] Directiva tls de Caddy^[5], [7] Six-Day and IP Address Certificates Available in Certbot^[7], [8] acme.sh en GitHub^[8].

Fuentes

1. entrada oficial del 2 de diciembre de 2025
2. página de perfiles
3. anuncio de disponibilidad general
4. Pebble
5. la documentación lo marca como experimental
6. documentación de Traefik
7. Six-Day and IP Address Certificates Available in Certbot
8. acme.sh en GitHub