HTTP-01 vs DNS-01: qual desafio ACME escolher

HTTP-01 vs DNS-01 é a primeira decisão ao automatizar certificados com o ACME (RFC 8555). Com o HTTP-01, a autoridade certificadora busca um token no seu servidor web pela porta 80; com o DNS-01, ela consulta um registro TXT na sua zona. Os dois são métodos de validação de domínio previstos nos Baseline Requirements e os dois resultam em certificados idênticos, mas diferem no que conseguem validar, em onde podem ser executados e no que pode dar errado.

Visão geral

O que a CA realmente verifica

Os dois desafios usam uma autorização de chave (key authorization): o token do desafio unido por um ponto à impressão digital (thumbprint) da JWK (RFC 7638) da chave da sua conta ACME. Como a chave da conta faz parte da prova, alguém que veja o token não consegue concluir o desafio para a própria conta. O HTTP-01 serve a autorização de chave como ela é; o DNS-01 publica o hash SHA-256 dela, que cabe em um registro TXT. O script abaixo reproduz os dois valores para a chave de conta de exemplo da RFC 7638 e os tokens de exemplo da 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"

A impressão digital coincide com o valor publicado na RFC 7638 §3.1, o que confirma o cálculo. Os clientes fazem tudo isso por você; conhecer os valores ajuda quando você depura à mão, com curl ou dig, um desafio que está falhando.

Verificações de várias perspectivas e DNSSEC

Desde 2025, as CAs públicas devem confirmar cada validação a partir de vários pontos da rede (Baseline Requirements §3.2.2.9). Desde 15 de junho de 2026, participam pelo menos quatro perspectivas remotas, a pelo menos 500 km de distância entre si e nas áreas de atuação de pelo menos dois registros regionais de internet, e apenas uma delas pode discordar; o mínimo sobe para cinco em 15 de dezembro de 2026. Para o HTTP-01, isso significa que todo nó anycast, toda resposta de GeoDNS e todo endereço IPv4 ou IPv6 do nome precisa servir o token. Para o DNS-01, todo servidor de nomes autoritativo já precisa ter o registro quando você pede à CA que faça a validação.

Desde 15 de março de 2026, as CAs também devem validar o DNSSEC nas consultas de validação de domínio e de CAA (votação SC-085v2). Zonas não assinadas não são afetadas, mas uma zona assinada com uma assinatura expirada ou um registro DS quebrado agora bloqueia a emissão para os dois tipos de desafio; o inspetor de DNSSEC mostra a cadeia que a CA vai verificar.

Como manter as credenciais de DNS restritas

O principal risco do DNS-01 é a credencial que ele exige: um token de API de DNS em um servidor web muitas vezes consegue reescrever a zona inteira. Como as CAs consultam o registro TXT pela resolução DNS comum, que segue delegações por CNAME e NS, o nome _acme-challenge pode apontar para uma zona separada, a única que o servidor tem permissão para alterar:

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

Ferramentas como o acme-dns, ou tokens do provedor restritos a um registro ou a uma zona, limitam então o que uma credencial roubada pode fazer. Combine isso com registros CAA que usem os parâmetros da RFC 8657, que as CAs devem processar a partir de 15 de março 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"

Com validationmethods configurado, um atacante que controle por pouco tempo a porta 80 ou um caminho web no seu servidor não consegue mais obter um certificado pelo HTTP-01. O gerador de registros CAA escreve esses registros.

TLS-ALPN-01 e registros DNS persistentes

O TLS-ALPN-01 (RFC 8737) valida na porta 443, dentro do handshake TLS, usando o protocolo acme-tls/1 e um certificado autoassinado que contém o hash da autorização de chave. Ele é adequado para proxies e balanceadores de carga que terminam o TLS em ambientes com a porta 80 fechada; assim como o HTTP-01, pode validar endereços IP, mas não nomes curinga.

