Renovación de certificados SSL/TLS: automatización, casos rebeldes y umbral de compra

⚡TL;DR

• Las renovaciones no consumen la cuota de Let's Encrypt de 50 certificados por dominio registrado. Ese límite mide la entrada de nombres nuevos, no el tamaño de un parque. Creer lo contrario falsea cualquier dimensionamiento.
• Lo que rompe una renovación de certificado SSL casi nunca es ACME, sino los endpoints que ningún script recarga: appliances con interfaz web, keystores con contraseña interactiva, terminaciones TLS gestionadas sin API.
• Un inventario se lleva por par (host, puerto), no por nombre de host. Sobre una misma dirección IP, ldap.google.com devuelve a un cliente por defecto dos números de serie distintos en los puertos 389 y 636, y un escáner que olvida el SNI registra un tercer serial, estable y falso.
• ACME, ARI y las seis fases del ciclo de vida se dan aquí por sabidos: se tratan en la guía de gestión del ciclo de vida de los certificados.

La renovación de un certificado SSL rara vez falla donde uno se lo espera. El modo de fallo más habitual no es un error de emisión bien visible en un registro: es un certbot renew que sale en verde durante semanas mientras el servicio sigue presentando el certificado antiguo. Dos líneas de openssl lo detectan: el número de serie leído en el disco frente al que realmente se sirve en el puerto. Nada, en los registros del cliente ACME, lo hará por ti. Las salidas reales están más abajo.

El contexto endurece la mecánica. A 21 de julio de 2026, un certificado TLS público no puede superar los 200 días de validez, y el mismo límite se aplica a la reutilización de la validación de control del dominio. Los siguientes escalones caen en marzo de 2027 y luego en marzo de 2029, y el segundo desacopla validez y revalidación. El porqué de ese calendario se trata en nuestro artículo sobre la reducción a 47 días. Aquí hablamos del cómo: lo que se rompe en concreto cuando sube la frecuencia, y qué se pone enfrente.

Este playbook se dirige a los equipos que gestionan entre 50 y 1000 certificados en un parque heterogéneo, sin un equipo de PKI dedicado. Encontrarás comandos ejecutados con sus salidas reales, las trampas que los acompañan, y los puntos donde no hemos podido medir nada, dichos como tales. Sin comparativas de fabricantes. Un único criterio de compra, con cifras, y no se refiere al número de certificados.

Caducidad de los certificados SSL en 2026: el escalón vigente y qué cambia para tus scripts

A 21 de julio de 2026, el escalón aplicable es el que entró en vigor el 15 de marzo de 2026. Fija tres techos: 200 días de validez máxima, 200 días de reutilización de la validación de control del dominio (DCV) y 398 días de reutilización de la información de identidad del suscriptor (SII). Es el techo duro de los Baseline Requirements del CA/Browser Forum.

En la práctica, las autoridades de certificación emiten por debajo. El texto recomienda no superar los 199 días y solo prohíbe más allá de 200, así que todo el mundo se guarda ese margen operativo. DigiCert dejó de aceptar solicitudes de certificados TLS públicos con una validez superior a 199 días el 24 de febrero de 2026, unas tres semanas antes del plazo. Sectigo hizo lo mismo el 12 de marzo de 2026: 199 días de validez para todo certificado TLS emitido o reemitido, 198 días de reutilización de la DCV.

Lo que viene ya tiene fecha. El 15 de marzo de 2027, la validez máxima y la reutilización de la DCV pasan ambas a 100 días. El 15 de marzo de 2029, la validez baja a 47 días y la reutilización de la DCV a 10 días. La SII, en cambio, se mantiene fijada en 398 días a lo largo de todo el calendario: su único escalón es el del 15 de marzo de 2026.

Cuidado con el atajo más extendido: en 2029 no es la validez la que cae a 10 días, es la reutilización de la prueba de control del dominio. Los dos contadores se separan, y es precisamente ahí donde todo cambia para tus scripts. Hoy, una validación correcta cubre varias renovaciones consecutivas. En 2029, cada reemisión arrastrará detrás una revalidación completa, porque la prueba anterior habrá caducado hace tiempo. Automatizar la emisión ya no bastará. Hará falta que la validación esté automatizada de forma permanente, es decir, que los permisos de escritura en el DNS o el acceso al puerto 80 estén disponibles de forma continua, y no solo el día en que un humano planifica un cambio.

Inventariar un parque de certificados: cuatro fuentes, cuatro puntos ciegos

Ninguna fuente de inventario ve la totalidad de un parque. Los registros de transparencia listan lo que se ha emitido públicamente, el disco y los almacenes listan lo que está instalado, el escaneo de red lee lo que se sirve, y las API de los proveedores cubren lo que las otras tres no ven. Hay que cruzarlas, y sobre todo saber qué se le escapa a cada una.

Los registros de transparencia muestran lo que se emitió, no lo que está en marcha

Los registros de Certificate Transparency recogen todo certificado emitido por una autoridad pública para tus dominios. No dicen ni dónde está desplegado, ni si sigue en servicio. La consulta ingenua cabe en una línea:

curl -s 'https://crt.sh/?q=%25.captaindns.com&output=json' | jq -r '.[].name_value' | sort -u

En nuestro dominio devolvió 12 valores únicos en 54 segundos. Una ejecución anterior había devuelto tres HTTP 502 consecutivos antes de completarse al cuarto intento. Nada roto en el comando: crt.sh responde así.

Lo que sigue nos lo encontramos al ejecutar, no lo dedujimos. La opción -s oculta el fallo: jq recibe HTML y saca jq: parse error: Invalid numeric literal at line 1, column 7, y sin set -o pipefail el script sigue como si nada. Los 54 segundos son un tiempo de respuesta nominal para 142 certificados, no una limitación de tasa. El %25 codifica el comodín %, que cubre los subdominios pero no el apex. El campo name_value contiene saltos de línea cuando el certificado lleva varios SAN: 142 objetos JSON produjeron 158 líneas para 12 valores únicos, lo que hace obligatorio el sort -u. Por último, los certificados caducados se incluyen por defecto: 76 de las 142 entradas.

La versión endurecida corrige todo eso:

curl -sS --fail --retry 8 --retry-all-errors --retry-delay 5 --max-time 180 \
  -o crt.json 'https://crt.sh/?q=%25.captaindns.com&output=json&exclude=expired' \
&& jq -r '.[].name_value' crt.json | sed 's/^\*\.//' | tr 'A-Z' 'a-z' | sort -u

Salida real: código 0 en 41,9 segundos, reintentos incluidos, 66 entradas frente a 142 sin el filtro del servidor, y 11 nombres. Se probaron y descartaron dos variantes, y son las que más enseñan. Sin -o, con salida a stdout, curl concatena el cuerpo del 502 con el del 200 correcto: 8342 bytes que empiezan por <html><head><title>502 Bad Gateway</title> seguidos del JSON válido, y jq falla. Con -o, curl rebobina el fichero en cada intento. Y --fail --retry 8 sin --retry-all-errors no reintenta: curl 8.7.1 devuelve curl: (56), un código ausente de la lista de errores que curl reintenta por defecto. Fallo en 0,12 segundos.

Queda el punto ciego estructural: la transparencia solo ve la PKI pública. Tus certificados internos no aparecen ahí.

