HTTP, HTTPS y TLS: Parte 11 — Certificados Let's Encrypt: ACME, verificación de dominio, CAA y Certificate Transparency

Let’s Encrypt — una autoridad de certificación (CA) gratuita que emite certificados DV automáticamente, sin solicitudes ni pago. La emisión y la renovación se realizan mediante el protocolo ACME (Automatic Certificate Management Environment, RFC 8555): un programa en el servidor demuestra que controla el dominio, obtiene el certificado y lo coloca en el servidor web. Por el mismo protocolo funcionan ZeroSSL, Google Trust Services, Buypass y otras CAs; en qué se diferencian de Let’s Encrypt — en el artículo «Más allá de Let’s Encrypt». Los periodos de validez de los certificados se están acortando, y en los próximos años la emisión manual será prácticamente imposible, por lo que conviene configurar esta parte correctamente de una vez.

Cómo funciona ACME

1. Cuenta. El cliente crea una cuenta en la CA — un par de claves con el que firma todas las solicitudes posteriores. El correo electrónico es opcional; desde junio de 2025 Let’s Encrypt ya no envía recordatorios de expiración, así que habrá que vigilar las fechas por cuenta propia.
2. Pedido (order). El cliente enumera los nombres para el certificado: example.ru, www.example.ru.
3. Comprobaciones (challenges). Para cada nombre la CA emite una tarea que solo puede realizar el propietario del dominio o del servidor.
4. Ejecución de la comprobación. El cliente coloca la respuesta, la CA la verifica desde varios puntos de Internet.
5. Emisión. El cliente envía una solicitud de firma (CSR) con su clave pública y descarga el certificado junto con el intermedio.

Una comprobación exitosa se considera válida durante un tiempo para reutilización (authorization reuse) — ahora hasta 30 días; para 2028 Let’s Encrypt reducirá ese periodo a 7 horas.

Tres métodos de verificación

HTTP-01. El cliente coloca un archivo con el token en http://example.ru/.well-known/acme-challenge/<token>, la CA lo descarga.

• se necesita el puerto 80 abierto — no se puede usar otro puerto; la CA sigue redirecciones a HTTPS;
• el dominio debe apuntar a ese servidor;
• no sirve para certificados wildcard;
• si hay varios servidores detrás de un balanceador, el archivo debe estar disponible en todos (o la solicitud de comprobación debe llegar al que ejecuta el cliente).

DNS-01. El cliente crea un registro TXT _acme-challenge.example.ru con el token. Una guía paso a paso para Cloudflare y Route 53 — en el artículo «Certificados SSL mediante DNS».

• único modo para obtener un wildcard *.example.ru;
• no se necesita puerto abierto ni acceso al servidor desde fuera — sirve para servicios internos con dominio público;
• el cliente necesita acceso a la API del proveedor DNS. Para no darle la clave de toda la zona, delegue la comprobación: _acme-challenge.example.ru CNAME _acme-challenge.acme-zone.example.net — y entregue la clave solo para la zona auxiliar (así funcionan, por ejemplo, acme-dns);
• tras crear el registro hay que esperar a que lo vean todos los servidores DNS autorizados de la zona.

Let’s Encrypt está preparando el método DNS-PERSIST-01, en el que la entrada TXT se crea una vez y no cambia en cada renovación.

TLS-ALPN-01. Comprobación en el puerto 443: la CA se conecta con ALPN acme-tls/1, y el servidor responde con un certificado temporal especial. Útil cuando el puerto 80 está cerrado. Se usa principalmente en clientes integrados — Caddy, Traefik, lego; no funciona con certbot y Nginx estándar.

Clientes ACME

certbot — cliente de EFF, está en los paquetes de la mayoría de distribuciones.

# emisión con configuración automática de Nginx
certbot --nginx -d example.ru -d www.example.ru

# solo emisión, el archivo de comprobación se coloca en el directorio del sitio
certbot certonly --webroot -w /var/www/letsencrypt -d example.ru -d www.example.ru \
  --deploy-hook 'systemctl reload nginx'

# wildcard vía API DNS (se necesita un plugin, por ejemplo python3-certbot-dns-cloudflare)
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.cf.ini \
  -d example.ru -d '*.example.ru'

# comprobar la renovación sin emitir
certbot renew --dry-run

El paquete certbot instala un temporizador systemd o una tarea cron que llama certbot renew dos veces al día. Los certificados están en /etc/letsencrypt/live/<nombre>/: fullchain.pem — certificado con el intermedio (se especifica en Nginx), privkey.pem — clave. --deploy-hook se ejecuta solo tras una renovación exitosa y recarga el servidor web; sin él Nginx seguirá sirviendo el certificado antiguo.

acme.sh — cliente en shell sin dependencias, soporta más de cien proveedores DNS.

# por defecto acme.sh usa ZeroSSL
acme.sh --set-default-ca --server letsencrypt
acme.sh --issue --dns dns_cf -d example.ru -d '*.example.ru'
acme.sh --install-cert -d example.ru \
  --fullchain-file /etc/nginx/ssl/example.ru.crt \
  --key-file /etc/nginx/ssl/example.ru.key \
  --reloadcmd 'systemctl reload nginx'

ACME integrado. Caddy y Traefik emiten y renuevan certificados por sí mismos para cada sitio en la configuración. Nginx tiene desde 2025 un módulo dinámico oficial ngx_http_acme_module (paquete nginx-module-acme). Si el servidor web soporta ACME internamente, no hace falta un cliente separado.

