Certificados TLS de 47 días: calendario y qué automatizar

Respuesta breve. La votación SC-081 del CA/Browser Forum, aprobada el 11 de abril de 2025, reduce en tres pasos la validez máxima de los certificados TLS de confianza pública. Los certificados emitidos a partir del 15 de marzo de 2026 pueden durar hasta 200 días; a partir del 15 de marzo de 2027, hasta 100 días, y a partir del 15 de marzo de 2029, hasta 47 días. El tiempo durante el que una CA puede reutilizar una validación de dominio se reduce en las mismas fechas: 200 días, luego 100 y luego 10. En la práctica, todos los certificados tienen que emitirse y desplegarse de forma automatizada (ACME). La renovación debería seguir la ventana ARI de la CA, y necesitas una monitorización que te avise mientras aún haya tiempo para arreglar una renovación que falla. Las CA privadas no se ven afectadas.

El calendario

Las reglas están en las secciones 6.3.2 y 4.2.1 de los Baseline Requirements (versión 2.3.1, octubre de 2026). La votación SC-081v3 la propuso Apple y la respaldaron Sectigo, Google Chrome y Mozilla. Se aprobó con 25 votos de CA a favor, ninguno en contra y 5 abstenciones, y los cuatro fabricantes de navegadores votaron a favor.

Algunos detalles que importan cuando planificas en función de estas cifras:

• Los límites son máximos que las CA aplican en el momento de la emisión. Un certificado emitido el 14 de marzo de 2026 todavía podía tener una validez de 398 días. Nada te obliga a sustituirlo antes de que caduque, pero su sustituto tendrá una vida útil corta.
• La «validez» cuenta ambos extremos. Los BR la definen como el período desde notBefore hasta notAfter, ambos incluidos, y recomiendan un día de margen: los certificados no deberían («SHOULD NOT») superar 199, 99 y 46 días.
• El límite de reutilización de la validación es el cambio más importante. Hoy una CA puede reutilizar durante meses la prueba de que controlas example.com. Desde 2029, la prueba debe tener como máximo 10 días de antigüedad, así que casi cada emisión necesita una validación de dominio nueva, y el desafío DNS o HTTP también tiene que estar automatizado.
• Los datos de la organización de los certificados OV y EV (nombre de la empresa, dirección) pueden reutilizarse durante 398 días en lugar de 825.
• Ámbito de aplicación. Los BR regulan los certificados de servidor TLS de las CA de confianza pública. Los certificados de tu propia CA interna, los certificados de cliente y los certificados S/MIME se rigen por otras reglas o por ninguna.

Qué emiten hoy las CA

El 20 de octubre de 2026, los certificados que servían algunos sitios grandes tenían este aspecto. La salida procede del script lifetimes.sh de la sección de monitorización:

letsencrypt.org        Let's Encrypt              2026-09-04  ->  2026-12-03  (90 days)
www.google.com         Google Trust Services      2026-09-28  ->  2026-12-21  (84 days)
github.com             Sectigo Limited            2026-09-01  ->  2026-11-29  (90 days)
www.microsoft.com      Microsoft Corporation      2026-01-22  ->  2027-01-17  (360 days)
www.amazon.com         Amazon                     2026-01-19  ->  2027-01-11  (358 days)
www.digicert.com       DigiCert Inc               2026-10-11  ->  2026-11-26  (47 days)

Dos de ellos todavía tienen certificados de casi un año, emitidos en enero de 2026, justo antes de que entrara en vigor el límite de 200 días. DigiCert ya sirve un certificado de 47 días en su propio sitio. El plan publicado de Let's Encrypt avanza más rápido de lo que exigen los BR:

• 13 de mayo de 2026: el perfil opcional tlsserver emite certificados de 45 días.
• 10 de febrero de 2027: el perfil predeterminado classic emite certificados de 64 días con un período de reutilización de autorizaciones de 10 días.
• 16 de febrero de 2028: classic emite certificados de 45 días con un período de reutilización de autorizaciones de 7 horas.

El directorio ACME en producción enumera los perfiles que puedes solicitar hoy:

"meta": {
  "profiles": {
    "classic": "https://letsencrypt.org/docs/profiles#classic",
    "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
    "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
  }
},
"renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"

Qué automatizar