El disco y los almacenes muestran lo que está instalado, no lo que se sirve

Leer un fichero PEM, un keystore Java o el almacén de máquina de Windows informa sobre lo que está puesto en la máquina. No sobre lo que el servicio presenta a la red.

Del lado PEM, basta con openssl x509 -in fullchain.pem -noout -subject -dates -serial. Para los otros dos, honestidad por delante: no hemos podido ejecutar los comandos correspondientes. Nuestro equipo de pruebas no tiene JDK y no funciona con Windows. En lugar de una salida inventada, esta es la traza del intento:

$ keytool -list -v -keystore /Library/Keychains/System.keychain
The operation couldn't be completed. Unable to locate a Java Runtime.

$ file /usr/bin/keytool
/usr/bin/keytool: Mach-O universal binary with 2 architectures

$ pwsh -NoProfile -Command 'Get-ChildItem Cert:\LocalMachine\My'
Get-ChildItem: Cannot find drive. A drive with the name 'Cert' does not exist.

Estos dos fallos desmontan cada uno un falso positivo de disponibilidad. La máquina sí expone un binario /usr/bin/keytool, pero es un binario de relleno de Apple que redirige al sitio de Java: un which keytool que responde no prueba nada en macOS. Y instalar PowerShell 7 en macOS o Linux no da ningún acceso al almacén de certificados, ya que el proveedor Certificate es un componente de Windows ausente de la lista de PSProvider. Este script solo se valida sobre su destino.

Las trampas cuentan tanto como los comandos. keytool pide su contraseña de forma interactiva, y pasarla con -storepass la expone en el historial y en ps: mejor usar -storepass:file. Desde el JDK 9, el formato por defecto es PKCS12, no JKS. En Windows, LocalMachine\My exige una consola abierta en modo administrador, y si no la lista vuelve truncada sin ningún mensaje de error, y un binding de IIS puede apuntar a una huella distinta de lo que está instalado.

El escaneo de red nunca verá tus servidores de correo

Un escaneo de red lee lo que realmente se sirve, lo que lo convierte en la fuente más fiable. Desde un equipo corriente o desde la mayoría de las nubes, nunca verá tus servidores de correo: el puerto 25 saliente está filtrado ahí.

La prueba cabe en tres líneas, sobre un único host. smtp.gmail.com resolvía, en el momento de la prueba, a una dirección única, y los frontales de Google rotan: sea cual sea la dirección devuelta por la resolución, los tres puertos dan el mismo contraste. El puerto 587 en STARTTLS y el puerto 465 en TLS implícito aceptan la conexión y devuelven el certificado; en el puerto 25, la conexión expira. La máquina es alcanzable, es el puerto el que está bloqueado. Repetida contra siete MX públicos de seis operadores distintos, dos de Google, más Proton, OVH, Riseup, Yandex y GMX, el mismo comando expira siete de siete veces.

El puerto 25 está filtrado en nuestra red, en salida. El matiz cuenta, porque la conclusión contraria se arrastra por todas partes. Google no cierra nada. AWS, GCP, Azure y OVH bloquean el 25 saliente por defecto, igual que casi todos los accesos residenciales. Un escaneo de parque lanzado desde una máquina de ese tipo produce, por tanto, un resultado mecánicamente incompleto.

El mismo síntoma encubre, sin embargo, dos causas distintas, y la segunda no viene de tu red. Desde el mismo equipo, pop.gmail.com expira en el puerto 110 mientras pop.gmx.net responde ahí, e imap.gmx.net responde en el 143, con STARTTLS validado, igual que en el 993; el 995 funciona en todas partes. Los puertos en claro no están, pues, filtrados en salida, al contrario que el 25: son los hosts de Google los que descartan esos paquetes sin responder, porque no sirven ni POP3 ni IMAP en claro. Política del proveedor por un lado, filtrado de la red por otro: dos causas de «inalcanzable», un solo síntoma. Antes de concluir que un puerto está filtrado, prueba con un segundo operador.

Un escáner de inventario debe distinguir, por tanto, tres estados, no dos: certificado leído, certificado en error y host no alcanzado. Un «inalcanzable» contado como un «nada que señalar» es el peor resultado posible, porque el panel sigue en verde sobre servicios que nunca se han medido. Y en los MX el asunto no es teórico: si el certificado cambia antes de que se publique el registro TLSA correspondiente, la RFC 7672 prohíbe la entrega del mensaje a través de ese servidor y obliga al emisor a pasar al MX siguiente o a diferir la entrega.

Nuestras propias herramientas caen bajo el mismo límite: el monitor de uptime de CaptainDNS solo acepta los esquemas HTTP y HTTPS. SMTP, IMAPS y LDAPS quedan fuera de su alcance.

Las API de los proveedores ven lo que las otras tres fuentes vinculan mal

Queda la cuarta fuente, la menos espectacular: las API de los proveedores. AWS Certificate Manager, Cloudflare o un CDN que termina el TLS por ti tienen certificados que ninguna otra cosa vincula correctamente a tu parque. Los registros de transparencia los ven sin decir quién los opera, el disco no los contiene, y el escaneo de red los atribuye a la infraestructura del proveedor en lugar de a tu servicio. La API es el único sitio donde esas terminaciones gestionadas existen con su fecha de caducidad y su modo de renovación.

Su punto ciego es simétrico: cada API solo cubre lo que vive en ese proveedor, y presupone permisos de lectura que el equipo que inventaría no siempre tiene. Tres proveedores son tres consultas, tres juegos de credenciales y tres formatos de respuesta que reconciliar.

Un inventario se indexa por par (host, puerto), no por nombre

Mismo nombre, misma dirección IP, dos certificados. ldap.google.com resuelve a una dirección IPv4 única, 216.239.32.58. Un cliente por defecto lee ahí el número de serie 84D4296C en el puerto 389 con STARTTLS, y E97CCECB en el puerto 636 con TLS implícito. Tres ejecuciones idénticas, tres veces el mismo resultado.

Primera trampa, el SNI. Sin él, los dos puertos devuelven el centinela de Google, CN=invalid2.invalid con OU=No SNI provided - please fix your client., número B3E9BADC: un escáner sin SNI registra un valor perfectamente estable y perfectamente falso, siempre sin error.

El puerto en sí no es, sin embargo, la causa de la diferencia entre 389 y 636. El listener del 389 tiene los dos certificados y decide según los algoritmos de firma que anuncia el cliente:

openssl s_client -starttls ldap -connect ldap.google.com:389 -servername ldap.google.com \
  -sigalgs 'RSA-PSS+SHA256:rsa_pkcs1_sha256' </dev/null 2>/dev/null | openssl x509 -noout -serial

serial=E97CCECBFFF70F940963C3B2C1F06634

El 389 devuelve, pues, bajo demanda el certificado que creíamos propio del 636. Lo contrario falla: ECDSA+SHA256 forzado en el 636 provoca un tls alert handshake failure (alerta 40), sin ningún certificado. El 636 solo tiene el RSA, y eso es lo que salva la indexación por par (host, puerto). Pero la configuración TLS del escáner es una variable de entrada igual que el puerto: dos escáneres con algoritmos de firma distintos inventarían dos números de serie distintos sobre el mismo par, sin levantar el menor error. Congela y documenta la configuración TLS del escáner, o el inventario no será reproducible de una ejecución a otra.

