200, 100, 47: el calendario que va a romper tu renovación manual de certificados

El 31 de agosto de 2026, poco después de las siete de la tarde en España, Exchange Online dejó de funcionar. Con él cayeron Outlook, OWA, ActiveSync, Teams, SharePoint y Defender XDR. Microsoft abrió la incidencia EX1464935 y durante horas habló de «un problema con un componente de autenticación». Los administradores que miraron los logs, según recogió el blog de Günter Born, encontraron una línea mucho más prosaica (el thumbprint es la huella que identifica a un certificado concreto, como el número de serie de un billete):

The cert with thumbprint 19F04B8A233DD9CE916F118056D224A1751729EA is expired

Un certificado caducado. En Microsoft. En 2026.

No lo cuento para reírme de nadie: si le pasa a una empresa con esos recursos, le puede pasar a cualquiera, y todos tenemos alguna historia parecida con un certificado que «renovaba otro departamento». Lo cuento porque justo esta semana empieza algo que va a multiplicar las ocasiones de que nos pase. Los certificados TLS públicos (los que permiten el candado del navegador y el https, y que demuestran que un servidor es quien dice ser) que se emitieron a partir del 15 de marzo de 2026 ya no podían durar más de 200 días. Si haces la cuenta, los primeros caducan en torno al 1 de octubre. Lo que antes era una tarea anual pasa a ser semestral. En marzo de 2027 será cada 100 días. En marzo de 2029, cada 47.

Qué se votó y por qué

El cambio viene del CA/Browser Forum, el organismo en el que las autoridades de certificación (las empresas u organizaciones que emiten certificados y responden de ellos, como un notario responde de una firma) y los fabricantes de navegadores pactan las reglas que deben cumplir los certificados en los que confían los navegadores. La propuesta la presentó Apple, Google la apoyó casi de inmediato y la votación se cerró el 11 de abril de 2025. El calendario queda así:

La segunda columna es la que menos se comenta y la que más trabajo va a dar; vuelvo a ella enseguida.

Los motivos que da la propuesta son dos. El primero es que la revocación no funciona bien. En teoría, si te roban la clave privada de un certificado, la autoridad de certificación lo revoca y los navegadores dejan de aceptarlo. En la práctica, los mecanismos de revocación han sido históricamente poco fiables. Las listas CRL funcionan como aquellas listas de tarjetas robadas que tenían antes las tiendas: hay que descargarlas y mantenerlas al día. Las consultas OCSP son como llamar al banco en cada compra para preguntar si la tarjeta sigue siendo buena: más al día, pero si el banco no contesta, muchos navegadores deciden aceptar la tarjeta igualmente. Así que un certificado revocado puede seguir funcionando para muchos clientes. Si el certificado caduca pronto, el daño de uno comprometido queda acotado por su propia fecha. El segundo motivo es que la información que contiene un certificado (a quién pertenece un dominio, qué organización está detrás) se va quedando vieja, y la única forma de que siga siendo cierta es volver a comprobarla a menudo.

Hay un tercer efecto, que no está en la propuesta con esas palabras pero que todo el mundo entiende: con vidas de 47 días, renovar a mano deja de ser una opción realista. Es una forma de obligar a toda la industria a automatizar.

De la ITV a comprar el pan

La mejor manera que he encontrado de explicar el cambio de mentalidad es comparar dos tareas domésticas.

Un certificado de un año es como la ITV del coche. Pasa una vez al año, te llega un aviso, lo apuntas en el calendario y lo haces. Si un año se te olvida, te das cuenta tarde y pasas un mal rato, pero el sistema «calendario más memoria» funciona razonablemente bien para algo anual.

Un certificado de 47 días es comprar el pan. Nadie apunta en el calendario cuándo comprar el pan: o es una rutina automática o no hay pan. Y si en tu casa comprar el pan dependiera de que alguien se acordara cada vez, habría días sin pan con toda seguridad.

