{{ summaryHeading }}
{{ scoreDisplay }}
{{ summaryLine }}
{{ badge.label }}
{{ node.label }} {{ scoreDisplay }}
Use one host, such as example.com or www.example.com. Do not include a path.
Let's Encrypt is the normal HTTP-01 profile; Generic ACME keeps the RFC-only checks; Strict internal CA blocks redirects.
Paste the token from the ACME order. The generated URL and probe script update immediately.
The body should start with the token and a dot, with no HTML, quotes, JSON, or trailing explanation.
Choose the closest external observation for the challenge URL.
Keep this explicit because CDN and forced-HTTPS rules are common ACME HTTP-01 failure points.
The validator looks for an exact key-authorization body and common failure signatures.
Pick the component that serves /.well-known/acme-challenge/ during renewal.
Leave as same when no AAAA exists or the IPv6 listener is verified.
Use strict values when DNS or a load balancer can send validators to several backends.
The challenge path should be a plain public GET with no login, JavaScript, captcha, or cookie dependency.
minutes
0-5 minutes is safest during active issuance; purge the path before retrying if unsure.
hops
Let's Encrypt follows up to 10 redirects; strict profiles should stay at 0.
Check Status Evidence Next action Copy
{{ row.label }} {{ row.statusLabel }} {{ row.evidence }} {{ row.action }}
Step When Action Owner Copy
{{ row.step }} {{ row.when }} {{ row.action }} {{ row.owner }} 
{{ probeScript }}
{{ formattedJson }}
Tags: DNS, HTTP, PKI, Security
Certificate Renewal Window Calculator Plan TLS certificate renewals from population, validity, lead time, spread, daily capacity, retry reserve, and safety buffer before expiry.
ACME DNS Challenge Readiness Check Check whether an ACME DNS-01 challenge is ready, with TXT matching, delegation-route checks, resolver comparison, and retry timing.
Alternative DCV Checker Check DNS, CNAME, HTTP, and HTTPS DCV proofs before a certificate retry, with CSR-hash handling, resolver evidence, and mismatch notes.
SSL Certificate Chain Checker Check a live host or pasted PEM chain for missing issuers, hostname mismatch, expiry risk, weak crypto, and install-ready certificate bundles.
Customize
Advanced
:

ACME HTTP-01 validation is a public web-route test. A certificate authority gives an ACME client a token, the client publishes a matching key authorization under a fixed path on the requested host, and the authority fetches that URL over ordinary HTTP. The validation succeeds only when the public response body matches the expected key authorization for the current order.

The method fits many web stacks because it can be handled by a static webroot, reverse proxy, temporary standalone listener, Kubernetes ingress, load balancer, or application route. That convenience also makes failure modes easy to hide. A site can serve normal pages correctly while the challenge path returns a default virtual host, an HTML error page, a login redirect, an old token, or a CDN challenge that an ACME validator cannot pass.

ACME HTTP-01 route from certificate authority through DNS, port 80, the challenge path, and an exact response body.

Port 80 is central to HTTP-01. The initial validation URL is built with the requested domain, the fixed /.well-known/acme-challenge/ prefix, and the challenge token, and the ACME server fetches it on TCP port 80. Redirects may be allowed by some authorities, but they do not change the final requirement: the authority must still reach a valid HTTP or HTTPS destination on an allowed port and receive the exact key authorization body.

Readiness depends on every public route, not only the route tested from an administrator's shell. AAAA records can send validators to a different IPv6 listener. Round-robin DNS, load balancers, blue-green pools, and Kubernetes ingress rules can put some validators on stale nodes. A CDN or WAF can serve cached content, geoblock a validator, inject a bot page, or require authentication before the challenge body is visible.

Factor Good sign Common failure
Identifier A normal DNS host name for the certificate order. Wildcard names, IP-style inputs, or invalid DNS labels.
Challenge route The public HTTP URL reaches the intended handler. Closed port 80, fallback pages, default virtual hosts, or auth walls.
Response body The body is the key authorization text itself. HTML, JSON, quotes, banners, old tokens, or explanatory text.
Edge behavior IPv4, IPv6, all nodes, caches, and WAF paths serve the same current body. Stale cache, broken AAAA, inconsistent backend sync, or bot challenge.

