How HTTP-01 automated validation works

{{anchor:HTTP-01 challenge}}

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.

{{anchor:How HTTP-01 works}}

How HTTP-01 works, step by step

{{anchor:When HTTP-01 fits}}

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.

{{anchor:When HTTP-01 does not fit}}

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.

{{anchor:Design requirements}}

Design requirements that commonly determine success

{{anchor:Why an HTTP-01 challenge fails}}

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.

{{anchor:FAQ}}

Frequently asked questions

{{anchor:Supplemental resources}}

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

{{anchor:Next steps}}