El paso intermedio, 200 y 100 días, es el más traicionero. Es demasiado frecuente para gestionarlo cómodamente con el calendario (dos o cuatro renovaciones al año por certificado, multiplicadas por todos los que tengas), pero aún lo bastante espaciado como para que la tentación sea «ya lo automatizaremos».

Figura: si renuevas cuando el certificado ha consumido dos tercios de su vida (la recomendación habitual), pasas de algo más de una renovación al año por certificado a casi doce.

La columna que nadie mira: validar el dominio

Cuando pides un certificado, la autoridad tiene que comprobar que controlas el dominio. Es lo que se llama validación de control de dominio (DCV): publicas un registro DNS concreto, o sirves un fichero en una ruta de tu web, y la autoridad lo comprueba. Son los llamados retos (challenges) DNS-01 y HTTP-01: la autoridad te pide que pongas una contraseña de un solo uso en un sitio que solo el dueño del dominio puede tocar. Hasta ahora, esa comprobación se podía reutilizar durante 398 días: validabas una vez y renovabas varias veces sin repetirla.

Con el calendario nuevo, la reutilización baja hasta 10 días en 2029. En la práctica, cada renovación va a necesitar una validación nueva. Es como si en la ventanilla del banco, en vez de reconocerte durante un año tras enseñar el DNI, te lo pidieran cada vez que vas.

Esto importa sobre todo a quien valida por DNS, que es lo necesario para certificados comodín (*.midominio.es, válidos para cualquier subdominio) y para servidores que no son accesibles desde internet.

Aquí entra ACME (Automatic Certificate Management Environment), el protocolo que creó Let’s Encrypt para que un programa, el cliente ACME (certbot, lego, acme.sh…), pida, valide y renueve certificados sin intervención humana. Validar por DNS de forma automática implica que ese cliente tenga credenciales para modificar tu zona DNS, y muchas organizaciones no quieren repartir llaves de su DNS por todos los servidores.

Para eso existe una propuesta que me parece de lo más interesante del año: DNS-PERSIST-01. En lugar de un registro nuevo en cada validación, publicas una vez un registro TXT (un registro DNS de texto libre, el que se usa para este tipo de pruebas) permanente que dice «esta autoridad puede emitir para este dominio a esta cuenta ACME»:

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

La llave sensible deja de ser el acceso al DNS y pasa a ser la clave de tu cuenta ACME. Let’s Encrypt lo anunció en febrero de 2026 con la previsión de tenerlo en producción ese mismo año, pero a 25 de junio uno de sus ingenieros escribió en el foro de la comunidad que no lo desplegarán hasta resolver una incidencia abierta en el borrador del IETF, el organismo que escribe los estándares de internet. Hoy puedes probarlo en el entorno de pruebas (staging, el ensayo general antes de la función), no en producción. Buen tema para seguir de cerca.

Qué está haciendo Let’s Encrypt

Si usas Let’s Encrypt, sus certificados ya duraban 90 días, así que el calendario del CA/B Forum no te afecta directamente. Pero Let’s Encrypt va por delante y ha publicado su propio calendario para bajar a 45. Lo hace mediante perfiles, que son como las tarifas de un contrato: el cliente ACME elige uno al pedir el certificado y cada perfil trae sus propias condiciones de duración:

Siete horas. En la práctica, cada renovación valida de nuevo.

Su recomendación es doble. La primera, no renovar a fecha fija (el clásico «30 días antes de caducar»), sino a unos dos tercios de la vida del certificado, para que la regla siga funcionando cuando cambie la duración. La segunda, y aquí viene la parte que más me gusta, usar ARI.

ARI: que la autoridad te diga cuándo renovar

ARI (ACME Renewal Information, publicado como RFC 9773; las RFC son los documentos que fijan los estándares de internet) es un mecanismo muy sencillo: tu cliente ACME le pregunta a la autoridad de certificación cuándo debería renovar un certificado concreto, y la autoridad responde con una ventana de fechas.