HTTP-01 is not the right challenge for every certificate. Wildcard certificates require DNS-01, and private services or hosts without reachable port 80 often fit DNS-01 or TLS-ALPN-01 better. For ordinary public web hosts, HTTP-01 works well when the validation path is kept plain, unauthenticated, current, and reachable from the same public routes the authority may use.

How to Use This Tool:

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

  1. Enter Identifier as one host name without a path. The checker flags wildcard names, IP-style values, missing hosts, and invalid DNS labels because this workflow is focused on host-based HTTP-01 retries.
  2. Select CA profile. Let's Encrypt / Boulder applies the common redirect expectations, Generic ACME HTTP-01 treats redirects more cautiously, and Strict internal CA expects a direct answer with no redirect.
  3. Paste the Challenge token and Expected key authorization from the current order. The expected value should start with the token, then a dot, then the account-key thumbprint portion.
  4. Set Observed HTTP result from an external probe, dry run, load balancer log, or monitoring check. Paste the fetched body or relevant log excerpt in Observed body or probe notes.
  5. Choose the Challenge handler that will serve the path during renewal, such as a static webroot, reverse proxy, standalone listener, Kubernetes ingress, or application route.
  6. Open Advanced when IPv6, multiple public nodes, CDN or WAF rules, cache TTL, or redirects may change what a validator receives.
  7. Read Readiness Ledger first. Use Retry Runbook for the order of fixes, Probe Script for repeatable curl checks, and Readiness Signal Split Chart to see whether identity, HTTP route, challenge body, or edge safety is carrying the risk.

Interpreting Results:

The score is a retry triage aid, not a certificate authority verdict. Ready for HTTP-01 retry means every weighted check passes for the evidence entered. 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.

Ledger area What it supports What to verify
Identifier eligibility The entered value is a normal DNS host for this HTTP-01 retry check. Use DNS-01 for wildcard names, and keep the ACME order host aligned with the public web route.
Port 80 challenge route The external observation reaches the challenge handler instead of a timeout, auth wall, 404, or fallback route. Probe from outside the origin network and from paths that can hit public DNS answers.
Exact body match The observed evidence contains the current expected key authorization. Remove HTML wrappers, JSON formatting, quotes, banners, old tokens, and friendly error pages.
Edge safety IPv6, backend sync, CDN or WAF bypass, and cache behavior should not change the response seen by validators. Check every public backend and purge the challenge path before quick retries.

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 in ways that can reach those public answers before asking the ACME server to retry.

Technical Details:

HTTP-01 has a compact protocol core. The client provisions a resource whose path is the fixed challenge prefix plus the token. The resource value is the ASCII key authorization, built from the challenge token and the client's account key. During validation, the ACME server builds an HTTP URL for the requested domain, sends a GET request to TCP port 80, checks that the body is a well-formed key authorization, and compares it with the expected value stored for the order.

The current retry risk is operational more than cryptographic. Token shape and key-authorization shape can be checked before the request, but route correctness depends on DNS, public network reachability, virtual-host selection, redirect policy, edge security rules, and cache freshness. A body that contains the expected string inside an HTML page is still a review problem because ACME validation expects the challenge response body itself, not a normal web page that happens to include the token.

Rule Core

Check Weight Pass, review, and blocker behavior
Identifier eligibility 12 Blocks wildcard names, IP-style inputs, missing hosts, and invalid DNS labels.
Token and key authorization 10 Blocks tokens outside the base64url-like 8 to 256 character shape or key authorizations that do not start with token plus dot; reviews unusual thumbprint shape.
Port 80 challenge route 16 Blocks timeout, refused connection, 404, fallback route, 401, 403, authentication, or bot defense; reviews unprobed routes.
Redirect policy 12 Blocks strict-profile redirects, redirect loops, more than 10 hops, and non-80/443 redirect targets; reviews generic or cross-host redirects where policy support is uncertain.
Exact body match 20 Blocks known wrong bodies and route failures; reviews missing evidence, evidence that lacks the expected value, or evidence that also looks like HTML or server banner text.
IPv6 parity 8 Passes when AAAA is absent or equivalent, reviews untested IPv6, and blocks a different, closed, or stale IPv6 listener.
Backend consistency 8 Reviews untested multi-node routes and blocks when any public node serves stale, missing, or different challenge content.
CDN and WAF bypass 8 Reviews unconfirmed bypasses and blocks authentication, captcha, JavaScript, bot defense, or geo/IP policy before the body.
Cache and retry window 6 Reviews challenge caches above 5 minutes and blocks cache TTL above 300 minutes.