Kubernetes — cert-manager: los certificados se describen como recursos, la emisión y la renovación ocurren dentro del clúster.

Plazos de validez y perfiles

Los certificados de Let’s Encrypt tradicionalmente duran 90 días. El proyecto está pasando a plazos más cortos mediante perfiles ACME — el cliente elige el perfil al pedir el certificado:

• classic — perfil por defecto: 90 días; desde el 10 de febrero de 2027 — 64 días, desde el 16 de febrero de 2028 — 45 días;
• tlsserver — desde el 13 de mayo de 2026 emite certificados de 45 días, para quienes quieran migrar antes;
• shortlived — alrededor de 6 días. Estos certificados se pueden emitir incluso para direcciones IP.

Esto coincide con la decisión general del CA/Browser Forum: la duración máxima de cualquier certificado público será 200 días desde marzo de 2026, 100 días desde marzo de 2027, 47 días desde marzo de 2029.

Qué se deduce de esto:

• renueve aproximadamente al dos tercios del periodo, no “30 días antes del final”: en un certificado de 45 días, 30 días es casi todo el periodo;
• use un cliente con soporte ARI (ACME Renewal Information, RFC 9773): la CA indica cuándo renovar, por ejemplo en una revocación masiva. Las renovaciones mediante ARI no consumen los límites;
• cualquier paso manual — copiar el certificado a otro servidor, subirlo en un panel, actualizarlo en un router — debe automatizarse o eliminarse.

Límites de Let’s Encrypt

Los más notables:

• 50 certificados por dominio registrado en 7 días — para example.ru junto con todos sus subdominios;
• 5 certificados para el mismo conjunto de nombres en 7 días — normalmente se agota cuando un script o contenedor emite un certificado en cada arranque en lugar de usar el guardado;
• 5 comprobaciones fallidas por hora para un mismo nombre por cuenta;
• 300 nuevos pedidos en 3 horas por cuenta.

Para depuración use el servidor de pruebas (staging, en certbot — la opción --staging o --test-cert): los límites ahí son mucho mayores y los certificados no son de confianza. Las renovaciones con el mismo conjunto de nombres no cuentan para el límite de 50 certificados por dominio.

Registros CAA

CAA (Certification Authority Authorization, RFC 8659) — registro DNS que enumera las autoridades de certificación autorizadas a emitir certificados para el dominio. Las CAs deben comprobarlo antes de emitir. Si no hay registro, cualquiera puede emitir.

example.ru.  3600  IN  CAA  0 issue "letsencrypt.org"
example.ru.  3600  IN  CAA  0 issuewild ";"
example.ru.  3600  IN  CAA  0 iodef "mailto:security@example.ru"

• issue — quién puede emitir certificados normales;
• issuewild — quién puede emitir wildcard; ";" — nadie;
• iodef — dónde comunicar intentos de emisión en violación de las reglas (las CAs no siempre lo soportan).

Puede limitarse no solo la CA, sino también la cuenta y el método de validación (RFC 8657):

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

El registro se aplica también a subdominios mientras el subdominio no tenga el suyo propio. Si el sitio está detrás de una CDN que emite certificados (Cloudflare, por ejemplo, usa Let’s Encrypt y Google Trust Services), no olvide añadir sus CAs, de lo contrario la CDN no podrá renovar el certificado. Comprobación: dig CAA example.ru.

Certificate Transparency

Certificate Transparency (CT) — sistema de registros públicos en los que las CAs anotan cada certificado público emitido. Chrome desde 2018, seguido por Safari y Firefox aceptan un certificado solo si contiene las pruebas de inclusión en los registros (SCT). Emitir un certificado de confianza en secreto es imposible.

Por qué interesa al propietario del dominio:

• detectar emisiones ajenas. Si alguien obtiene un certificado para su dominio — por un secuestro de DNS, un error de la CA o un excontratista — aparecerá en el registro;
• saber qué nombres son públicos. Cada certificado revela todos los nombres del SAN. Se emite un certificado para grafana.example.ru o test-crm.example.ru — ese nombre lo ven en minutos todos, incluidos los escáneres que monitorizan CT y revisan nuevos hosts en busca de vulnerabilidades.

Búsqueda en los registros — servicio crt.sh:

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

%25 — es el carácter % codificado, patrón “cualquier subdominio”. Notificaciones sobre nuevos certificados para su dominio las ofrecen servicios gratuitos de monitorización CT, por ejemplo Cert Spotter.

Cómo no revelar nombres internos:

• para servicios internos emita un wildcard *.example.ru — en el registro aparecerá solo el patrón, no cada nombre;
• o use una autoridad de certificación interna (step-ca): sus certificados no se escriben en los registros CT;
• no confíe en que “nadie conoce la dirección” — CT hace público cualquier nombre que esté en un certificado público.

Errores típicos

• cert.pem en lugar de fullchain.pem en Nginx — cadena incompleta.
• La renovación funciona, pero no hay --deploy-hook ni --reloadcmd — el servidor web sigue sirviendo el certificado viejo hasta reiniciarse.
• Emitir un certificado en cada arranque del contenedor — límite de 5 duplicados por semana, y el servicio se queda sin certificado.
• Puerto 80 cerrado “por seguridad” — deja de funcionar HTTP-01.
• CAA permite solo Let’s Encrypt, y la CDN emite certificados con otra CA — la renovación en la CDN falla silenciosamente.
• Monitoreo de fechas no configurado esperando correos de Let’s Encrypt, que ya no existen.