O DNS-PERSIST-01 elimina a mudança no DNS a cada renovação. A votação SC-088v3 (outubro de 2025) acrescentou “DNS TXT Record with Persistent Value” como Baseline Requirements §3.2.2.4.22: um único registro TXT de longa duração em _validation-persist.name indica a CA e o URI da sua conta ACME, opcionalmente com policy=wildcard. O desafio ACME ainda é um rascunho da IETF (Internet-Draft). O Google Trust Services oferece suporte à versão 01 do rascunho desde 28 de setembro de 2026; a Let’s Encrypt só o disponibilizou no ambiente de homologação (staging) e, em outubro de 2026, adia a liberação em produção até que uma questão em aberto no rascunho seja resolvida. A contrapartida é que a chave da conta se torna uma autorização permanente, então proteja-a como uma credencial de DNS.

A validação está prestes a acontecer a cada renovação

A reutilização de autorizações está diminuindo junto com a vida útil dos certificados. Os Baseline Requirements limitam a reutilização da validação de domínio a 200 dias hoje, 100 dias a partir de março de 2027 e 10 dias a partir de março de 2029. O perfil padrão da Let’s Encrypt reutiliza autorizações por 30 dias hoje, 10 dias a partir de 10 de fevereiro de 2027 e 7 horas a partir de 16 de fevereiro de 2028. Seja qual for o desafio escolhido, ele precisa rodar sem intervenção; copiar valores TXT à mão não vai sobreviver a 2028.

Quando escolher cada um

• Um servidor web público com o cliente ACME instalado nele: HTTP-01.
• Certificados curinga: DNS-01 (ou DNS-PERSIST-01, onde a sua CA o oferecer).
• Hosts internos com nomes públicos, serviços acessíveis só por VPN, ambientes de desenvolvimento: DNS-01; lembre-se de que os nomes vão aparecer nos logs do CT.
• Frotas com balanceamento de carga, implantações em várias regiões ou com anycast: DNS-01, ou HTTP-01 com todos os nós encaminhando /.well-known/acme-challenge/ por proxy para um único respondedor.
• CDNs e plataformas gerenciadas: deixe a plataforma validar (normalmente pelo HTTP-01 na borda dela ou por um CNAME que você adiciona uma única vez).
• Certificados para endereços IP: HTTP-01 ou TLS-ALPN-01; na Let’s Encrypt, apenas no perfil shortlived, de seis dias.
• Porta 80 fechada por política: DNS-01 ou TLS-ALPN-01.

Notas de migração

1. Migração de HTTP-01 para DNS-01: crie uma zona dedicada aos desafios, aponte cada nome _acme-challenge para ela com um CNAME, dê ao cliente ACME um token restrito a essa zona e mude o tipo de desafio do cliente; os certificados existentes continuam funcionando.
2. Verifique a propagação antes de responder ao desafio: a maioria dos clientes consegue esperar até que todos os servidores autoritativos retornem o registro; ative essa opção em vez de uma pausa fixa.
3. Faça a limpeza: é recomendável que os clientes excluam os registros TXT depois da validação (RFC 8555 §8.4); os que sobram se acumulam e deixam as consultas mais lentas.
4. Restrinja a emissão com CAA usando accounturi e validationmethods, tanto em issue quanto em issuewild.
5. Renove no cronograma da CA: use o ACME Renewal Information (ARI, RFC 9773) onde houver suporte; caso contrário, renove em cerca de dois terços da vida útil. A calculadora de vida útil de certificados mostra os limites por data.
6. Monitore a emissão nos logs do CT (Certificate Transparency para desenvolvedores) para que os certificados obtidos por qualquer método fiquem visíveis.

Referências

• RFC 8555 §8, desafios de validação de identificadores do ACME
• RFC 8737, TLS-ALPN-01 e RFC 8738, identificadores IP no ACME
• RFC 8657, accounturi e validationmethods no CAA
• RFC 7638 §3.1, exemplo de impressão digital de JWK
• RFC 9773, ACME Renewal Information
• Baseline Requirements do CA/Browser Forum, §3.2.2.4, §3.2.2.9, §4.2.2
• Votação SC-085v2, validação de DNSSEC nas consultas de CAA e DCV
• Let’s Encrypt: tipos de desafio
• Let’s Encrypt: DNS-PERSIST-01
• Let’s Encrypt: redução da vida útil dos certificados para 45 dias