<b>Why does the ACME DNS-01 challenge prove something HTTP-01 cannot?</b>

<b>Why does the ACME DNS-01 challenge prove something HTTP-01 cannot?</b>

Let's Encrypt automates issuance via ACME (Automatic Certificate Management Environment, RFC 8555). The protocol proves you control a domain through a challenge, and the choice between HTTP-01 and DNS-01 is not merely about convenience — they prove different scopes of control.

HTTP-01 asks the CA to fetch a token at http://your-domain/.well-known/acme-challenge/. Passing it proves you control the web server answering on port 80 for that exact hostname. It cannot issue wildcards, and it depends on inbound port 80 being reachable from the CA's validation network — which it deliberately performs from multiple network vantage points (multi-perspective validation, deployed 2020) to resist BGP-hijack-based fraud.

DNS-01 asks you to publish a TXT record at _acme-challenge.your-domain. Passing it proves control of the domain's DNS zone — a strictly broader authority. This is why DNS-01 is the only challenge that can issue wildcard certificates (*.example.com): a wildcard asserts control over an unbounded set of subdomains, which only zone-level control can substantiate.

Evidence vs. speculation: the wildcard-requires-DNS-01 rule is mandated by RFC 8555 §7.1.1 and Let's Encrypt policy, not an implementation quirk. The validation, not the issuance, is where the security lives.

<b>Further reading:</b> RFC 8555 §7.1, §8; Let's Encrypt multi-perspective validation announcement (2020).

<b>Bottom line:</b> HTTP-01 proves host-level control and fits single-name automation; DNS-01 proves zone-level control and is mandatory for wildcards — pick the challenge that matches the authority you actually need to assert.