En otros sitios el comportamiento se invierte: en Gmail, los puertos 465 y 587 sirven el mismo certificado, 6D09D839.... Nada de esto se adivina, y un inventario indexado por nombre de host cuenta mal en ambos sentidos: fusiona certificados distintos o duplica el mismo.

La tabla de auditoría descargable al final del artículo recoge estas columnas: una fila por par (host, puerto), el modo TLS, el estado del último escaneo con sus tres valores posibles, el método de depósito, el de recarga, el propietario con nombre y apellidos y la clase de automatización. Tres filas de ejemplo muestran el relleno esperado, el resto está en blanco.

Delegar _acme-challenge sin entregar las llaves de la zona

Delegar _acme-challenge mediante CNAME da al cliente ACME permiso de escritura sobre una zona de validación dedicada, y nada más. Tu zona de producción no se mueve: mismos registros, misma API cerrada.

Qué es la delegación CNAME y qué no es

La RFC 8555 no menciona el CNAME. La palabra no aparece en ninguna parte de su texto, comprobado. La delegación no es, por tanto, una recomendación del estándar ACME: está documentada y soportada por Let's Encrypt, cuya validación DNS-01 sigue las reglas DNS ordinarias y acepta que un CNAME o una delegación NS lleve la respuesta al desafío hacia otra zona. En el plano normativo, los Baseline Requirements citan explícitamente el registro CNAME entre los soportes válidos del método de validación «DNS Change», en la sección 3.2.2.4.7.

La distinción cabe en una línea: soportada por el ecosistema, ausente del estándar.

El beneficio, en cambio, es claro. El cliente ACME recibe credenciales que solo escriben en una zona de validación, a menudo alojada en otro sitio. El compromiso del servidor que renueva no da entonces ningún poder sobre tus registros MX, A o TXT de producción. Al barrer 32 dominios públicos encontramos varias delegaciones reales de este tipo: fastmail.com apunta a fastmail.com.acme-challenge.fmhosted.com, github.com a github.com.acme.github.net, reddit.com a un destino dcv.cloudflare.com, eff.org y digitalocean.com a fastly-validations.com.

Verificar una delegación: tres pasos, nunca uno solo

Una sola consulta no prueba nada. La verificación completa exige tres, y la tercera es la que convierte una duda en prueba.

Paso 1, el CNAME existe:

dig +noall +answer _acme-challenge.fastmail.com CNAME

_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

Eso es todo lo que dice este comando: hay un CNAME escrito. No prueba que la delegación funcione.

Paso 2, seguir la cadena hasta el TXT y leer el estado:

dig +noall +answer +comments _acme-challenge.fastmail.com TXT

Tres casos reales, y es aquí donde la mayoría de los artículos se equivocan:

CASO A - fastmail (CNAME presente, destino sin TXT activo)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59352
_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

CASO B - reddit (CNAME presente, destino existente)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8461
_acme-challenge.reddit.com. 292 IN CNAME reddit.com.7ee8918f112aca0f.dcv.cloudflare.com.

CASO C - captaindns.com (ninguna delegación)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27534
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Hay que cruzar dos señales, nunca una sola. Un CNAME en la sección ANSWER con un NXDOMAIN significa que la delegación está escrita pero que el destino no existe en ese instante, porque el TXT solo se crea en el momento del desafío. Es el estado normal entre dos renovaciones: de las siete delegaciones públicas que consultamos, seis estaban en ese caso. El fallo de verdad es un NOERROR con ANSWER: 0, es decir, ninguna delegación en absoluto. Una supervisión que alerte sobre el NXDOMAIN de _acme-challenge producirá ruido permanente, y se equivocará seis de cada siete veces.

Paso 3, verificar en el nivel autoritativo y confirmar que la zona de destino está viva:

ns=$(dig +short NS fastmail.com | head -1)
dig +noall +answer +comments @"$ns" _acme-challenge.fastmail.com CNAME
dig +noall +answer +comments acme.github.net SOA

El SOA de acme.github.net responde NOERROR mientras que la consulta TXT sobre _acme-challenge.github.com devolvía NXDOMAIN: la delegación está sana, solo falta la respuesta al desafío porque no hay ninguna renovación en curso. Un SOA en NXDOMAIN o en SERVFAIL sobre la zona de destino, en cambio, señala una delegación rota de verdad, típicamente una cuenta de validación eliminada o un dominio caducado.

El nombre empieza por un guion bajo, que algunas interfaces de administración se comen o prefijan por duplicado: verifica el FQDN devuelto en la respuesta DNS, no lo que muestra el panel; una consulta CNAME en la herramienta DNS Lookup lo enseña sin abrir un terminal. Un CNAME sobre _acme-challenge es incompatible con cualquier otro registro con el mismo nombre, de modo que un TXT de validación antiguo que se haya quedado ahí deja la zona inválida. Los TTL observados van de 3600 a 120 segundos según los dominios: tras una corrección, un resolvedor puede servir la respuesta antigua, NXDOMAIN incluido, durante todo ese tiempo, y esa es la causa número uno de los fallos de validación justo después de un cambio. El head -1 solo prueba un servidor autoritativo. Por último, consultar la zona de destino no prueba que el cliente tenga permisos de escritura ahí: solo una emisión real lo prueba.

El límite de un solo delegado por dominio, y el borrador que lo levanta

El DNS solo permite un CNAME por nombre. _acme-challenge.captaindns.com solo puede, por tanto, delegarse a un cliente a la vez. Multi-CDN, multirregión, migración sin corte, certificado de respaldo emitido por una segunda autoridad: estas cuatro necesidades chocan todas contra el mismo muro, y no existe ningún rodeo limpio del lado del DNS.

Un borrador en curso en el IETF ataca el problema. El draft-ietf-acme-dns-account-label-03, Active Internet-Draft del grupo de trabajo ACME, revisión 03 del 15 de mayo de 2026, en última llamada del grupo de trabajo en el momento de nuestra comprobación, define un desafío llamado dns-account-01. El principio: prefijar el nombre de validación con un hash de la URL de la cuenta ACME, según la construcción "_" || base32(SHA-256(ACCOUNT_URL)[0:10]) || "._acme-challenge". Cada cuenta obtiene así su propio nombre de validación, y varios clientes pueden validar en paralelo sobre el mismo dominio.

Es un borrador, no una norma. No tiene número de RFC, su contenido puede cambiar en la siguiente revisión, y no anunciamos ninguna disponibilidad en ninguna autoridad de certificación. A seguir si tu arquitectura es multiproveedor, a no meter en un plan de despliegue.

La renovación de un certificado SSL no acaba en la emisión: la recarga es el verdadero eslabón débil

certbot renew escribe el nuevo certificado en el disco. No recarga ni nginx, ni postfix, ni haproxy. Entre el momento en que la emisión funciona y aquel en que el servicio presenta el nuevo certificado hay una recarga, y es ahí donde la cadena se rompe más a menudo, sin que se encienda ningún registro. La respuesta del lado del cliente se llama deploy hook, y la guía de gestión del ciclo de vida de los certificados le dedica su fase 3; el control que sigue verifica, desde fuera, que realmente ha funcionado.

