Alternative DCV Checker

Introduction

Domain control validation, usually shortened to DCV, is the proof a certificate authority asks for before it issues a certificate. In practice that proof can live in DNS, at a web path, or in a provider-specific hash pattern that is easy to mistype when you are working quickly or validating a long SAN list.

This checker turns that proof into one repeatable batch test. You can start with a manual hostname list or a pasted certificate signing request, choose a CA-style profile, preview the exact record name or file path that should exist, and then test the enabled DNS, HTTP, and HTTPS methods in one run.

The page is most useful when you need to know whether a hostname is fully ready, only partly ready, or blocked by a transport problem before you trigger real CA validation. The Verdict, Ready via, and Recommendation fields make that distinction visible across a batch instead of leaving you to compare raw DNS answers and page responses by hand.

It also understands several provider-specific patterns. Sectigo's CSR-hash CNAME and file methods depend on MD5 and SHA-256 values derived from the CSR, while DigiCert's practical methods rely on _dnsauth CNAME records or /.well-known/pki-validation/fileauth.txt. The checker previews those names, targets, and paths before it runs.

This is still a readiness check, not a CA simulator. It can tell you whether the configured proof is visible over the methods you enabled, but final issuance still depends on the CA's own polling, status-code rules, timing windows, and policy decisions.

Technical Details:

The checker builds one expected proof signal from the selected profile, token, and optional CSR, then applies that expectation separately to DNS, HTTP, and HTTPS. CSR parsing happens in the browser. The parser extracts the subject common name and SAN DNS names, computes MD5 and SHA-256 from the DER-encoded request, and uses those values in the Sectigo hash-based profiles.

That behavior matches how the current profiles are meant to be used. A PKCS #10 certification request contains the subject name, public key, and optional attributes, while current Sectigo guidance uses CSR-derived MD5 and SHA-256 values for its hash-based CNAME and file methods. DigiCert's current DNS CNAME guidance uses a static _dnsauth host label, and its practical website method checks for a token in fileauth.txt.

DNS checks run from the browser through DNS-over-HTTPS using Cloudflare or Google. The DNS name template supports placeholders such as {domain}, {auth_domain}, {csr_md5_upper}, {csr_sha256_split}, and {token}. If Walk parent domains is enabled, the checker tries shorter Authorization Domain candidates from left to right until it finds a match or reaches the configured depth.

HTTP and HTTPS checks build a URL from the chosen path template and send the request through the site's server-side fetch helper. That helper only allows public http and https targets on ports 80 and 443, rejects localhost and private IP space, limits the captured body to 65,000 bytes, and follows up to six redirects only when they stay on the same hostname. The response is then evaluated against the expected token or required terms.

Everyday Use & Decision Guide:

Pick the validation profile that matches the CA path you actually plan to use. If the certificate order will be validated with a DigiCert CNAME, start there. If you are preparing a Sectigo CSR-hash file check, load the CSR first. Turning on extra methods can be useful for diagnostics, but it can also create noise when the operational question is only about one sanctioned path.

The preview lines matter before the live check starts. Current signal contract tells you the DNS name, Path, Expected target, or required body terms the tool will look for. If those previews already look wrong, a failing run is only confirming a bad expectation, not discovering a new problem.

• Use a CSR whenever you are testing Sectigo hash-based methods. That avoids hostname typing errors and builds the exact MD5 and SHA-256 values the profile expects.
• Read Readiness Brief first for a batch. The coverage cards tell you whether the run is mostly clean, partly usable, or dominated by Signal mismatch and Transport issue outcomes.
• Open Request Evidence for the failing hostname next. Values, Missing, Preview, and Final URL usually explain the problem faster than the top badge alone.
• Keep Validate TLS off only when that matches the real situation, such as serving the right file before the final trusted certificate is installed. A content match with TLS validation disabled is not the same as a healthy public HTTPS deployment.
• Raise Concurrency only after the expectation is clearly correct. The current tool clamps concurrency from 1 to 20 and Max domains from 1 to 120, so it can scale, but a shared upstream fault will also fail faster at higher parallelism.

The default workflow for most people is simple: choose the right profile, confirm the previews, run the batch, read the Verdict and Ready via columns, then use the Recommendation and request-level evidence to decide whether you need a DNS change, a file-content change, a redirect fix, or a TLS fix.

Responsible Use Note:

This checker is meant for public certificate-validation targets, not for private or internal-only names. CSR parsing and signal construction stay in the browser, but DNS queries go to the selected public DNS-over-HTTPS resolver and HTTP or HTTPS checks go through the site's server-side fetch path. If a hostname, path, or token should not leave your private environment, do not test it here.

