iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
ACME uses HTTP-01 and DNS-01 challenges to check that a requester controls a domain identifier before a certificate can be issued. HTTP-01 asks the certificate authority (CA) to retrieve a token-derived response from a web path on port 80; DNS-01 asks it to find a token-derived value in a TXT record. Neither challenge issues a certificate by itself: the client must still finalize the order with a certificate signing request (CSR).
How ACME moves from an order to a certificate
RFC 8555 defines ACME as an order-and-authorization process. A client starts by requesting an order for one or more identifiers, such as domain names. The ACME server returns the authorization resources required by its policy; there is not necessarily a one-to-one match between identifiers in the order and authorization resources. RFC 8555
- Create an order. The client asks the server to issue a certificate for the requested identifiers.
- Complete authorizations. For a pending authorization, the client chooses a supported challenge and installs the corresponding proof before telling the server the challenge is ready for validation.
- Wait for validation. The CA checks the proof using the selected method. A successful challenge can make the authorization valid; unsuccessful validation can make it invalid. The protocol also defines other authorization states, including expired and deactivated.
- Finalize the order. Once all authorizations required for the order are valid, the order reaches
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 challenge therefore establishes control of an identifier for authorization purposes. It is a prerequisite to issuance, not the certificate request or the issuance step itself.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →How HTTP-01 proves control
For HTTP-01, the ACME server provides a token. The client combines that token with a thumbprint derived from the ACME account’s public key to form the expected key authorization. The format is the token, a period, and the base64url-encoded JWK thumbprint. The client makes that value available at http://<domain>/.well-known/acme-challenge/<token>. The CA retrieves the resource over HTTP and checks that its response matches the expected key authorization. RFC 8555 specifies port 80 for this challenge. RFC 8555; Let’s Encrypt challenge types
#1 Best Overall
Why port 80 and public reachability matter
The validation depends on the CA being able to fetch the challenge resource from the domain. The relevant web endpoint must therefore be reachable to the CA over HTTP on port 80 when validation occurs. A private-only service or a network path that blocks the request cannot serve the required proof.
What can interfere with the check
The server, reverse proxy, or routing rules must deliver the expected content at the challenge path. Redirect handling can also affect what a CA retrieves; do not assume every CA follows redirects in the same way. Check the selected CA’s current operational documentation and configure the endpoint accordingly.
Rank #2
How DNS-01 proves control
DNS-01 starts with the same token and account-key thumbprint used to form the key authorization. The client hashes that key authorization with SHA-256, then base64url-encodes the digest. It publishes the encoded value as a TXT record at _acme-challenge.<domain>. The CA looks up the TXT record and checks for the expected value. RFC 8555
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWhy the proof is a TXT record
The TXT record is the DNS-published proof that the client can arrange for the requested value to appear under the identifier’s challenge name. The CA compares the published digest with the one it derives from the challenge and account key; simply creating an arbitrary TXT record is not sufficient.
Rank #3
Wildcard identifiers and delegated DNS
DNS-01 supports wildcard authorizations; HTTP-01 does not. Let’s Encrypt’s operational guidance says it follows DNS standards for TXT lookups, so a CNAME or NS record can delegate challenge answering to another DNS zone. That can separate challenge automation from the primary zone, but it does not remove the need to protect the automation and scope its DNS credentials carefully. Let’s Encrypt challenge types
HTTP-01 and DNS-01 compared
| Consideration | HTTP-01 | DNS-01 |
|---|---|---|
| What the CA checks | A token-derived key authorization served at the well-known challenge path. | A SHA-256 digest of the key authorization published as a TXT record under _acme-challenge. |
| Network dependency | The challenge URL must be reachable over HTTP on port 80. | Does not depend on an inbound web request to the server. |
| Wildcard authorization | Not supported. | Supported. |
| Automation interface | The client or web-server stack must place the response at the correct path. | The client needs a way to publish the TXT record, manually or through DNS automation. |
| Operational consideration | Web routing, proxies, and CA-specific redirect behavior can affect retrieval. | DNS API credentials can increase the impact of a compromise; delegated challenge zones may help constrain automation. |
Which challenge should you choose?
Choose HTTP-01 when the web path is available
HTTP-01 is a practical fit when the domain’s challenge URL can be exposed to the CA over port 80 and your client or web stack can reliably serve the expected response. It avoids the need for DNS-provider automation, but depends on the public web endpoint and its routing being correct during validation.
Choose DNS-01 for wildcard certificates or when inbound HTTP is unavailable
DNS-01 is necessary when you need wildcard authorization and is useful when the server cannot receive an inbound HTTP validation request. You must be able to publish the TXT proof, either manually or through an automation interface. If using DNS automation, consider a delegated challenge zone and restrict credentials to the narrowest scope your DNS provider supports.
Keep protocol requirements separate from provider behavior
RFC 8555 defines the ACME protocol behavior. Let’s Encrypt’s challenge documentation describes that provider’s operational guidance, which can change over time. Boulder is software used by Let’s Encrypt; its implementation details are not a universal definition of how every ACME server behaves. Boulder documentation
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.
