Alternative DCV Checker

Introduction:

Certificate authorities do not issue a public TLS certificate just because a domain name appears in a request. Domain Control Validation, usually shortened to DCV, is the proof step that shows the requester can control the domain being named on the certificate. For operational teams, the hard part is rarely the idea of DCV itself. The hard part is making the exact public proof match what the certificate order expects before the CA checks it.

Alternative DCV methods move the proof away from email approval and into DNS or web evidence. A DNS TXT method usually publishes a random value in a specific TXT record. A DNS CNAME method points a CA-specified owner name at a CA-specified target. A website-based method publishes a text file under the well-known validation directory so the CA can fetch it. These methods are useful when mailbox routing is unreliable, when many domains are renewed by automation, or when the person ordering the certificate does not control the administrative email addresses.

DNS TXT proof

A CA token appears in a TXT answer at the required owner name, often below a validation prefix.

DNS CNAME proof

A validation owner name aliases to a target that contains the expected token, hash, or CA domain.

Website proof

A public HTTP or HTTPS URL serves a file containing the expected validation value or request token.

Small details decide whether a proof passes. A CNAME target with a missing underscore, a lowercased hash where the file name is case-sensitive, a token published at the parent zone instead of the requested hostname, or a redirect that changes hosts can make a proof look correct to a human and still fail when the CA performs its check. DNS caching adds another source of confusion because one resolver may already see the new record while another still has an old answer or no answer.

Public CA rules and CA-specific instructions both matter. The CA/Browser Forum Baseline Requirements define permitted domain-validation processes, while providers such as Sectigo and DigiCert add exact record names, token formats, file paths, and renewal behavior. A preflight check can reduce repeated CA retries, but it cannot replace the CA's final validation from its own network perspective, account state, and current order token.

How to Use This Tool:

Start with the CA method from the certificate order, then add only the proof material that method needs. The preview line below the token field is the first sanity check: it should describe the exact DNS name, CNAME target, or web path you expect the CA to test.

1. Choose the Validation profile. Use the Sectigo profiles for CSR-hash based CNAME or HTTP/HTTPS proofs, the DigiCert profiles for _dnsauth CNAME or fileauth.txt, and Custom mixed check when you need your own DNS name or proof-file path.
2. Paste a CSR for Sectigo DNS CNAME or Sectigo HTTP/HTTPS file validation. The browser extracts common-name and subject-alternative-name hostnames, then derives the MD5 and SHA-256 values used in the proof.
3. Fill Domains with one hostname per line or comma. Wildcard entries are normalized to the base validation name, duplicates are removed, and the Max domains setting caps large SAN lists.
4. Add the Unique value / token exactly as shown in the CA order. Sectigo hash-based methods may allow the unique value to be blank, while DigiCert token methods need a single-label random value.
5. Open Advanced only when the default method needs adjustment. DNS checks can switch between TXT and CNAME, change the owner-name template, choose Cloudflare or Google as the public resolver, and optionally walk parent authorization domains. Web checks can change the path, follow or stop redirects, require or bypass TLS validation for HTTPS, and tune timeout or concurrency.
6. Select Check readiness. If the button is disabled, fix the helper line first: it will ask for a domain, at least one enabled method, or the missing token or CSR-derived signal.

After the run, use Readiness Brief for the overall state, Method Evidence for per-domain DNS, HTTP, and HTTPS results, and Request Ledger when you need to compare the exact target and observed evidence against the CA instructions.

Interpreting Results:

The main question is whether each hostname has at least one valid proof path and whether every enabled path is clean. All enabled ready means the selected DNS, HTTP, and HTTPS checks all matched for that hostname. Fallback ready means at least one method matched, but another enabled method still mismatched or failed. That can be acceptable if the CA order only needs the working method, but it is a warning sign when you expected every path to be valid.

• Signal mismatch means a DNS answer or web response was reachable but did not contain the expected token, CNAME target, or hash terms.
• Transport issue means the checker could not reliably reach the proof location because of DNS failure, timeout, redirect host mismatch, TLS failure, forbidden private address, or another fetch problem.
• Ready via names the method that matched. If only HTTP is listed but the order is set to DNS CNAME, change the order method or fix the CNAME proof before retrying with the CA.
• DCV Method Outcome Mix shows whether failures are concentrated in one method. A DNS-only failure usually points to the record name, resolver visibility, CNAME target, or TXT content; an HTTP/HTTPS failure points to file placement, routing, redirects, TLS, or body content.