Formula Core

Each check earns full credit for Pass, half credit for Review, and no credit for Blocker. The displayed score is the rounded weighted percentage.

S = round ( ∑ ( w i × v i ) ∑ w i × 100 )

Here, S is the readiness score, w is the check weight, and v is 1 for Pass, 0.5 for Review, or 0 for Blocker. The maximum weight is 100. A run with one body-match blocker worth 20 points and one IPv6 review worth 8 points earns 0 for body match, 4 for IPv6, and full credit for the other 72 points, so the score rounds to 76/100.

Readiness labels are driven by status, not score alone. Any blocker produces Fix blockers before retry, even if the weighted percentage remains high. With no blockers and at least one review row, the label becomes Ready with review notes. Only an all-pass ledger shows Ready for HTTP-01 retry.

Redirect and Body Boundaries

Boundary Accepted or reviewed Blocked
Let's Encrypt redirects Direct HTTP, HTTP to HTTPS on 443, HTTP redirect chains on 80, and cross-host redirects with review when the final body is exact. Loops, more than 10 hops, or redirects to non-standard ports.
Generic ACME redirects Redirects are reviewed because implementations differ. Cross-host redirects, loops, too many hops, and non-standard ports.
Strict internal profile Direct HTTP 200 response only. Any redirect.
Body evidence The expected key authorization appears as the plain response body, with trailing whitespace tolerated by the ACME standard. Wrong body, route failure, auth wall, or default page; HTML and banners trigger review even when the expected value appears inside them.

Limitations and Privacy Notes:

The checker evaluates the evidence and settings you enter. It does not perform the public ACME validation itself, query DNS, contact the certificate authority, or prove what every validator vantage point will see.

  • Challenge tokens and key authorizations are processed in the browser for the visible report, probe script, exports, and chart.
  • Do not paste private account keys; HTTP-01 uses a token plus account-key thumbprint, not secret key material.
  • Use staging, dry-run, or low-risk retry flows when a route, cache, or edge-policy change could affect a production certificate order.

Advanced Tips:

  • Run the probe script from a network outside the origin path, then repeat with forced IPv4 and forced IPv6 when AAAA records exist.
  • For load-balanced sites, probe each public backend or temporarily pin validation traffic to a known-good pool before retrying.
  • Set cache TTL to 0 during validation when an edge cache can serve an old token after a new ACME order is created.
  • Use the strict profile for private CAs that do not follow redirects, and do not assume Let's Encrypt redirect behavior applies to every ACME service.

Worked Examples:

Clean webroot retry

The host is example.com, the token and key authorization have the expected shape, the external body exactly matches, redirects are off, and port 80 is reachable. The score reaches 100/100, and the retry runbook stays short: publish the current body, probe from outside, record the evidence, and retry the order.

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. Route /.well-known/acme-challenge/ ahead of the normal site fallback, then 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 asking the ACME server to retry.

FAQ:

Why does HTTP-01 require port 80?

The ACME HTTP-01 validation URL is fetched over HTTP on TCP port 80. Some authorities follow HTTPS redirects, 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 check flags wildcard input so route troubleshooting does not hide the challenge-type mismatch.

Does one successful browser request prove readiness?

No. 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.

Why is a 200 response still marked as a blocker?

HTTP 200 only proves that something answered. The challenge body must match the current key authorization; a default page, branded error page, JSON object, or old token still fails the body check.

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, login redirects, and geo/IP blocks 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.
AAAA record
A DNS record that points a host name to an IPv6 address, which can send validators to a different listener than IPv4.
Challenge handler
The webroot, proxy, ingress, listener, or application route responsible for serving the HTTP-01 path during validation.

References: