HTTP-01 frente a DNS-01: qué desafío ACME elegir

HTTP-01 frente a DNS-01 es la primera decisión al automatizar certificados con ACME (RFC 8555). Con HTTP-01, la autoridad de certificación descarga un token de tu servidor web por el puerto 80; con DNS-01, consulta un registro TXT de tu zona. Ambos son métodos de validación de dominio según los Baseline Requirements y ambos dan certificados idénticos, pero difieren en lo que pueden validar, en dónde pueden ejecutarse y en lo que puede fallar.

De un vistazo

Qué comprueba realmente la CA

Ambos desafíos usan una autorización de clave (key authorization): el token del desafío unido con un punto a la huella JWK (JWK thumbprint, RFC 7638) de la clave de tu cuenta ACME. Como la clave de la cuenta forma parte de la prueba, alguien que vea el token no puede completar el desafío para su propia cuenta. HTTP-01 sirve la autorización de clave tal cual; DNS-01 publica su resumen SHA-256, que cabe en un registro TXT. El script siguiente reproduce ambos valores para la clave de cuenta de ejemplo del RFC 7638 y los tokens de ejemplo del RFC 8555 (Node.js 26).

import { createHash } from "node:crypto";

// Account public key: the RSA example JWK from RFC 7638 §3.1
const accountJwk = {
  kty: "RSA",
  e: "AQAB",
  n: "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
};

const b64url = (buf) => buf.toString("base64url");
const sha256 = (s) => createHash("sha256").update(s).digest();

// RFC 7638: hash the required members in lexicographic order
const { e, kty, n } = accountJwk;
const thumbprint = b64url(sha256(JSON.stringify({ e, kty, n })));
console.log("account key thumbprint:", thumbprint);

// http-01 (RFC 8555 §8.3): serve the key authorization itself
const httpToken = "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0";
console.log("\nhttp-01");
console.log(`  GET http://www.example.org/.well-known/acme-challenge/${httpToken}`);
console.log(`  body: ${httpToken}.${thumbprint}`);

// dns-01 (RFC 8555 §8.4): publish base64url(SHA-256(key authorization))
const dnsToken = "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA";
const txt = b64url(sha256(`${dnsToken}.${thumbprint}`));
console.log("\ndns-01");
console.log(`  _acme-challenge.www.example.org. 300 IN TXT "${txt}"`);

account key thumbprint: NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

http-01
  GET http://www.example.org/.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0
  body: LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

dns-01
  _acme-challenge.www.example.org. 300 IN TXT "ZTRx1Ckl1-tM05o5zaizTTA0yUy5AGereMgSNWC6Ll8"

La huella coincide con el valor publicado en el RFC 7638 §3.1, lo que confirma el cálculo. Los clientes hacen todo esto por ti; conocer los valores ayuda cuando depuras a mano con curl o dig un desafío que falla.

Comprobaciones desde varias perspectivas y DNSSEC

Desde 2025, las CA públicas deben confirmar cada validación desde varias ubicaciones de red (Baseline Requirements §3.2.2.9). Desde el 15 de junio de 2026 participan al menos cuatro perspectivas remotas, separadas entre sí al menos 500 km y situadas en las regiones de al menos dos registros regionales de internet, y solo una puede discrepar; el mínimo sube a cinco el 15 de diciembre de 2026. En HTTP-01, esto significa que cada nodo anycast, cada respuesta de GeoDNS y cada dirección IPv4 o IPv6 del nombre debe servir el token. En DNS-01, todos los servidores de nombres autoritativos deben tener ya el registro cuando pidas a la CA que valide.

Desde el 15 de marzo de 2026, las CA también deben validar DNSSEC en las consultas de validación de dominio y de CAA (votación SC-085v2). Las zonas sin firmar no se ven afectadas, pero una zona firmada con una firma caducada o un registro DS roto ahora bloquea la emisión con ambos tipos de desafío; el inspector de DNSSEC muestra la cadena que comprobará la CA.

Cómo acotar las credenciales de DNS

El principal riesgo de DNS-01 es la credencial que exige: un token de la API de DNS en un servidor web a menudo puede reescribir toda la zona. Como las CA consultan el registro TXT mediante la resolución DNS normal, que sigue las delegaciones CNAME y NS, el nombre _acme-challenge puede apuntar a una zona separada en la que el servidor tenga permiso de escritura, y en nada más:

_acme-challenge.example.com.  3600  IN  CNAME  example-com.acme.example.net.

Así, herramientas como acme-dns, o los tokens del proveedor limitados a un registro o a una zona, restringen lo que puede hacer una credencial robada. Combina esto con registros CAA que usen los parámetros del RFC 8657, que las CA deben procesar a partir del 15 de marzo de 2027:

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

Con validationmethods configurado, un atacante que controle brevemente el puerto 80 o una ruta web de tu servidor ya no puede obtener un certificado mediante HTTP-01. El generador de registros CAA escribe estos registros.

TLS-ALPN-01 y registros DNS persistentes

TLS-ALPN-01 (RFC 8737) valida en el puerto 443 dentro del handshake TLS, con el protocolo acme-tls/1 y un certificado autofirmado que lleva el resumen de la autorización de clave. Es adecuado para proxies y balanceadores de carga que terminan TLS y tienen el puerto 80 cerrado; como HTTP-01, puede validar direcciones IP, pero no comodines.

DNS-PERSIST-01 elimina el cambio en el DNS en cada renovación. La votación SC-088v3 (octubre de 2025) añadió «DNS TXT Record with Persistent Value» (registro TXT de DNS con valor persistente) como §3.2.2.4.22 de los Baseline Requirements: un único registro TXT de larga duración en _validation-persist.name indica la CA y el URI de tu cuenta ACME, opcionalmente con policy=wildcard. El desafío ACME sigue siendo un borrador del IETF. Google Trust Services admite el borrador 01 desde el 28 de septiembre de 2026; Let's Encrypt solo lo ofrece en su entorno de staging y, a octubre de 2026, aplaza su paso a producción hasta que se resuelva una cuestión abierta del borrador. La contrapartida es que la clave de la cuenta se convierte en una autorización permanente, así que protégela como una credencial de DNS.

La validación pronto se hará en cada renovación

La reutilización de autorizaciones se reduce junto con la vida útil de los certificados. Los Baseline Requirements limitan la reutilización de la validación de dominio a 200 días ahora, a 100 días desde marzo de 2027 y a 10 días desde marzo de 2029. El perfil predeterminado de Let's Encrypt reutiliza las autorizaciones durante 30 días hoy, 10 días a partir del 10 de febrero de 2027 y 7 horas a partir del 16 de febrero de 2028. Elijas el desafío que elijas, debe ejecutarse sin intervención; copiar valores TXT a mano dejará de ser viable en 2028.

Cuándo elegir cada uno

• Un servidor web público con el cliente ACME instalado en él: HTTP-01.
• Certificados comodín: DNS-01 (o DNS-PERSIST-01 si tu CA lo ofrece).
• Hosts internos con nombres públicos, servicios accesibles solo por VPN, entornos de desarrollo: DNS-01; recuerda que los nombres aparecerán en los registros CT.
• Flotas con balanceo de carga, despliegues multirregión o anycast: DNS-01, o HTTP-01 si cada nodo reenvía /.well-known/acme-challenge/ por proxy a un único servidor de respuesta.
• CDN y plataformas gestionadas: deja que valide la plataforma (normalmente con HTTP-01 a través de su red perimetral o con un CNAME que añades una sola vez).
• Certificados para direcciones IP: HTTP-01 o TLS-ALPN-01; en Let's Encrypt, solo con el perfil shortlived de seis días.
• Puerto 80 cerrado por política: DNS-01 o TLS-ALPN-01.

Notas de migración

1. Paso de HTTP-01 a DNS-01: crea una zona dedicada a los desafíos, apunta cada nombre _acme-challenge a ella con un CNAME, da al cliente ACME un token limitado a esa zona y cambia el tipo de desafío del cliente; los certificados existentes siguen funcionando.
2. Comprueba la propagación antes de responder al desafío: la mayoría de los clientes pueden esperar hasta que todos los servidores autoritativos devuelvan el registro; activa esa opción en lugar de una espera fija.
3. Haz limpieza: los clientes deberían eliminar los registros TXT después de la validación (RFC 8555 §8.4); los restos se acumulan y ralentizan las consultas.
4. Restringe la emisión con CAA mediante accounturi y validationmethods, tanto para issue como para issuewild.
5. Renueva según el calendario de la CA: usa ACME Renewal Information (ARI, RFC 9773) donde se admita y, si no, renueva hacia los dos tercios de la vida útil; la calculadora de vida útil de certificados muestra los límites por fecha.
6. Vigila la emisión en los registros de Certificate Transparency (Certificate Transparency para desarrolladores) para que los certificados obtenidos por cualquier método sean visibles.

Referencias

• RFC 8555 §8, desafíos de validación de identificadores en ACME
• RFC 8737, TLS-ALPN-01 y RFC 8738, identificadores IP en ACME
• RFC 8657, accounturi y validationmethods en CAA
• RFC 7638 §3.1, ejemplo de huella JWK
• RFC 9773, ACME Renewal Information
• Baseline Requirements del CA/Browser Forum, §3.2.2.4, §3.2.2.9, §4.2.2
• Votación SC-085v2, validación de DNSSEC en las consultas de CAA y DCV
• Let's Encrypt: tipos de desafío
• Let's Encrypt: DNS-PERSIST-01
• Let's Encrypt: reducción de la vida útil de los certificados a 45 días