Con certificados de 398 días, una renovación manual al año era molesta pero llevadera. Con certificados de 47 días y 10 días de reutilización de la validación, la renovación manual es una tarea propensa a errores al menos ocho veces al año por cada nombre, y más cerca de doce si renuevas a los dos tercios de la vida útil. El trabajo se divide en cuatro partes.

1. Emisión mediante ACME. Usa un cliente ACME (RFC 8555) para cada certificado de una CA pública. La mayoría de las CA comerciales también ofrecen endpoints ACME, a menudo con vinculación de cuenta externa (External Account Binding). Si un certificado todavía te llega por correo electrónico, como descarga desde un portal o mediante un ticket, ponlo el primero de la lista.

2. Validación desatendida. Elige un desafío que funcione sin intervención humana:

• http-01 necesita el puerto 80 accesible en cada host que sirve el nombre.
• dns-01 necesita acceso a la API de tu proveedor de DNS. Limita el token a los registros _acme-challenge si el proveedor lo permite.
• tls-alpn-01 funciona íntegramente en el puerto 443.

Dos métodos más recientes se redactaron precisamente para esta situación. «DNS Labeled with Account ID», el desafío ACME dns-account-01 del §3.2.2.4.21 de los BR, permite que varias cuentas ACME validen el mismo nombre sin disputarse un único registro _acme-challenge. «DNS TXT Record with Persistent Value» (§3.2.2.4.22, votación SC-088) te permite publicar una sola vez un registro permanente:

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

La CA puede dar por buena cada comprobación de ese registro durante 10 días como máximo. Pero es la propia CA la que vuelve a comprobar el registro, así que nadie tiene que tocar el DNS en cada renovación. Pregunta a tu CA si admite este método antes de depender de él.

3. Renovación guiada por la CA. Renueva pronto y deja que la CA marque los tiempos:

• Renueva hacia los dos tercios de la vida útil. Es decir, el día 30 de un certificado de 45 días. Let's Encrypt afirma que «renovar con un intervalo fijo de 60 días ya no será suficiente». Desde la versión 4.0, certbot renueva cuando queda un tercio de la vida útil, en lugar de cuando quedan 30 días fijos.
• Usa ARI (RFC 9773), que se explica en la siguiente sección. La CA indica a cada cliente cuándo renovar y puede adelantar esa ventana cuando tiene que revocar certificados de forma masiva.
• Solicita el perfil explícitamente si quieres certificados de 45 días antes de que cambie el valor predeterminado de tu CA.

4. Despliegue en cada copia. Renovar el archivo en el disco no es el final. Haz una lista de todos los lugares a los que se copia un certificado:

• balanceadores de carga y CDN en los que se cargan certificados,
• secretos de Kubernetes,
• almacenes de claves de Java y paquetes PKCS#12,
• equipos dedicados (appliances), servidores de correo, bases de datos y brokers de mensajes,
• aplicaciones móviles que fijan un certificado hoja.

Cada copia necesita un hook de recarga o una integración que obtenga el certificado nuevo. La fijación de un certificado hoja o de su clave en una aplicación se vuelve inviable a este ritmo. Fija en su lugar una clave de CA o, mejor aún, no fijes nada.

Esta prueba ejecuta certbot 5.8.0 contra un servidor ACME Pebble 2.10.1 local cuyo perfil tlsserver emite certificados de 45 días. Muestra que la solicitud del perfil y la configuración de renovación funcionan tal como se documenta:

$ certbot certonly --standalone --non-interactive --agree-tos --register-unsafely-without-email \
    --server https://localhost:14000/dir -d app.example.test --preferred-profile tlsserver
Account registered.
Requesting a certificate for app.example.test
Successfully received certificate.
This certificate expires on 2026-12-04.
$ openssl x509 -in /etc/letsencrypt/live/app.example.test/cert.pem -noout -startdate -enddate
notBefore=Oct 20 11:47:52 2026 GMT
notAfter=Dec  4 11:47:51 2026 GMT
$ grep -E "preferred_profile|server" /etc/letsencrypt/renewal/app.example.test.conf
preferred_profile = tlsserver
server = https://localhost:14000/dir
$ certbot renew --non-interactive
Processing /etc/letsencrypt/renewal/app.example.test.conf
Certificate not yet due for renewal

