ACME HTTP 01 Readiness Validator

Introduction:

ACME HTTP-01 validation proves control of a host by asking a public web server to serve a short challenge response at a well-known HTTP path. The certificate authority supplies a token, the ACME client combines that token with the account key authorization, and the authority fetches the result over ordinary HTTP. If the fetched body matches what the authority expects, domain control is proven for that identifier.

The method is attractive because it fits the systems many teams already run: a webroot, reverse proxy, ingress controller, load balancer, or temporary standalone listener. It is also fragile in predictable ways. Port 80 must be reachable, the challenge path must avoid the normal application fallback, the body must be plain text rather than an HTML page, and every public route that might answer for the host must serve the same current token.

Most HTTP-01 failures come from a gap between the operator's local test and the authority's public fetch. A curl from the origin server can succeed while the public route still fails through a CDN, WAF, IPv6 listener, alternate backend, forced HTTPS rule, or stale cache. A browser can show a friendly site page while the ACME server needs one exact body at one token URL.

Redirects deserve special care. Some ACME services follow limited redirects, but redirects do not relax the core requirement: the final response still has to be reachable on allowed ports and contain the key authorization body. Redirect loops, non-standard ports, authentication walls, captchas, bot challenges, and default virtual-host pages usually turn a working web site into a failing ACME route.

HTTP-01 also has scope boundaries. It is not the right method for wildcard certificates, and it is inconvenient when port 80 cannot be exposed. DNS-01 is often better for wildcard names, private services, or fleets where distributing a web challenge to every node is harder than automating a DNS TXT record. For ordinary public web hosts, HTTP-01 remains a practical path when the route is deliberately kept simple during validation.

A readiness check should therefore combine protocol facts with operational evidence. The useful question is not whether the domain has a web server, but whether the exact public validation path will return the exact current key authorization from every relevant route while the ACME server is retrying.

How to Use This Tool:

Use the form after an ACME client has produced a token and expected key authorization, or while preparing a manual retry runbook for a failed order.

1. Enter the Identifier as one host name, without a path. Wildcard names and IP-style inputs are flagged because this checker is focused on host-based HTTP-01 readiness.
2. Select the CA profile. Let's Encrypt / Boulder applies the common 10-redirect expectation, Generic ACME HTTP-01 keeps redirect assumptions more cautious, and Strict internal CA expects direct HTTP answers.
3. Paste the Challenge token and Expected key authorization. The key authorization should begin with the token, then a dot, then the account-key thumbprint portion.
4. Choose the Observed HTTP result from an external probe, ACME dry run, load balancer log, or monitoring check. Paste the fetched body or relevant probe notes in Observed body or probe notes.
5. Set the Challenge handler so the runbook matches a static webroot, reverse proxy, standalone listener, Kubernetes ingress, or application route.
6. Open Advanced when the route crosses IPv6, multiple backends, CDN or WAF rules, edge caches, or redirect chains. The readiness ledger changes as those assumptions change.
7. Read Readiness Ledger first, then use Retry Runbook and Probe Script to turn the findings into a repeatable pre-retry check.

Interpreting Results:

The score is a triage aid, not a certificate authority result. Ready for HTTP-01 retry means the entered evidence lines up with the selected policy. Ready with review notes means no hard blocker was found, but one or more assumptions still need confirmation. Fix blockers before retry means the next ACME attempt is likely to fail until the named route, body, identity, or edge problem is fixed.

The most common false-confidence mistake is trusting one successful request. If the host has AAAA records, round-robin DNS, a load balancer, canary routing, or edge cache, repeat the probe from paths that can hit each public answer before asking the ACME server to retry.

Technical Details:

HTTP-01 has a compact protocol core. The challenge token is placed at a fixed path under the requested host, and the response body is the key authorization. The ACME server constructs the HTTP URL, fetches it on TCP port 80, checks that the response body is a valid key authorization, and compares it with the stored expected value.

Rule Core

Each check earns full, half, or zero credit for pass, review, or blocker status. The readiness score is the earned weighted total divided by the maximum weighted total.

The body check is deliberately strict. A web server can return HTTP 200 and still fail the challenge if it serves a branded error page, a JSON object, a templated route, an old token, or the right key authorization embedded inside other text. The expected body should be the key authorization itself, with no user-facing page chrome.

Redirect handling is profile-sensitive because ACME servers differ in practice. The Let's Encrypt profile permits limited HTTP and HTTPS redirects on standard ports, while a strict internal profile treats any redirect as a blocker. A generic profile warns on redirects because not every ACME implementation follows the same policy.

Limitations and Privacy Notes:

The checker evaluates the evidence and settings you provide; it does not perform the public ACME validation itself. It cannot prove DNS propagation, CDN routing, WAF behavior, or backend consistency unless your probes and logs represent those paths accurately.

• Challenge tokens and key authorizations are processed in the browser for the visible report and script text.
• Do not paste private account keys; HTTP-01 uses a thumbprint-derived key authorization, not the secret key material.
• Use staging or dry-run issuance when available before retrying a production certificate order after major routing changes.

Worked Examples:

Clean webroot retry. The host is example.com, the token and key authorization have the right shape, the external body exactly matches, redirects are off, and port 80 is reachable. The score reaches 100/100 and the retry runbook keeps the next steps short: publish, probe from outside, and retry.

Wrong default virtual host. The observed result is HTTP 200, but the pasted body is an HTML default page. The exact body match becomes a blocker even though the route responds. The fix is to route the challenge path ahead of the normal site fallback and retest the body byte-for-byte.

Stale edge cache. The body matched once, but the cache TTL is 120 minutes and a new order has a new token. The cache row becomes a review note because quick retries can keep serving the previous token. Purge the challenge URL and repeat the external probe before retrying.

FAQ:

Why does HTTP-01 require port 80?

The ACME HTTP-01 validation URL is fetched over HTTP on TCP port 80. HTTPS redirects may be followed by some authorities, but the initial challenge method still depends on the port-80 HTTP route.

Can HTTP-01 issue wildcard certificates?

No. Use DNS-01 when the order includes a wildcard name. The identifier row flags wildcard input so the failure is caught before route troubleshooting.

Does a successful browser request prove readiness?

Not by itself. Browser sessions can carry cookies, follow local DNS, or hit a different route than the ACME validator. Use the generated probe script from an external network and compare the body text.

Should the challenge path be protected by login or bot rules?

No. The challenge URL needs to answer an unauthenticated GET with the plain expected body. Captchas, JavaScript challenges, and login redirects are blockers for this workflow.

Glossary:

ACME

Automatic Certificate Management Environment, the protocol used by ACME clients and certificate authorities to automate certificate issuance.

HTTP-01

An ACME challenge type that proves control by serving a key authorization at a fixed HTTP path for the requested host.

Key authorization

The token plus a dot plus the account-key thumbprint portion that the ACME server expects as the challenge response body.

Edge path

The public route through DNS, CDN, WAF, load balancer, proxy, ingress, and backend that the ACME validator may actually hit.

References:

• RFC 8555: Automatic Certificate Management Environment
• Let's Encrypt: Challenge Types