El control posterior a la renovación y sus cinco falsos positivos

El único control que cuenta compara el número de serie leído en el disco con el que realmente se sirve en la red:

HOST=api.captaindns.com
FILE=/etc/letsencrypt/live/$HOST/fullchain.pem

disk=$(openssl x509 -in "$FILE" -noout -serial | cut -d= -f2)
served=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
         | openssl x509 -noout -serial | cut -d= -f2)

echo "disco  =$disk"
echo "servido=$served"
[ "$disk" = "$served" ] \
  && echo "OK: el certificado servido es el del disco" \
  || echo "ALERTA: el servicio sirve un certificado ANTIGUO -> se requiere recarga"

Las dos ramas se ejecutaron de verdad, con dos números de serie distintos:

CASO 1 - concordancia
disco  =05DFD8366DC6A73780F3707BC7E13F91E0EC
servido=05DFD8366DC6A73780F3707BC7E13F91E0EC
OK: el certificado servido es el del disco

CASO 2 - divergencia
disco  =05DFD8366DC6A73780F3707BC7E13F91E0EC
servido=05B499411D7820A6C0EC7A0626E1BA25CF67
ALERTA: el servicio sirve un certificado ANTIGUO -> se requiere recarga

Este control tiene sus trampas, y la primera es tonta. El cut -d= -f2 no es decorativo: openssl muestra serial=05DF... y la comparación falla sin él. Compara el número de serie, nunca la fecha de caducidad: dos certificados renovados el mismo día pueden compartir notAfter. El fichero fullchain.pem contiene varios certificados y openssl x509 -in solo lee el primero, de modo que un fichero ordenado al revés hace comparar el intermedio y falla el test de forma permanente. Detrás de un balanceador de carga que termina el TLS, el certificado puesto en el disco del origen no tiene nada que ver con lo que se sirve al público: el control se convierte en un falso positivo permanente, y hay que apuntar desde fuera del balanceador. Por último, para identificar el fichero en lugar de la emisión, sustituye -serial por -fingerprint -sha256.

Este control no tiene nada de específico del 443. Lo repetimos fuera de la web: en TLS implícito sobre el puerto 465, y luego en STARTTLS sobre el puerto 587, con el mismo número de serie 6D09D839... en ambos lados. Un parque de correo se controla exactamente igual, salvo por la opción de conexión.

La huella SPKI SHA-256 ofrece un control complementario, aguas arriba. La exponen tanto nuestro SSL Certificate Checker como el CSR Parser, lo bastante para demostrar que una CSR dada ha producido efectivamente el certificado servido. La correlación es manual: nada la hace automáticamente por ti.

¿Todos tus frontales sirven el mismo certificado?

Un bucle sobre las direcciones IP del servicio responde a la pregunta en unos segundos:

HOST=debian.org
for ip in $(dig +short A "$HOST" | grep -E '^[0-9]'); do
  printf '%-16s ' "$ip"
  openssl s_client -connect "$ip:443" -servername "$HOST" </dev/null 2>/dev/null \
    | openssl x509 -noout -serial | cut -d= -f2
done

En debian.org, las cuatro direcciones devueltas dieron todas el mismo número de serie, 057EB3AB.... Parque homogéneo por ese lado. El meollo del truco está en el -servername puesto cuando uno se conecta a una IP: sin él, se obtiene el certificado por defecto del frontal, no el del vhost buscado. El grep -E '^[0-9]' filtra las líneas de CNAME que dig +short intercala, un comportamiento observado en www.google.com por culpa de una reescritura del resolvedor local.

El bucle solo cubre IPv4: añade una pasada sobre dig +short AAAA con -connect "[$ip]:443". El otro límite es más traicionero. Detrás de un anycast (una misma dirección anunciada desde varios puntos del planeta), esas cuatro direcciones pertenecen al mismo punto de presencia visto desde tu equipo: lo pruebas cuatro veces, no los otros N repartidos por el mundo.

Diagnosticar un puerto mal identificado con una línea de error

No hace falta adivinar el modo de un puerto: openssl lo dice en su mensaje de error. Un wrong version number significa que falta -starttls: el servidor espera un diálogo en claro antes de la negociación. A la inversa, un Didn't find STARTTLS in server response, trying anyway... seguido de un unexpected eof while reading significa que el -starttls sobra, sobre un puerto ya cifrado: openssl lo intenta igualmente, espera un banner en claro de un servidor que solo espera TLS, y la conexión muere en un EOF.

El comando equivalente sobre un MX en el puerto 25 se escribe así:

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 \
  -servername gmail-smtp-in.l.google.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -serial

No validado desde nuestro equipo, puerto 25 saliente filtrado; sintaxis validada de forma idéntica en el 587. No publicamos, por tanto, ninguna salida para este caso. Aun así, vale la pena señalar tres trampas: el 2>/dev/null se traga el error real y te deja con un Could not find certificate from <stdin> sea cual sea el problema, el </dev/null evita que la sesión quede abierta, y el -servername debe llevar el nombre del MX, no el del dominio de correo.

DANE y TLSA: el único caso en el que el orden de las operaciones es normativo

La recarga tiene un último piso, reservado a los MX que publican registros TLSA. Ahí, el orden de las operaciones deja de ser una buena práctica para convertirse en una obligación. La RFC 7671, sección 8.1, describe la rotación en cuatro tiempos: publicar el registro TLSA del futuro certificado junto al del certificado actual, esperar al menos dos TTL el tiempo de que se vacíen las cachés, desplegar entonces el nuevo certificado y comprobar que funciona, y por último retirar el registro que ha quedado obsoleto. Dos TTL, no 48 horas: la RFC razona en TTL, y tus TTL no son los nuestros.

Para SMTP, la RFC 7672 lo convierte en una obligación formal. En caso de desincronización, la entrega queda prohibida a través de ese servidor, y el emisor pasa al MX siguiente o difiere la entrega.

El modo de fallo es asimétrico, y eso es lo que lo hace temible. Del lado del operador culpable, ninguna alerta: la conexión la aborta el cliente, los emisores que no validan DANE siguen entregando, la supervisión sigue en verde. La RFC 7672 emplea la palabra «unwittingly» para describir a ese dominio socio que acaba mal configurado sin saberlo. Del lado del emisor que valida no es silencioso, pero sí diferido: los mensajes se acumulan en cola, con avisos de retraso y luego posibles rebotes al vencer. El destinatario final, por su parte, no recibe ni el mensaje ni la menor notificación.

Queda una condición que la sección 8.1 plantea sin subrayarla: el uso, el selector y el tipo de correspondencia deben permanecer sin cambios. Si modificas uno de esos tres parámetros, se aplica la sección 8.3, y la regla se invierte.

Los casos rebeldes a ACME: lo que no se deja automatizar

Una parte del parque se resiste, y no por razones de protocolo. ACME sabe emitir para casi todo. Lo que atasca es la instalación, la recarga o el nivel de validación exigido.

La PKI interna y los certificados de dos años

Las autoridades internas escapan al calendario del CA/Browser Forum, así que nada las empuja a acortar ni a automatizar. La instancia de demostración pública de FreeIPA lo muestra bien: en la comprobación del 21 de julio de 2026, ipa.demo1.freeipa.org servía un certificado válido del 23 de abril de 2025 al 24 de abril de 2027, es decir, dos años, sobre una cadena firmada por una raíz privada.