certbot guarda el perfil en la configuración de renovación, así que cada renovación posterior lo vuelve a solicitar. La opción --preferred-profile existe desde certbot 4.0. Si el directorio de la CA no incluye el perfil indicado, se usa el perfil predeterminado de la CA. --required-profile, en cambio, hace que la emisión o la renovación fallen. Los perfiles proceden de draft-ietf-acme-profiles, que en octubre de 2026 estaba pendiente de revisión por el IESG. Los clientes distintos de certbot tienen sus propios nombres de opción.

Información de renovación de ACME (ARI)

ARI (RFC 9773, junio de 2025) convierte el momento de la renovación, que era una estimación del lado del cliente, en una pregunta a la CA. Para cada certificado, el cliente construye un identificador a partir del Authority Key Identifier (identificador de clave de la autoridad) y del número de serie del certificado:

url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)

Después consulta periódicamente esa URL sin autenticación. La respuesta contiene un suggestedWindow, y un encabezado Retry-After indica cuándo volver a preguntar. Puedes hacer la consulta por tu cuenta para cualquier certificado de Let's Encrypt:

#!/bin/bash
set -e
host="$1"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out cert.pem
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | grep -o -E '([0-9A-F]{2}:){19}[0-9A-F]{2}' | tr -d ':')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
# The DER INTEGER content keeps a leading 00 byte when the high bit is set.
[ $(( 16#${serial:0:1} )) -ge 8 ] && serial="00$serial"
b64url() { python3 -c 'import sys,base64; print(base64.urlsafe_b64encode(bytes.fromhex(sys.stdin.read().strip())).decode().rstrip("="))'; }
id="$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"
ari=$(curl -s https://acme-v02.api.letsencrypt.org/directory | grep -o '"renewalInfo": *"[^"]*"' | cut -d'"' -f4)
openssl x509 -in cert.pem -noout -issuer -startdate -enddate
echo "GET $ari/$id"
curl -s -D - "$ari/$id" | grep -i -E '^retry-after|^\{|"'

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
retry-after: 25769
{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"

La ventana se abre el día 59 de este certificado de 90 días, hacia los dos tercios de su vida útil. El cliente debería elegir un momento aleatorio dentro de la ventana, lo que reparte las renovaciones en el tiempo. Si la CA tiene que revocar certificados de forma masiva, mueve la ventana al pasado, y los clientes que se comportan correctamente renuevan en cuestión de horas en lugar de fallar cuando el certificado caduca. Al renovar, el cliente envía el identificador del certificado anterior en el campo replaces de su nuevo pedido.

Compatibilidad con ARI en los clientes habituales, según sus notas de la versión:

Monitorización que detecta una renovación fallida

La automatización falla en silencio: un token caducado de la API de DNS, un cambio en el cortafuegos que bloquea el puerto 80, un hook de recarga que ya no funciona. Con un certificado de 47 días renovado el día 30, tienes unos 17 días entre la primera renovación fallida y una caída del servicio. Lanza la alerta al principio de ese margen.

Desde fuera. Sondea cada nombre público, no solo los que recuerdas. El blackbox exporter de Prometheus expone la caducidad de la cadena servida como probe_ssl_earliest_cert_expiry:

probe_ssl_earliest_cert_expiry 1.795737599e+09
probe_success 1
probe_tls_version_info{version="TLS 1.3"} 1

Estas dos reglas de alerta superan promtool check rules (Prometheus 3.5.0). La primera salta cuando la renovación lleva retraso; la segunda, cuando la caída del servicio está cerca:

groups:
  - name: certificates
    rules:
      - alert: CertificateRenewalOverdue
        # Fires when less than a third of a 47-day lifetime (about 16 days) is left:
        # the renewal job should have replaced the certificate by now.
        expr: probe_ssl_earliest_cert_expiry - time() < 16 * 86400
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"
      - alert: CertificateExpiresSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 86400
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"

Desde un script. openssl x509 -checkend N termina con el código de salida 1 si el certificado caduca en los próximos N segundos, lo que basta para una tarea cron o un paso de CI:

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Nov 26 23:59:59 2026 GMT
$ openssl x509 -in cert.pem -noout -checkend $((30 * 86400)); echo "exit status: $?"
Certificate will not expire
exit status: 0
$ openssl x509 -in cert.pem -noout -checkend $((45 * 86400)); echo "exit status: $?"
Certificate will expire
exit status: 1

La tabla con el sondeo del principio de esta página se generó con este script:

#!/bin/bash
for host in "$@"; do
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out /tmp/c.pem 2>/dev/null || { echo "$host: no certificate"; continue; }
  nb=$(openssl x509 -in /tmp/c.pem -noout -startdate | cut -d= -f2)
  na=$(openssl x509 -in /tmp/c.pem -noout -enddate | cut -d= -f2)
  issuer=$(openssl x509 -in /tmp/c.pem -noout -issuer -nameopt multiline | grep -E "organizationName" | head -1 | cut -d= -f2 | sed 's/^ *//')
  days=$(( ($(date -d "$na" +%s) - $(date -d "$nb" +%s) + 1) / 86400 ))
  printf '%-22s %-26s %s  ->  %s  (%s days)\n' "$host" "$issuer" "$(date -u -d "$nb" +%F)" "$(date -u -d "$na" +%F)" "$days"
done

Desde el lado de la CA. Los logs de Certificate Transparency registran cada certificado emitido para tus dominios. Un monitor de CT muestra las renovaciones realizadas y los certificados que no esperabas. Consulta Certificate Transparency para desarrolladores o busca el historial de un dominio con la herramienta de historial de CT. Para ver lo preparado que está un conjunto de dominios, la calculadora de certificados de 47 días aplica el calendario a cada uno de tus certificados.

CAA y vinculación a la cuenta

Una reutilización de la validación más corta implica más validaciones, y en cada una se comprueban tus registros CAA. Desde el 15 de marzo de 2027 (votación SC-098), las CA también deben respetar los parámetros accounturi y validationmethods del RFC 8657. Eso te permite limitar la emisión a tu propia cuenta ACME y al tipo de desafío que elijas:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

El generador de registros CAA crea estos registros. Ten en cuenta que un registro CAA obsoleto bloqueará tus propias renovaciones, que ahora se producen al menos ocho veces al año en lugar de una.

Errores frecuentes

• Un intervalo de renovación fijo. «Renovar cada 60 días» ya no sirve con certificados de 45 días. Renueva a una fracción de la vida útil o según ARI.
• Renovar sin recargar. El archivo nuevo está en el disco, pero el servidor sigue sirviendo desde la memoria el certificado antiguo hasta que caduca. Prueba el hook de despliegue, no solo la renovación.
• Olvidar las copias. El origen renueva su certificado automáticamente, pero la CDN o el balanceador de carga siguen teniendo un certificado cargado a mano.
• Alertar con 7 días de antelación. Con certificados de 47 días, una alerta una semana antes de la caducidad no deja tiempo para depurar un problema de la API de DNS o del cortafuegos. Lanza la alerta cuando la renovación lleve retraso.
• Fijar las claves de los certificados hoja en aplicaciones móviles o clientes de API. Cada renovación con una clave nueva los rompe.
• Dar por hecho que la PKI privada debe seguir el mismo camino. Tu CA interna puede mantener su propia política. Las vidas útiles cortas siguen siendo una buena idea ahí, pero la decisión es tuya.

Fuentes

• CA/Browser Forum, Baseline Requirements v2.3.1: §1.2.2 (fechas relevantes), §3.2.2.4.21–22 (nuevos métodos DNS), §4.2.1 (períodos de reutilización), §6.3.2 (validez).
• Votación SC-081v3 (aprobada el 11 de abril de 2025, en vigor desde el 16 de mayo de 2025).
• RFC 9773: ACME Renewal Information (información de renovación de ACME). RFC 8555: ACME. draft-ietf-acme-profiles.
• Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days y perfiles.
• Notas de la versión de certbot, Caddy, lego, acme.sh y cert-manager.
• RFC 8659 (CAA) y RFC 8657 (accounturi y validationmethods de CAA).

La salida de los comandos se generó el 20 de octubre de 2026 en node:24.22.0-trixie (OpenSSL 3.5.7, curl 8.14.1), certbot/certbot:v5.8.0 con ghcr.io/letsencrypt/pebble:2.10.1, quay.io/prometheus/blackbox-exporter:v0.25.0 y prom/prometheus:v3.5.0.