How HTTP-01 automated validation works

What is an HTTP-01 challenge?

Automated Certificate Management Environment (ACME) HTTP-01 is a standards-based way to prove control of a domain by serving a short-lived challenge response over HTTP. It can be simple and highly automatable when the target hostname is reachable on port 80, but redirects, load balancers, CDNs, geographic filtering, and multi-perspective validation can change the design.

HTTP-01 is one of the challenge types defined by the Automated Certificate Management Environment (ACME) protocol. Its purpose is domain control validation (DCV), proving that the requester controls the hostname for which a certificate is being requested. The ACME server provides a challenge token, and the ACME client uses that token plus its ACME account key to construct a key authorization. The client makes that response available at a standard URL on the requested hostname:

http://yourdomain.example/.well-known/acme-challenge/<token>

DigiCert retrieves the resource over HTTP on TCP port 80 and verifies that the response contains the expected key authorization. Successful DCV establishes control of the hostname for that validation event; certificate issuance still depends on the certificate product, any required organization validation, CAA checks, approval settings, and other issuance requirements.

How HTTP-01 works, step by step

1. The ACME client starts an order — the client requests a certificate for one or more fully qualified domain names (FQDNs) using DigiCert ACME credentials and an ACME directory URL.
2. DigiCert returns an authorization challenge — for a domain that requires dynamic ACME validation, the ACME server returns an HTTP-01 challenge containing a unique token.
3. The client publishes the challenge response — the client computes the key authorization and serves it at /.well-known/acme-challenge/<token> on the HTTP service for the FQDN being validated.
4. The client signals that the response is ready — the ACME client tells the ACME server that the challenge resource has been provisioned.
5. DigiCert validates from the network — DigiCert requests the challenge URL on port 80 and verifies the returned key authorization. For publicly trusted TLS issuance, DigiCert also performs required CAA and multi-perspective checks.
6. Issuance can proceed — if DCV succeeds and all other validation, policy, and approval requirements are satisfied, DigiCert can issue the certificate. Installation and service reload are separate lifecycle steps handled by the client or automation workflow.

When HTTP-01 is a good fit

HTTP-01 is often a strong choice when the ACME client can control the web server or routing layer, and DigiCert can reliably reach the requested hostname on port 80. It avoids the need to grant the ACME client DNS API credentials and can be straightforward on conventional web-server deployments.

• A web server or reverse proxy already listens on port 80 for the hostname.
• The ACME client can write or serve content under /.well-known/acme-challenge/.
• Routing is deterministic enough that every DigiCert validation perspective can retrieve the same challenge response.
• You are validating specific FQDNs rather than wildcard names.
• You prefer not to place DNS write credentials in the certificate-renewal workflow.

When HTTP-01 is not the right option

Choose another DCV approach when the environment cannot reliably satisfy HTTP-01 requirements. DNS-01 is the standard ACME alternative for wildcard names and is often better suited to environments where validation should be decoupled from web-server routing.

• Inbound HTTP on port 80 cannot be made reachable from DigiCert validation infrastructure.
• You need a wildcard certificate such as *.example.com. Standard ACME HTTP-01 cannot validate wildcard identifiers; use DNS-01.
• A CDN, load balancer, geo-routing policy, or multiple independent origins cannot consistently serve the same challenge response.
• You need ACME validation of an IP address. DigiCert documents that ACME HTTP-01 does not support IPv4 or IPv6 address validation.
• The ACME client does not have permission to publish the challenge response at the required path.

Design requirements that commonly determine success

• Port 80 reachability — the validation request is made to the HTTP URL on TCP port 80. If you restrict inbound traffic by IP, use the current DigiCert-published validation IP ranges rather than hard-coding ranges into documentation.
• Correct hostname and path — the requested FQDN must resolve to infrastructure that can serve the challenge response at /.well-known/acme-challenge/<token>.
• Load balancers and CDNs — if requests can land on different backends or edges, each possible path must return the expected challenge response, or the routing layer must direct challenge requests to a centralized challenge responder.
• Redirect behavior — HTTP-to-HTTPS redirects are not automatically invalid. ACME permits redirect following, and DigiCert supports redirects that meet its DCV rules. Misconfigured redirect chains, unsupported status codes, cross-domain redirects, or rules that hide the challenge resource can still cause validation failure.
• Geographic and security filtering — because DigiCert validates public TLS domain control from multiple network perspectives, geo-blocking, asymmetric routing, WAF rules, CDN policies, or regional origin differences can produce inconsistent results.
• DNS consistency — the hostname must resolve consistently enough for the validation perspectives to reach infrastructure that serves the expected response. If DNSSEC is configured, DigiCert validates DNSSEC during applicable DCV and CAA lookups; DNSSEC itself is not required for issuance.

Why did my HTTP-01 challenge fail?

Start with the network path rather than the certificate request itself. The following checks resolve most HTTP-01 failures:

• Confirm DNS resolution: verify the FQDN resolves to the infrastructure that actually serves the ACME challenge response.
• Confirm port 80 reachability: test from outside your network and review perimeter firewall, cloud security group, WAF, host firewall, and geographic filtering rules.
• Verify the exact challenge path: confirm the client has published the current response under /.well-known/acme-challenge/<token> and that the path is not rewritten or shadowed by another application.
• Inspect redirects: a redirect can be valid, but confirm it uses a supported status code and destination and ultimately returns the correct challenge response.
• Check every load-balanced path: if multiple origins or edges can receive the request, confirm all of them serve the correct response or route the challenge path to one authoritative responder.
• Look for regional differences: compare DNS, CDN, WAF, and origin behavior across regions. MPIC can expose geo-routing or asymmetric-routing differences that a local test misses.
• Review DNSSEC and CAA: if DNSSEC is configured, validate the chain. Also verify CAA records do not prohibit DigiCert issuance.
• Use DigiCert validation status: use CertCentral or Trust Lifecycle Manager validation details and current DigiCert documentation to identify the exact failure rather than relying only on the ACME client's summary error.

Frequently asked questions

Supplemental resources

• DigiCert: ACME HTTP-01 challenge
• DigiCert: Supported domain control validation methods
• DigiCert: Complete HTTP-01 challenges for ACME
• DigiCert: Certbot example for Apache using HTTP-01
• DigiCert: CertCentral change log - MPIC and DNSSEC updates
• RFC 8555: Automated Certificate Management Environment (ACME)
• CA/Browser Forum: TLS Baseline Requirements