Visto desde un equipo externo, openssl devuelve verify error:num=19 self-signed certificate in certificate chain. Ese código se confunde a menudo con otro: verify error:num=20 unable to get local issuer certificate. No describen la misma situación. El 19 significa que el servidor sí envía su raíz privada en la cadena, pero que esta falta en tu almacén local. El 20 significa que el intermedio no se envía en absoluto y que openssl no puede remontar la cadena. En los dos casos el diagnóstico es el mismo: problema de almacén de confianza, no problema de certificado. Y la corrección también: -CAfile internal-ca.pem.

Existen pasarelas para traer esos parques hacia ACME. Ninguna se despliega sin contrapartida, y más vale conocerla de antemano.

• acme2certifier, bajo licencia GPLv3, pone una fachada ACME delante de Microsoft ADCS mediante MS-WCCE o los Certificate Enrollment Web Services. La revocación no está soportada y la cadena de la autoridad hay que cargarla a mano. Es un proyecto comunitario sostenido por un único mantenedor, activo: versión 0.44 el 18 de julio de 2026.
• step-ca es un punto único de fallo en su configuración por defecto, por culpa de su base embebida Badger, que no gestiona la concurrencia. La documentación describe un despliegue multiinstancia, al precio de una base MySQL o PostgreSQL externa y de la gestión remota de los aprovisionadores.
• HashiCorp Vault expone un servidor ACME desde la versión 1.14.0, con una vida útil limitada a 90 días. Es un servidor, no un cliente, y ese matiz lo cambia todo en una arquitectura.
• EJBCA Community Edition: Keyfactor lo escribe él mismo en el README del repositorio oficial, «EJBCA Community Edition is not intended for production use.»

Los certificados que ACME no puede entregar

El nivel de validación extendida no se obtiene mediante ACME. Presupone una verificación de identidad jurídica (categoría de actividad, jurisdicción de registro, número en el registro mercantil) que ningún desafío automatizado produce.

El caso se cruza en producción. En la misma comprobación, en el puerto 465, posteo.de servía un certificado de validación extendida válido del 18 de febrero de 2026 al 24 de febrero de 2027, es decir, 371 días. Y sin embargo, ninguna infracción del techo de 200 días. El certificado se emitió antes del 15 de marzo de 2026, y la regla no es retroactiva. No sacamos ninguna conclusión sobre las prácticas de renovación de ese operador.

El terreno se estrecha aún más. Los certificados de marca VMC y CMC, utilizados por BIMI, se descodifican con nuestro analizador dedicado pero no son certificados TLS de servidor. Los certificados de cliente, en particular los que llevan una autenticación mutua, siguen por su parte una cadena de emisión y una distribución que no tienen nada que ver con ACME.

Los endpoints que ningún script recarga

Ahí está el verdadero techo de la automatización, y la única cifra que cuenta para decidir una compra. Repasa tu parque y cuenta lo que sigue.

Las appliances de red administrables únicamente por interfaz web. Los balanceadores de carga físicos, cuya actualización de certificado pasa por un formulario. Las impresoras, los equipos industriales, las cámaras y todo lo que lleva embarcado un servidor HTTPS olvidado desde la instalación. Los keystores Java protegidos por una contraseña interactiva, que bloquean en seco cualquier ejecución desatendida. Los almacenes de Windows, donde instalar un certificado no basta, ya que un binding de IIS puede seguir apuntando a otra huella. Las terminaciones TLS gestionadas en un proveedor que no expone ninguna API.

El punto común no es la emisión: ACME sabe emitir para todos esos nombres. Son la instalación y la recarga las que siguen siendo manuales. Un script puede obtener el certificado en unos segundos y quedarse luego esperando a que un humano se conecte a una interfaz para ponerlo. Con 200 días de validez, ese humano interviene dos veces al año y nadie se queja. Con 47 días, interviene ocho veces al año y por endpoint como mínimo estricto, renovando al vencimiento, y once o doce renovando a los dos tercios como se recomienda. El coste se convierte en una partida presupuestaria.

Mídelo ahora, mientras la frecuencia todavía es baja: número de endpoints afectados, minutos realmente empleados por rotación, propietario con nombre y apellidos. Esas tres columnas valen más que todas las comparativas de herramientas.

Cadencia, perfiles cortos y lo que realmente limita un bucle de renovación

Un bucle de renovación no está limitado por el tamaño del parque. Está limitado por la cadencia a la que cada nombre reemite, y por dos o tres límites de tasa que no tienen nada de intuitivos.

Cuándo renovar: la regla de los dos tercios tiene una excepción

La regla general es simple: renovar cuando queda un tercio de la vida útil total. Es decir, 30 días antes del vencimiento para un certificado de 90 días. Pero la documentación de Let's Encrypt prevé una excepción explícita para los certificados válidos menos de diez días: para esos, la renovación se recomienda a mitad de vida.

El perfil shortlived cae justo en la excepción. Vale 160 horas, es decir, 6,67 días. Su mitad de vida está, pues, en las 80 horas, lo que da 2,1 emisiones por semana y por nombre.

Ese 2,1 es un modelo, no un valor publicado por Let's Encrypt. Sus cinco hipótesis, en claro. La validez de 160 horas está documentada. Reducir la semana a 168 horas fijas es una aproximación: el mecanismo real es un cubo de fichas con recarga continua. La renovación a una fracción fija y determinista, sin jitter ni reintentos, es una hipótesis de modelado. Un certificado equivale a un nombre, mientras que shortlived acepta hasta 25 nombres: agrupar divide el número de certificados en la misma proporción. Y el cálculo supone cero fallos.

La reserva más importante: con ARI, que es el modo nominal, la cadencia no sigue una fracción fija sino la ventana sugerida por el servidor, cuya posición y anchura no se publican. Toda cadencia expresada en fracción de vida útil describe, por tanto, una red de seguridad, no el régimen normal.

En cuanto a la «treintena de nombres por dominio en perfil corto» que circula, divide una cuota que las renovaciones no consumen por una cadencia que no se aplica a ese perfil: no la recogemos.

Lo que Let's Encrypt llama una renovación

Dos mecanismos, dos regímenes de exención. Confundirlos es el error que más caro sale en explotación.

Con ARI, el comando newOrder designa explícitamente el certificado al que sustituye. Tres condiciones, en realidad: esa designación, al menos un identificador en común con el certificado saliente, y un saliente que no haya sido sustituido ya una primera vez. La exención es entonces total. Todos los límites saltan, sin excepción, y el perímetro de los SAN puede incluso cambiar, ya que la identidad del certificado saliente la lleva el campo dedicado.

Con la detección por conjunto exacto, el régimen es más estrecho. El conjunto de identificadores debe ser estrictamente idéntico, sin que las mayúsculas ni el orden tengan efecto (matiz que muchos artículos invierten). La exención solo cubre entonces New Orders per Account y New Certificates per Registered Domain.

El corolario merece colgarse de la pared: agrandar un certificado SAN para añadirle un subdominio consume la cuota de los 50 por dominio registrado, mientras que la renovación idéntica no consume ninguna. Escribir «50 certificados por semana y por dominio» sin esa precisión equivale a describir un techo de parque que no existe. Ese límite mide un caudal de entrada de nombres nuevos.

