Alternative DCV Checker

Public certificate issuance depends on fresh proof that the applicant controls each requested domain. That proof may live in DNS or at a well-known web path. A certificate authority (CA) supplies the random value or request token and defines where it must appear, how it must be formatted, and how long it remains usable.

Alternative domain control validation (DCV) methods vary more than their labels suggest. One CA may expect a literal TXT value, another a CNAME target built from a certificate signing request (CSR), and another a file whose name and body follow separate rules. A publicly reachable value can therefore be valid DNS or HTTP data while still being wrong for the active order.

A multi-domain certificate needs evidence for every subject alternative name (SAN), not just the common name. Some CA profiles can walk from a fully qualified domain name toward an authorization parent, while others require proof on the exact hostname. Wildcards and CA-specific authorization-domain rules need the active CA documentation rather than a guess based on a neighboring domain.

Transport success and proof success are separate. A timeout or TLS failure means the checker could not observe the proof reliably. An HTTP 200 response with the wrong body is a signal mismatch. Conversely, one matching fallback method helps only when the current CA order is configured to accept that method.

A preflight can confirm what selected public resolvers and a remote web fetch see at one moment. It cannot approve the order, reproduce the CA's required network perspectives, or establish that the proof value will still be current when validation runs.

How to Use This Tool:

Start from the active CA order and choose the matching proof profile before collecting public evidence.

1. Select the Validation profile. Use Custom mixed check only when the CA's owner name, target, or web path differs from a built-in profile.
2. Paste the Certificate signing request when the profile derives hashes from it, then add or extract the Certificate hostnames. Use one hostname per line.
3. Paste the current Order token or unique value. Values from an earlier order can produce a clean public response and still fail CA validation.
4. Enable only the DNS, HTTP, and HTTPS methods configured for the order. Check custom owner templates, authorization-domain walking, web paths, redirect handling, and TLS trust before starting the run.
5. Read Readiness brief by hostname, then use method evidence to separate mismatches from transport failures. Retry the CA only after a matching method agrees with the order configuration.

Interpreting Results:

• Every path ready means every enabled method matched for every checked hostname.
• Fallback path ready means at least one enabled method matched somewhere, but one or more enabled paths or hostnames remain unmatched. Confirm that the CA order permits the matching method.
• Proof mismatch means public evidence was reached but none of the enabled methods matched the expected proof.
• Transport issues means no method matched and at least one resolver or web request could not produce usable evidence. Restore reachability before deciding that the published value is wrong.

The summary is intentionally permissive about fallback methods. For a SAN certificate, approval should still require a suitable matching proof for every hostname that the CA has not already validated.

Technical Details:

Alternative DCV is a comparison between order-specific expected material and public observations. The comparison rules come from the selected profile; changing profiles can alter the DNS owner, record type, expected target, web filename, body terms, and authorization-domain search.

Transformation Core:

CSR hashes are computed from the DER-encoded request in the browser. Subject common name and DNS SAN entries can be extracted as candidate hostnames. Hashes identify the request material for these vendor profiles; they are not a certificate signature check.

Sectigo file-body terms are compared without letter-case sensitivity. Other web profiles keep the supplied letter case, while DNS CNAME values are lowercased and have a trailing dot removed before exact comparison.

Rule Core:

Each enabled method for each hostname receives one of three outcomes.

The batch label is Every path ready only when all hostnames match every enabled method. Any match in an otherwise incomplete batch produces Fallback path ready. With no matches, transport takes precedence over proof mismatch when at least one request failed.

Public Request Mechanism:

DNS checks query the selected public resolver for TXT or CNAME. An optional authorization-domain walk tests the hostname and then removes leftmost labels, up to 1 to 6 candidates. CNAME comparisons are exact after lowercasing and removing a trailing dot; TXT comparisons look for the expected token within returned text.

HTTP and HTTPS checks are performed from a remote fetch service because browser cross-origin rules would otherwise hide many responses. Only public hosts on ports 80 and 443 are accepted. Same-host redirects may be followed for up to six hops, and response reading stops after 65,000 bytes. Trusted TLS path requires normal certificate validation for HTTPS; when it is off, an untrusted certificate can still expose the proof body and should not be read as a healthy TLS deployment.

A run accepts 1 to 120 unique hostnames, a timeout from 500 to 20,000 milliseconds, and concurrency from 1 to 20. These bounds change collection behavior, not CA policy.

Privacy and Accuracy Notes:

The CSR and order token remain session-only and are excluded from the shareable URL and browser persistence. Public checks still transmit data needed to observe the proof.

• DNS owner names are sent to the selected public resolver.
• For web checks, the public target URL and expected proof terms are sent to a remote fetch service, which retrieves a bounded response and returns status, redirect, match, and body-preview evidence.
• Private, loopback, link-local, and other non-public target addresses are rejected. Redirects to another hostname or a nonstandard port are also rejected.
• A response preview can contain public page text. Do not publish secrets at a DCV path or paste private CSR material into copied reports.
• CA methods and request-token formats can change. Verify the current order instructions before relying on a built-in profile.

Worked Examples:

References:

• Baseline Requirements, Section 3.2.2.4.7: DNS Change, CA/Browser Forum.
• Domain Control Validation Methods, Sectigo.
• Add and validate a domain using HTTP Practical Demonstration, DigiCert.
• How to check a CNAME chain with dig, Simplified Guide.