ACME HTTP 01 Readiness Validator

A certificate authority using Automatic Certificate Management Environment (ACME) must reach a short-lived challenge response through the public Internet before it can issue a certificate. With the HTTP-01 challenge, that response lives under a fixed path on port 80 for the exact DNS name in the order. A successful request returns the order's key authorization as plain text.

Many failed retries are not certificate problems. The token may have changed, the challenge path may fall through to an application route, or a reverse proxy may send the request to a backend that never received the current value. IPv6, caches, content delivery networks, web application firewalls, and forced redirects can each make an origin test look healthy while the public path still fails.

Challenge token

A fresh, unpredictable value created for the current authorization. Evidence from an earlier order does not prove that the current token is being served.

Key authorization

The token joined to the account-key thumbprint. The response body must match this current value.

Public challenge path

The unauthenticated HTTP route that the certificate authority requests. Every reachable address and backend must serve the same content.

A browser request from inside the same network is weak evidence because split DNS, private routing, trusted-source rules, or an origin bypass can hide the public failure. A useful readiness check comes from an external probe of the exact hostname and token path, with IPv4 and IPv6 tested separately when both address families are published.

Redirects need special care. ACME clients and certificate authorities can differ in what they follow, and a redirect may introduce another hostname, port, certificate, cache, or access policy. A direct HTTP 200 response is the most portable arrangement. Wildcard identifiers are outside HTTP-01 and require a DNS-based challenge.

Readiness is therefore an evidence judgment, not a live issuance guarantee. A clean review means the supplied observations agree with the selected policy. It cannot prove what a certificate authority will see after DNS, routing, cache, or backend state changes.

How to Use This Tool:

Collect a fresh public probe for the current ACME order before filling in the review. The hostname, token, key authorization, and observed body must all belong to the same attempt.

1. Enter the DNS identifier without a scheme or path, then choose the Validation profile that matches the certificate authority.
2. Paste the current Challenge token and Expected key authorization. Do not reuse values from a failed or expired order.
3. Probe the exact challenge URL from outside the origin network and record the Observed HTTP result, redirect behavior, hop count, and response body.
4. Describe the public route through IPv6 / AAAA behavior, Public backend consistency, CDN / WAF behavior, and the challenge cache lifetime.
5. Read the overall verdict first, then use the evidence ledger and retry runbook to clear every Blocker and verify each Review item before retrying validation.

Interpreting Results:

The verdict takes precedence over the percentage. Any blocker produces Fix blockers before retry, even when several other checks pass. A review-only result means the route may work, but one or more observations remain incomplete or depend on the chosen certificate-authority policy.

• Pass means all nine supplied checks meet the selected rules.
• Review means there are no blockers, but at least one item needs a fresh probe or policy confirmation.
• Blocker means at least one condition is incompatible with a safe retry, such as a wildcard name, malformed token pair, unreachable route, mismatched body, broken IPv6 listener, inconsistent backend, intercepting edge policy, or excessive cache lifetime.

Technical Details:

HTTP-01 validation binds three facts together: the DNS identifier in the authorization, the token created for that authorization, and the ACME account key. The key authorization has the form token.thumbprint. The current review accepts a base64url token 22 to 256 characters long and a 43-character base64url thumbprint suffix.

Rule Core

The nine checks use ordered pass, review, and blocker rules. These rules mix protocol requirements with a clearly labeled operator policy for safe retries.

Formula Core

Each check contributes its weight multiplied by a status factor. Pass contributes 1, Review contributes 0.5, and Blocker contributes 0. The weights total 100, so the rounded weighted sum is already a percentage.

The overall status is not derived from a percentage band. It is Blocker when any check blocks, otherwise Review when any check needs review, and Pass only when every check passes. Category percentages for identity, route, body, and edge safety use the same factors but divide by the weights in that category.

The weighted score is an operator readiness heuristic, not a value defined by RFC 8555 or a certificate authority. Its purpose is to prioritize evidence without allowing a high percentage to hide a blocking condition.

Limitations and Privacy Notes:

No network request is made by the review itself. The result depends entirely on the observations you supply, so a stale or internal-only probe can produce false confidence.

• Repeat the probe from the public Internet after changing DNS, redirects, firewall rules, cache policy, or backend content.
• Test both IPv4 and IPv6 when the hostname publishes both address families.
• Do not treat the generated probe command or readiness score as certificate-authority confirmation.
• Challenge tokens and key authorizations are short-lived operational data. Keep them out of long-lived tickets and public logs when they are no longer needed.

Worked Examples:

References:

• RFC 8555: Automatic Certificate Management Environment, RFC Editor, March 2019.
• Challenge Types, Let's Encrypt.
• Best Practice: Keep Port 80 Open, Let's Encrypt.
• How to troubleshoot Certbot challenge failures, Simplified Guide.
• How to force curl to use IPv4 or IPv6, Simplified Guide.