Los límites que muerden, por orden de peligrosidad

Hay cinco límites de tasa que conviene conocer, y no todos valen lo mismo. Aquí están, del más peligroso al menos molesto.

El primero es el único que un bucle legítimo puede agotar por sí solo: 5 fallos de autorización por identificador, por cuenta y por hora, con recarga de un fallo cada 12 minutos, sin posibilidad de ampliación, y sobre todo con aplicación a las renovaciones. El segundo cuenta los fallos consecutivos y pone el identificador en pausa al cabo de 1152 fallos seguidos. Es un contador de racha, no un caudal, y se recarga a razón de una ficha por identificador y por día: un día con cinco fallos solo consume cuatro en neto, y la pausa no llega hasta los 288 días; con 120 fallos al día llega al cabo de 10 días, y con uno solo al día, nunca. Estos valores no salen de un cálculo casero, la documentación de Let's Encrypt publica la tabla. No fusiones los dos límites.

Viene después el verdadero techo de un bucle sin ARI: 5 certificados por conjunto exacto de identificadores cada 7 días, con recarga de un certificado cada 34 horas, sin ampliación posible. Una cadencia de 2,1 pasa holgadamente, y el margen absorbe los reintentos. Más abajo en la clasificación, 10 cuentas por dirección IP cada 3 horas solo muerde si cada nodo crea su propia cuenta en vez de compartir una. El último ni siquiera es una cuota, sino una restricción de perfil: shortlived tiene un tope de 25 nombres por certificado, frente a 100 en classic. Pasar al perfil corto obliga, por tanto, a trocear los certificados SAN grandes, y esos troceos son emisiones nuevas, no renovaciones.

Los límites de tasa de Let's Encrypt que afectan a un bucle de renovación

Valores documentados en la página oficial de rate limits, consultada el 21 de julio de 2026. Estas exenciones y estos topes son propios de Let's Encrypt y no se generalizan a las demás autoridades de certificación.

5

Fallos de autorización por identificador, por cuenta y por hora

Recarga de un fallo cada 12 minutos, sin posibilidad de ampliación, aplicable a las renovaciones.

5

Certificados por conjunto exacto de identificadores cada 7 días

Recarga de un certificado cada 34 horas, sin posibilidad de ampliación.

50

Certificados nuevos por dominio registrado cada 7 días

Caudal de entrada de nombres nuevos, recarga de un certificado cada 202 minutos. Las renovaciones están exentas.

1152

Fallos consecutivos antes de poner el identificador en pausa

Contador de racha que se pone a cero en cuanto una validación funciona, con salida a través del portal de autoservicio.

La guía de integración del proveedor añade dos consejos de explotación: por encima de 10 000 nombres, renovar en lotes pequeños en lugar de en paquetes grandes, y escalonar de una vez por todas las fechas de renovación. El formulario de ampliación de cuota solo afecta a dos límites, tarda unas semanas en tramitarse y nunca pone un contador a cero: es una herramienta de planificación, no un recurso de urgencia.

Todo lo anterior describe la política de Let's Encrypt, y nada más. En AWS Certificate Manager, la cifra estructurante no es un número de certificados sino un caudal, FinalizeOrder limitado a una petición por segundo, y esas cuotas están documentadas en la guía de usuario.

El verdadero modo de fallo: dos escenarios, y ninguno es una cuota

Los incidentes de renovación que vemos no se parecen a una cuota de emisión superada. Se parecen a estos dos escenarios, que comparten una característica desagradable: se agravan solos.

Escenario 1, el bucle de fallo. Unas credenciales DNS caducan, una delegación se rompe, el puerto 80 se cierra tras un cambio de regla de red. El cliente ACME reintenta, a menudo de forma agresiva porque es el ajuste por defecto de muchas configuraciones. Al sexto fallo dentro de la hora sobre el mismo identificador, cualquier comando que lleve ese nombre se rechaza, y la recarga baja a un fallo cada 12 minutos. Un incidente reparable en diez minutos se convierte en una caída de varias horas, no por culpa del problema de origen, sino por culpa del comportamiento del cliente ante el problema. Y mientras tanto el contador de fallos consecutivos sube hacia los 1152 del segundo límite. La respuesta cabe en dos ajustes: un backoff exponencial del lado del cliente, y una alerta sobre el fallo de validación en lugar de solo sobre la proximidad de la caducidad.

Escenario 2, la renovación que deja de serlo. Sin ARI, añadir o quitar un solo nombre de un certificado SAN le hace perder su condición de renovación y devuelve el comando a la cuota de los nombres nuevos. Y muchos parques generan sus conjuntos de SAN a partir de un inventario dinámico: controlador de ingress de Kubernetes, entornos efímeros, plataformas de previsualización. Ya ningún comando es una renovación, y un parque perfectamente estable consume el caudal reservado a los nombres nuevos.

Lo que hace real este segundo escenario es el estado de los clientes a 21 de julio de 2026. Certbot lee ARI pero no envía el campo replaces: su implementación sigue siendo de solo lectura, así que todos sus comandos se apoyan en la detección por conjunto exacto. lego envía replaces desde la v4.16.0 pero, desde la v5.1.0, ignora ARI si los SAN han cambiado. cert-manager sabe enviarlo, detrás del feature gate ACMEUseARI, clasificado como Alpha y desactivado por defecto, disponible desde la v1.21.0 publicada el 8 de julio de 2026. acme.sh lo envía desde la versión 3.1.4, publicada el 17 de julio de 2026, es decir, cuatro días antes de que verificáramos este punto. La protección existe en la norma desde junio de 2025. No es efectiva casi en ninguna parte.

Supervisión de la caducidad de los certificados SSL: dos cosas que vigilar, no una

La supervisión de la caducidad y la del fallo de renovación son dos sistemas distintos. El primero ve la consecuencia, con semanas de retraso. El segundo ve la causa, el mismo día. Un parque correctamente equipado tiene los dos, y no dependen del mismo componente.

Umbrales que no sobreviven a los certificados cortos

Un umbral de alerta fijado en 30 días se vuelve absurdo sobre un certificado de 47 días. Salta ya en el día 17 de vida del certificado, es decir, durante más de la mitad de su existencia. La alerta es permanente, por tanto invisible, por tanto inútil. El umbral debe volverse relativo a la vida útil: una fracción, no una constante.

Más vale aplicar esa exigencia a nuestras propias herramientas. El SSL Certificate Checker de CaptainDNS usa un umbral de «caduca pronto» fijado en 30 días, y los escalones de alerta de la nota de postura son D-30, D-14, D-7, D-3 y D-1. Un umbral relativo del tipo max(15, vida útil / 3) está previsto en la especificación interna, pero no está implementado. En un parque con perfil corto, esos valores tendrás que recalcularlos tú.

Lo que debe disparar una alerta además de la caducidad

Además de la fecha de caducidad, hay seis señales que merecen una alerta. La última de la lista es la más útil de todas.