Parece un detalle menor hasta que piensas en el caso para el que está pensado. Si una autoridad descubre que ha emitido certificados con un error y tiene que revocarlos en masa, sin ARI solo le queda escribir correos y rezar. Con ARI, simplemente adelanta la ventana de renovación de los certificados afectados, y todos los clientes que lo consulten renovarán solos en las horas siguientes, sin que nadie tenga que leer ningún correo.

certbot lo soporta desde la versión 4.1.0, de junio de 2025: certbot renew consulta ARI automáticamente cuando la autoridad lo ofrece y puede renovar antes de tiempo si esta se lo indica. Desde la 5.0 guarda además el Retry-After que devuelve la autoridad (una cabecera HTTP que significa «vuelve a preguntar dentro de tanto»), para no consultar de más entre ejecuciones. No hay que activar nada; basta con tener una versión reciente y que la renovación se ejecute a menudo. El paquete de tu distribución o el snap instalan un temporizador de systemd, el sustituto moderno de una entrada de cron; compruébalo con systemctl list-timers | grep certbot.

Con certbot también puedes elegir perfil de Let’s Encrypt desde la versión 4.0:

# Pedir el perfil de 45 días (tlsserver) para ir probando antes de que sea obligatorio
sudo certbot certonly --nginx -d www.midominio.es --preferred-profile tlsserver

# Simular una renovación sin tocar nada
sudo certbot renew --dry-run

Pedir hoy el perfil corto en un par de servicios poco críticos es una forma barata de descubrir qué se rompe con renovaciones frecuentes antes de que no haya más remedio.

El trabajo de verdad: saber qué certificados tienes

Todo lo anterior es la parte fácil. Lo difícil, y lo que casi nadie tiene bien hecho, es el inventario. El certificado que caduca y tumba un servicio casi nunca es el del servidor web principal, que está automatizado desde hace años. Es el del balanceador que configuró alguien que ya no está, el de la interfaz de gestión de un SAI, el que está metido dentro de un almacén de claves Java (un keystore, el fichero en el que las aplicaciones Java guardan sus certificados, que no se ve con un simple ls), o el del servicio interno que habla con un proveedor por mTLS, el TLS mutuo en el que los dos extremos presentan certificado, como dos personas que se enseñan el DNI a la vez.

Un primer barrido sencillo es preguntar a cada servicio conocido qué certificado presenta y cuántos días le quedan. Este script lo hace con openssl para una lista de host:puerto:

#!/usr/bin/env bash
# dias_certificados.sh — días restantes del certificado que presenta cada endpoint
# Uso: ./dias_certificados.sh endpoints.txt   (una línea por host:puerto)