The helper is intentionally conservative: it refuses localhost, private IP space, and non-80 or 443 ports. That makes it better suited to public issuance troubleshooting than to general web crawling or internal validation. It also means a clean result here still does not replace the CA's own multi-perspective checks, retry timing, or issuance policy.

Step-by-Step Guide:

1. Choose the validation profile that matches the CA method you are preparing for.
2. Paste a CSR if the profile depends on CSR hashes, then use Extract domains & hashes to fill the hostname list.
3. Enter the token or uniqueValue if that profile requires one.
4. Check the preview lines and the Current signal contract panel before you run anything.
5. Adjust Advanced settings only when you need them, especially resolver choice, redirect following, TLS validation, timeout, concurrency, or parent-domain walking.
6. Run Check readiness and read Method Evidence for the headline verdicts.
7. Use Request Evidence, then export CSV, DOCX, or JSON if the result needs to move into an issuance ticket or handoff.

Interpreting Results:

The main reading job is to separate content problems from transport problems. A path can answer and still be wrong, which becomes a mismatch. A path can also fail before the checker gets a clean comparison, which becomes a transport issue. Those are different fixes.

The per-method cells give the short version. DNS can show a direct match against a name or a mismatch against the returned values. HTTP and HTTPS can show a match, a mismatch with the returned status code, or an error such as timeout, redirect_host_mismatch, or fetch_failed. The request-level panel then shows the supporting details.

Do not read Ready via as automatic CA approval. It only tells you which enabled methods matched in this run. If the CA will validate only one method, that specific method still has to be the clean one.

Worked Examples:

Sectigo DNS CNAME comes back fully ready

A CSR for example.com produces an MD5 value of C7FBC2039E400C8EF74129EC7DB1842C and a split SHA-256 target ending in .sectigo.com. With the Sectigo DNS CNAME profile selected, the row for example.com shows Verdict = All enabled ready, Ready via = DNS, and the DNS cell shows Match (_C7FBC2039E400C8EF74129EC7DB1842C.example.com). That is the cleanest sign that the hash-based DNS path is in place.

HTTP is ready, strict HTTPS is not

A team checks portal.example.com with the Sectigo HTTP/HTTPS file profile and leaves Validate TLS on because the final certificate should already be live. The file under /.well-known/pki-validation/<MD5>.txt contains the right body terms over plain HTTP, but the HTTPS endpoint still presents a bad certificate. The row shows Verdict = Fallback ready, Ready via = HTTP, HTTP = Match (200), and HTTPS = Error: fetch_failed. That means the content is ready while the strict HTTPS path still needs certificate repair.

The file answers, but the token is stale

With the DigiCert fileauth.txt profile, the token is 4z8p1kq2 and the target host is billing.example.com. The site returns HTTP 200 from the HTTP /.well-known/pki-validation/fileauth.txt path on that host, but the file still contains yesterday's token. The row shows Verdict = Signal mismatch, HTTP = Mismatch (200), and the Missing field in Request Evidence lists 4z8p1kq2. The next fix is content, not routing.

A redirect breaks the allowed path

A custom run checks shop.example.com with HTTP only, token ABCD-90210, and Follow redirects enabled. The first URL redirects to an HTTPS URL on www.example.com, a different hostname. The row shows Verdict = Transport issue, HTTP = Error: redirect_host_mismatch, and the Recommendation says to keep redirects on the same hostname or disable redirect following. That is a pathing problem, not proof that the token itself is wrong.

FAQ:

Glossary:

DCV

Domain control validation, the process a CA uses to confirm control of a hostname before issuance.

Authorization Domain Name

The domain level at which a CA accepts the proof record, which can be the full hostname or a shorter parent domain depending on the method.

CSR

Certificate signing request. In this tool it can supply hostnames and, for Sectigo profiles, the hashes used to build the expected proof.

DoH

DNS-over-HTTPS, a way to send DNS queries over HTTPS rather than the older DNS transport path.

uniqueValue

An optional CA-provided token segment that some Sectigo methods append to the CSR-derived target or file content.

References:

• Baseline Requirements, CA/Browser Forum.
• Domain Control Validation (DCV) Guide, Sectigo.
• Alternative Methods of Domain Control Validation (DCV) Quick Summary CNAME, Sectigo.
• DNS-based DCV methods, DigiCert, March 11, 2026.
• Validate a domain using the HTTP Practical Demonstration DCV method, DigiCert, November 3, 2025.
• RFC 8484: DNS Queries over HTTPS, RFC Editor, October 2018.
• RFC 2986: PKCS #10 Certification Request Syntax Specification, RFC Editor, November 2000.