• Un cambio de número de serie señala una renovación efectiva, o sea, una buena noticia que aun así conviene ver pasar.
• Un cambio de emisor puede delatar un cambio de autoridad no previsto.
• Una cadena que ha quedado incompleta rompe la validación solo en una parte de los clientes, lo que la hace difícil de reproducir.
• Un nombre de host que ya no coincide aparece después de una migración.
• Un protocolo o una clave que se han vuelto débiles indican una configuración que ha retrocedido.
• Y sobre todo, el fallo de validación ACME: la única señal que llega lo bastante pronto para evitar la caída.

Al contrario, hay dos reflejos que solo producen ruido. No alertar nunca sobre un NXDOMAIN de _acme-challenge, por la razón expuesta más arriba. Y no alertar sobre un simple cambio de huella sin cambio de estado visible, so pena de cosechar falsos positivos en cada conmutación de frontal.

Nuestros límites, dichos con franqueza, porque cambian la forma en que hay que leer los párrafos anteriores. La nota de postura es un opt-in de pago por monitor. Su cadencia por defecto es de 86 400 segundos, es decir, una pasada al día: hablar de «supervisión continua» sería falso. No hay descubrimiento de parque, ninguna enumeración a través de los registros de transparencia: supervisas lo que declaras, una URL cada vez. Y no hay STARTTLS, así que nada sobre tus servidores de correo.

¿A partir de cuándo hay que pagar por una herramienta?

El umbral de compra no se cuenta en certificados. Se cuenta en endpoints que ningún script sabe recargar. Un parque de 800 certificados íntegramente pilotados por un controlador de ingress no justifica ningún gasto; un parque de 60 certificados de los que 25 viven en appliances con interfaz web lo justifica de inmediato.

Clasifica tu parque en tres columnas y luego cuenta la tercera.

Clase	Lo que hace el script	Lo que sigue siendo humano
Automatizable de principio a fin	Emisión, instalación, recarga, verificación del número de serie servido	Nada en régimen nominal
Semiautomatizable	Emisión y depósito del fichero	Instalación o recarga manual, a menudo una consola
No automatizable	Solo la emisión	Conexión a una interfaz web, importación del fichero, reinicio

El punto de inflexión se lee en la tercera fila, multiplicada por la frecuencia venidera. Un endpoint no automatizable cuesta, en régimen de 47 días, ocho intervenciones al año como mínimo estricto, el de una renovación al vencimiento, y once o doce renovando a los dos tercios como se recomienda; la guía del ciclo de vida modela algo menos de ocho con otra hipótesis de calendario, sin que el orden de magnitud se mueva. Frente a dos hoy. Haz el producto con tus minutos medidos, no estimados, y compáralo con el precio de una licencia: el cálculo no exige ni benchmark ni concurso.

El modelo de umbral que se ofrece al final del artículo hace modificables esas hipótesis una a una: número de endpoints no recargables, cadencia de rotación por escalón de validez, minutos por rotación, coste horario cargado y precio de referencia. Cada valor precargado lleva ahí su estado, documentado, derivado o comprobado en una fecha, de modo que sustituir nuestras hipótesis por las tuyas lleva un minuto.

Precisamente, los precios. En AWS Marketplace, comprobación del 21 de julio de 2026, la ficha de AppViewX AVX ONE CLM muestra dos escalones públicos con contrato de un mes: 2100 $ al mes por 100 certificados de servidor y 4200 $ al mes por 250 certificados de servidor. El mismo fabricante publica 5000 $ y 9100 $ al mes en su ficha de PKIaaS, lo que impide presentar los 2100 $ como «el» precio público del fabricante. La ficha de Venafi Certificate Management Service no lleva ningún precio y remite a una oferta privada bajo presupuesto. La ficha de DigiCert muestra un importe de 5000 $ para un contrato de doce meses, precisando a la vez que está reservada a las compras mediante oferta privada. Esta comprobación se refiere a las fichas consultadas ese día, en un único marketplace, y a la noción de precio suscribible públicamente. No dice nada de las tarifas negociadas, ni de los fabricantes ausentes de esa comprobación.

Una palabra sobre el mercado, formulada como constatación de ausencia. En gartner.com no aparece referenciado ningún Magic Quadrant dedicado a la gestión del ciclo de vida de los certificados: la consultora trata el tema mediante una «Buyers' Guide for PKI and Certificate Life Cycle Management» publicada el 29 de mayo de 2025 y mediante un espacio de opiniones de usuarios, Peer Insights. En cuanto a las cifras que circulan en los argumentarios, son atribuibles y nada más: en un comunicado del 2 de julio de 2025, DigiCert indica que el 45 % de quienes respondieron a su encuesta «Trust Pulse» declaran haber sufrido una interrupción de servicio ligada a un incidente de certificado, y que el 31 % informan de pérdidas de entre 50 000 y 250 000 dólares. El comunicado no precisa ni el número de encuestados, ni su perfil, ni los países cubiertos, ni el periodo de recogida, y no hemos encontrado ningún informe que detalle esa metodología a esta fecha. Son declaraciones de personas encuestadas en un estudio encargado por un actor de la categoría, no una medición.

Quédate con el gesto, no con las cifras: cuenta la tercera columna, multiplica por tus minutos, compara.

🎯 Plan de acción: la secuencia que hay que desplegar

Ocho acciones, en este orden. Las tres primeras se hacen una vez; las siguientes se convierten en reflejos de explotación.

1. Inventariar por par (host, puerto), cruzando los registros de transparencia, el disco y los almacenes, y luego el escaneo de red. Lanza ese escaneo desde una red que no filtre los puertos salientes, o tus servidores de correo no aparecerán nunca.
2. Tratar «host no alcanzado» como un fallo del inventario, con una línea explícita en el informe. Un inalcanzable silencioso contado como un éxito es lo que vuelve falso un panel.
3. Delegar _acme-challenge mediante CNAME, y luego verificar la delegación en tres pasos: el CNAME existe, la cadena se resuelve, la zona de destino responde en SOA. Y no alertar sobre los NXDOMAIN fuera del periodo de renovación.
4. Verificar después de cada renovación que el número de serie servido es el del disco, incluso fuera del 443. Es el control que atrapa la recarga olvidada, y cuesta dos líneas de script.
5. Poner un backoff exponencial en el cliente y alertar sobre el fallo de validación. Sin eso, un incidente de diez minutos se convierte en un bloqueo de una hora.
6. Verificar que tu cliente envía replaces, o aceptar que dependes de la detección por conjunto exacto, lo que equivale a congelar tus SAN.
7. Pasar los umbrales de alerta de un valor fijo a una fracción de la vida útil. Treinta días no significan nada en un certificado de 47 días.
8. Contar tus endpoints no recargables antes de comparar herramientas. Ese número decide la compra; el número de certificados, no.

Ocho acciones, dos ficheros que descargar y una sola cifra que producir: el número de endpoints que nadie sabe recargar. Es esa cifra la que decide lo que sigue, no el tamaño del parque.

FAQ

¿Es posible renovar automáticamente un certificado SSL?

Sí, y es el modo nominal con ACME desde hace años. La verdadera pregunta se refiere a la cadena completa: emisión, instalación, recarga del servicio y verificación. La extensión ARI permite además seguir la ventana sugerida por la autoridad, pero su soporte del lado cliente sigue siendo desigual a 21 de julio de 2026. Certbot la lee sin enviar el campo replaces, cert-manager la mantiene detrás de un feature gate desactivado por defecto, acme.sh la cableó en la versión 3.1.4 el 17 de julio de 2026.

