The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →ACME’s HTTP-01 and DNS-01 challenges let a certificate authority (CA) verify that you control a domain identifier before it issues a certificate. HTTP-01 checks a token-derived response at a web address on port 80; DNS-01 checks a token-derived value in a DNS TXT record. Neither challenge issues a certificate by itself: the ACME order must still be finalized with a certificate signing request (CSR).
How an ACME order and authorization work
ACME separates proving control of an identifier from requesting the certificate. The protocol flow, defined in RFC 8555, is:
As an Amazon Associate I earn from qualifying purchases.
- Create an order. The client asks the ACME server for a certificate covering one or more identifiers, such as domain names. The server returns the authorizations required by its policy; there is not necessarily one authorization resource for every identifier in the order.
- Select and prepare a challenge. A pending authorization contains challenge objects. The client chooses a supported challenge type and puts the required proof in place before telling the server the challenge is ready for validation.
- Complete validation. The CA checks the proof using the selected method. Success makes the authorization valid; a failed check can make it invalid. The protocol also defines other authorization states, including expiration, deactivation, and revocation.
- Finalize the order. Once all authorizations required for the order are valid, the order becomes ready. The client submits a PKCS#10 CSR to the order’s finalize URL. If the CA processes it and issues the certificate, the order becomes valid and provides a certificate URL.
The distinction matters: a challenge proves control of an identifier at validation time, while finalization is the separate step that asks the CA to issue the requested certificate.
How HTTP-01 constructs and checks its proof
What the client publishes
The ACME server supplies a token. The client makes a key authorization by joining the token, a period, and the base64url-encoded JWK thumbprint of the ACME account key. It serves that exact value at http://<domain>/.well-known/acme-challenge/<token>.
#1 Best Overall
What the CA checks
The CA retrieves the challenge resource over HTTP and checks that its response matches the expected key authorization. RFC 8555 specifies HTTP on port 80 for HTTP-01. The proof therefore demonstrates control of the identifier’s web endpoint when the CA performs validation; it does not establish permanent control of the domain.
The challenge path must be publicly reachable by the validating CA. Web-server routing, reverse-proxy rules, and redirects can change what the CA receives, so confirm the behavior of the particular CA and deployment rather than assuming all redirect handling is identical. Let’s Encrypt’s challenge documentation describes its operational guidance, which is provider-specific rather than a replacement for the ACME standard.
Rank #2
How DNS-01 constructs and checks its proof
What the client publishes
The client first constructs the same key authorization used by HTTP-01: the challenge token, a period, and the base64url-encoded account-key JWK thumbprint. It then calculates the SHA-256 digest of that key authorization and base64url-encodes the digest. That encoded value is published as a TXT record at _acme-challenge.<domain>.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Why the TXT record is the proof
The CA looks up the TXT record for the challenge name and checks whether it contains the expected digest. The record carries a value derived from the challenge token and account key, rather than the original key authorization served as a web page. The lookup lets the CA check control through DNS without making an inbound HTTP request to the domain’s web server.
Rank #3
DNS-01 supports wildcard identifier validation; HTTP-01 does not. For Let’s Encrypt specifically, the documented DNS lookup behavior follows DNS standards and allows CNAME or NS records to delegate challenge answering to another zone. Delegation can separate challenge automation from the primary DNS zone, but any automation credentials still need to be limited carefully. Let’s Encrypt’s operational notes describe this provider behavior.
HTTP-01 vs. DNS-01: choose by deployment
| Decision factor | HTTP-01 | DNS-01 |
|---|---|---|
| What the CA must reach | The challenge URL on the domain over HTTP port 80. | A DNS TXT record at _acme-challenge.<domain>; no inbound web request is required. |
| Wildcard identifiers | Not supported. | Supported. |
| Automation interface | The client or web stack must place the response at the correct challenge path. | The client must publish the TXT value, manually or through DNS automation. |
| Main operational consideration | Public reachability and correct routing of the challenge path. | Safe handling and scope of DNS credentials; delegated challenge zones can help isolate automation. |
Choose HTTP-01 when
- You can make the challenge URL publicly reachable over port 80.
- Your ACME client or web-server stack can reliably serve the response at the required path.
- You do not need wildcard validation.
Choose DNS-01 when
- You need to validate a wildcard identifier.
- Your deployment cannot accept inbound HTTP validation requests.
- You can publish the required TXT record, and can manage DNS automation credentials with appropriate limits. Delegating the challenge name to a separate zone may help constrain the automation boundary.
What the protocol does—and what depends on the CA
RFC 8555 defines the challenge-response protocol and the HTTP-01 and DNS-01 proof checks. A certificate authority’s operational instructions explain how that provider performs or supports validation in practice. For example, Boulder is the software implementation used by Let’s Encrypt; its behavior is implementation-specific, not the definition of every ACME server. Boulder’s documentation and source are useful for understanding that implementation, while protocol requirements should be read in the RFC.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