while read -r endpoint; do
  [[ -z "$endpoint" || "$endpoint" == \#* ]] && continue
  host="${endpoint%%:*}"
  fin=$(echo | timeout 5 openssl s_client -connect "$endpoint" -servername "$host" 2>/dev/null \
        | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  if [[ -z "$fin" ]]; then
    printf "%-40s  SIN RESPUESTA TLS\n" "$endpoint"
    continue
  fi
  dias=$(( ( $(date -d "$fin" +%s) - $(date +%s) ) / 86400 ))
  printf "%-40s  %4d días  (%s)\n" "$endpoint" "$dias" "$fin"
done < "$1" | sort -k2 -n

El -servername es importante: sin él, en servidores que alojan varios dominios obtendrás el certificado por defecto y no el que ven tus usuarios. Y el sort final te deja arriba lo que más prisa corre.

Para lo que está en disco, un find sobre las rutas habituales da una segunda pasada:

# Certificados en ficheros PEM bajo /etc, con su fecha de caducidad
sudo find /etc -type f \( -name "*.pem" -o -name "*.crt" \) -print0 2>/dev/null |
  while IFS= read -r -d '' f; do
    fin=$(openssl x509 -noout -enddate -in "$f" 2>/dev/null | cut -d= -f2) && echo "$fin  $f"
  done

Ninguno de los dos encontrará los certificados que viven dentro de un almacén de claves Java o de un appliance (un equipo cerrado que se administra por su propia interfaz, como un balanceador físico o un cortafuegos), pero te darán una primera lista para empezar a tirar del hilo.

Vigilar que la automatización funciona

La automatización tiene un fallo clásico: falla en silencio. El temporizador deja de ejecutarse tras una actualización, el reto HTTP-01 empieza a fallar porque alguien añadió una redirección, las credenciales del DNS caducan. Por eso la renovación automática necesita una alarma que mire el resultado, no el proceso.

Si usas Prometheus, el blackbox_exporter, que prueba servicios desde fuera como lo haría un usuario (de ahí lo de caja negra: no mira dentro, solo cómo responden), expone probe_ssl_earliest_cert_expiry, la fecha (en segundos desde el 1 de enero de 1970, el famoso epoch de Unix) en que caduca el primer certificado de la cadena que presenta el endpoint. Con ella, una alerta tiene este aspecto:

- alert: CertificadoCercaDeCaducar
  expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 20
  for: 1h
  labels:
    severity: warning
  annotations:
    summary: "El certificado de {{ $labels.instance }} caduca en menos de 20 días"

El umbral merece una reflexión. Con certificados de un año, avisar a 30 días tenía sentido. Si renuevas a los dos tercios de la vida, un certificado sano nunca debería bajar de un tercio de vida restante: unos 66 días en uno de 200, 33 en uno de 100, 15 en uno de 47. Si baja de ahí, la renovación ya ha fallado al menos una vez, y eso es lo que quieres saber. El umbral fijo de 30 días que muchos tenemos configurado desde hace años empieza a quedarse corto para unos certificados y a disparar en falso para otros.

A quién no le afecta (y a quién le va a doler)

Conviene acotar. Las reglas del CA/B Forum se aplican a los certificados TLS de servidor emitidos por autoridades de confianza pública, los que acepta un navegador sin configurar nada. Si tienes una PKI interna (infraestructura de clave pública: tu propia autoridad de certificación para servicios internos, en la que solo confían tus equipos), estas reglas no te obligan (aunque las razones de seguridad que las motivan siguen siendo razonables).

A quien le va a doler es a quien tenga equipos que no hablan ACME: interfaces de gestión de hardware, impresoras, dispositivos de red antiguos, appliances cerrados en los que el certificado se sube a mano por una web. Para esos casos hay pocas salidas buenas: ponerlos detrás de un proxy inverso (un servidor que recibe las conexiones en su nombre, como una recepción que atiende las visitas de toda una oficina) que sí se renueve solo, pasarlos a la PKI interna si no necesitan confianza pública, o automatizar la subida mediante la API del fabricante, si la tiene. Lo que no va a funcionar es seguir subiendo a mano un .pfx (el formato de fichero que empaqueta certificado y clave privada, habitual en entornos Windows) cada 47 días.

Para cerrar

La caída de Microsoft del 31 de agosto no tuvo nada que ver con las nuevas reglas; fue un certificado que alguien, o algo, no renovó. Justo por eso es buen recordatorio: el problema nunca ha sido la duración de los certificados, sino que su renovación dependía de la memoria de alguien. Las nuevas reglas no crean ese problema, lo hacen imposible de ignorar.

Si tuviera que priorizar para este mes: primero el inventario, aunque sea imperfecto; después, renovación automática con un cliente que soporte ARI; y por último, una alerta que mire días restantes y no si el proceso ha corrido. En ese orden, porque no se puede automatizar lo que no se sabe que existe.

Fuentes:

• DigiCert: TLS certificate lifetimes will officially reduce to 47 days — calendario y motivos de la votación.
• Let’s Encrypt: de 90 a 45 días — calendario de Let’s Encrypt y recomendación de ARI.
• Let’s Encrypt: DNS-PERSIST-01 — cómo funciona la validación persistente.
• Born’s Tech and Windows World: M365 outage due to forgotten certificate renewal — la caída del 31 de agosto.