¿Cómo automatizar la renovación de los certificados SSL?

Bastan tres piezas. Un cliente ACME planificado, que obtiene el certificado. Una delegación _acme-challenge mediante CNAME hacia una zona de validación dedicada, lo que evita confiar las llaves de tu zona de producción al servidor que renueva. Y un control que compare el número de serie leído en el disco con el que realmente se sirve en el puerto correspondiente. La tercera pieza es la que se olvida, y es la que detecta la recarga que falta.

¿Cómo renovar un certificado SSL?

Una renovación no es una prórroga: es una reemisión completa, con una nueva validación de control del dominio si la ventana de reutilización ha caducado. En Let's Encrypt, un comando se reconoce como renovación de dos maneras: designa el certificado al que sustituye mediante ARI, o lleva exactamente el mismo conjunto de identificadores que el certificado saliente. En ambos casos escapa a los límites de emisión para nombres nuevos.

¿Cómo verificar que una renovación ha surtido efecto de verdad?

Deja que el cliente ACME haga la emisión, y luego verifica el resultado por la red en lugar de por los registros del cliente. El comando útil compara openssl x509 -in fullchain.pem -noout -serial con el número de serie devuelto por openssl s_client sobre el servicio. Si los dos difieren, el certificado está renovado en el disco pero el servicio sigue sirviendo el antiguo: falta una recarga.

¿Qué hago si mi certificado SSL caduca?

En un servicio web, la caducidad se ve de inmediato: los navegadores bloquean. En un servidor de correo protegido por DANE es más taimado. La RFC 7672 prohíbe la entrega a través de un servidor cuya autenticación falla, y el emisor pasa al MX siguiente o difiere la entrega: por tu lado, ninguna alerta. Empieza, pues, el diagnóstico leyendo el certificado realmente servido en el puerto correspondiente, no por tus registros de aplicación.

¿Cuántos certificados de Let's Encrypt puedo renovar por semana?

La pregunta parte de una idea falsa, la más extendida del tema. Las renovaciones están exentas del límite de 50 certificados por dominio registrado y por periodo de 7 días: ese límite mide la entrada de nombres nuevos. Una renovación pilotada por ARI escapa incluso a todos los límites. Sin ARI, la única restricción que muerde es el tope de 5 certificados por conjunto exacto de identificadores cada 7 días.

¿Cómo inventariar un parque de certificados?

Cruzando cuatro fuentes, ninguna de las cuales es completa. Los registros de transparencia listan lo que se ha emitido públicamente pero ignoran tu PKI interna. El disco y los almacenes (PEM, keystores Java, almacén de Windows) listan lo que está instalado, no lo que se sirve. El escaneo de red lee lo que se presenta efectivamente, pero se pierde todo lo que filtra tu cortafuegos de salida, empezando por el puerto 25. Las API de tus proveedores cubren las terminaciones TLS gestionadas. Indexa el resultado por el par (host, puerto).

¿Cómo delegar _acme-challenge mediante CNAME sin entregar las llaves de la zona?

Crea un CNAME de _acme-challenge.captaindns.com hacia un nombre alojado en una zona de validación dedicada, y luego dale al cliente ACME credenciales que solo escriban en esa zona. Verifica en tres pasos: el CNAME está presente, la resolución del TXT devuelve un estado coherente, la zona de destino responde en SOA. Un NXDOMAIN fuera del periodo de renovación es normal. El borrador draft-ietf-acme-dns-account-label-03 prevé levantar el límite de un solo delegado por dominio, pero todavía no es una norma.

¿A partir de cuántos endpoints hay que comprar una herramienta?

No hay un umbral universal, y menos aún un umbral expresado en número de certificados. Cuenta los endpoints que ningún script sabe recargar, multiplica por el número de rotaciones anuales venideras (ocho como mínimo estricto en régimen de 47 días, once o doce renovando a los dos tercios) y por los minutos empleados en cada una. Compara el total con el coste de una licencia: en AWS Marketplace, en la última comprobación, la ficha de AppViewX AVX ONE CLM muestra 2100 $ al mes por 100 certificados de servidor. Escribe las hipótesis de tu cálculo, cuentan tanto como el resultado.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

• Descargar el modelo de umbral parametrizable (CSV)
• Descargar el modelo de umbral parametrizable (JSON)

Descarga la checklist de despliegue

Los asistentes pueden reutilizar la checklist con los exports JSON o CSV de abajo.

• Descargar la tabla de auditoría del parque (CSV)
• Descargar la tabla de auditoría del parque (JSON)

📖 Glosario

• ARI (ACME Renewal Information): extensión de ACME normalizada por la RFC 9773, con estatus de Proposed Standard. Es una extensión, no una revisión de ACME: no deja obsoleta ni actualiza la RFC 8555.
• DCV (Domain Control Validation): prueba de que el solicitante controla el dominio. Su reutilización está limitada a 200 días desde marzo de 2026, 100 días en 2027 y 10 días en 2029: es ese contador, y no la validez, el que baja a 10 días.
• Conjunto exacto de identificadores: conjunto estrictamente idéntico de nombres cubiertos por un certificado. En Let's Encrypt sirve para reconocer una renovación sin ARI; las mayúsculas y el orden no tienen ningún efecto, pero añadir un solo nombre hace perder la condición de renovación.
• Dominio registrado: la parte del dominio comprada a un registrador, identificada mediante la Public Suffix List. Todos los subdominios comparten la misma cuota. Let's Encrypt nunca emplea el término «eTLD+1».
• Perfil shortlived: perfil de emisión de Let's Encrypt con 160 horas de validez y 25 nombres como máximo, en disponibilidad general desde el 15 de enero de 2026. Sigue siendo opcional, y sus certificados todavía contienen hoy una URL de lista de revocación.
• Endpoint no recargable: punto de acceso en el que un certificado se emite automáticamente pero se instala a mano, por falta de API o de acceso no interactivo. Es la unidad de cuenta del umbral de compra.

---

Un último control antes de irte. El gesto que atraviesa este playbook, comparar el certificado realmente servido con el que uno cree haber desplegado, tiene un terreno donde no tolera ninguna aproximación: si tus MX publican registros TLSA, la rotación se verifica antes del despliegue, nunca después. El DANE/TLSA Checker resuelve tus registros, valida la cadena DNSSEC y puede, opcionalmente, confrontar el certificado presentado por el servidor SMTP con lo que anuncia tu DNS.

---

📚 Guías de certificados y DNS relacionadas

• Ballot SC-085v2: las autoridades verifican DNSSEC antes de emitir: lo que las autoridades controlan en tu DNS antes de cada validación.
• DANE y TLSA: la guía completa: publicar y rotar los registros TLSA al ritmo de las renovaciones.
• HSTS y preload: la guía completa: por qué el margen de maniobra es nulo cuando a un sitio con HSTS le caduca el certificado.

Fuentes

1. Let's Encrypt: Rate Limits
2. Let's Encrypt: Certificate Profiles
3. Let's Encrypt: Integration Guide
4. CA/Browser Forum: Baseline Requirements for TLS Server Certificates
5. draft-ietf-acme-dns-account-label: ACME DNS Labeled With ACME Account ID Challenge