Do not treat a ready result as issuance approval. It means the selected public checks matched from this checker at that moment. The CA may still require a different profile, see a different resolver state, reject a stale token, or apply policy limits such as website-based DCV not validating wildcard names.

Technical Details:

DNS-based DCV proves control through public name resolution. The evidence can be a literal random value in a TXT record or a CNAME target assembled from a CA token or CSR-derived hashes. Website-based DCV proves control through public web serving: the CA requests a defined path under /.well-known/pki-validation/ and checks that the response body contains the expected value.

Sectigo's hash-based methods are tied to the DER-encoded certificate signing request. The MD5 digest is used in the DNS owner name or file name, and the SHA-256 digest is used as proof content or as two 32-character DNS labels. DigiCert's checked paths use a random value either under _dnsauth for CNAME validation or inside fileauth.txt for website validation. These are rule transformations rather than numerical formulas, so a rule core is more accurate than a formula block.

Transformation Core:

Authorization-domain walking checks the exact hostname first and then shorter parent candidates, up to the selected depth. That matches CA flows that allow proof at an eligible authorization domain, but it can also hide an accidental record at a parent zone if the certificate order is supposed to validate only the exact FQDN. Keep the walk setting aligned with the CA method rather than leaving it on for every run.

Validation Boundaries:

The result classification is deliberately conservative. A reachable proof that lacks the expected value becomes a signal mismatch, while resolver errors, forbidden targets, redirect problems, TLS failures, and timeouts become transport issues. This separation helps avoid fixing the wrong thing: changing a token will not repair a blocked web route, changing timeout will not repair a wrong CNAME target, and bypassing TLS validation only explains the HTTPS transport path rather than proving the final certificate state.

Privacy and Accuracy Notes:

The CSR is parsed in the browser to derive domains and hashes. DNS checks query the selected public resolver. HTTP and HTTPS checks send the public URL and expected proof terms to a server-side fetch service so the target proof file can be requested and compared from outside the browser.

• Do not paste a CSR or token unless you are comfortable using it for a live public DCV preflight check.
• The web fetch returns request metadata, redirect details, matched or missing terms, and a short response preview for troubleshooting, but the target site still receives a normal validation-style request.
• A passing result reflects this checker's public network path and current resolver state, not guaranteed CA acceptance.
• Current CA policy, account settings, validation reuse periods, and order-specific tokens can change the final CA outcome.

Worked Examples:

A Sectigo DNS TXT order for www.example.com with token RANDOM123 should publish that value at _pki-validation.www.example.com unless the CA instructions say to validate a parent authorization domain. When the TXT answer contains the token, Method Evidence shows DNS as matched and Ready via includes DNS.

A Sectigo DNS CNAME order using a CSR for secure.example.com produces an uppercase MD5 owner label and a two-label SHA-256 target under sectigo.com. If the DNS record points to the right hash but omits the supplied unique value, Request Ledger shows the expected target and the observed CNAME, while the domain verdict remains Signal mismatch.

A DigiCert fileauth check for app.example.com expects the random value inside /.well-known/pki-validation/fileauth.txt on the checked hostname. If the file exists only on HTTPS while the selected profile checks HTTP, the web result can show a transport issue or mismatch. Enable the matching HTTPS method or publish the file at the HTTP path required by the order.

FAQ:

Glossary:

DCV

Domain Control Validation, the proof that a certificate requester controls or is authorized to use a domain name.

Authorization domain

The exact domain or eligible parent domain where a CA accepts the DNS or website proof.

Random value

A CA-provided token that must appear in the required DNS record, CNAME target, or proof file.

Request token

A validation value assembled from CSR hashes, a CA domain string, and sometimes a unique value.

CSR hash

An MD5 or SHA-256 digest derived from the DER-encoded certificate signing request for Sectigo hash-based validation.

Transport issue

A reachability, resolver, redirect, TLS, timeout, or target-safety problem that prevents proof content from being checked cleanly.