| Domain | DNS | HTTP | HTTPS | Notes | Copy |
|---|---|---|---|---|---|
| {{ row.domain }} | {{ formatCheckCell(row.dns) }} | {{ formatCheckCell(row.http) }} | {{ formatCheckCell(row.https) }} | {{ row.notes || '' }} | |
| No results. | |||||
Alternative domain control validation, usually shortened to DCV, is the proof a certificate authority asks for before it will issue a certificate. The practical problem is simple: a CA gives you a token, then expects to find that token in a DNS record or at a web path on the domain you are trying to validate. This checker turns that proof process into a repeatable multi-domain test instead of forcing you to inspect each method by hand.
The package accepts domains directly or extracts them from a certificate signing request. It then checks the expected token across DNS, HTTP, and HTTPS according to the enabled methods, summarizes which domains passed, and records transport errors separately from token mismatches. That distinction matters, because a missing token, a redirect problem, and a TLS trust problem are very different failure modes even though all three can block issuance.
A common use case is pre-issuance verification before you ask a CA to validate a large SAN certificate. Another is debugging why one validation path works while another does not. The coverage tab and JSON export make it easier to explain those results to someone else than a raw pile of curls, dig commands, and browser screenshots.
The tool is deliberately configurable. DNS checks can look for TXT or CNAME answers with a name template such as _pki-validation.{domain}. HTTP and HTTPS checks can hit a configurable path, follow redirects, and optionally skip TLS certificate validation for domains that do not yet have a trusted certificate on the destination host.
The boundary is that this is a verification helper, not a CA emulator. It checks for the expected token over the configured methods, but it does not reproduce every CA-specific retry policy, challenge timeout, or issuance rule. It is best used to catch obvious readiness problems before the real validation attempt.
Start with the token and the domains, because every other option depends on those two inputs being right. If you already have a CSR, extracting domains from it reduces typing mistakes. If you are validating a mixed set of hostnames manually, the domain textarea accepts comma- or newline-separated input and deduplicates it before the checks run.
The method toggles should match the CA workflow you are actually preparing for. DNS is useful when token proof lives in a TXT or CNAME record. HTTP and HTTPS are useful when the CA expects a file or endpoint response under a well-known path. Enabling all three can be useful for diagnostics, but it can also create noise if you only care about one sanctioned validation path.
The TLS validation switch is especially important to interpret correctly. When HTTPS checking is enabled but TLS validation is turned off, the package still fetches the HTTPS resource and checks the token, but it does not require the certificate on that endpoint to be trustworthy. That is helpful when DCV happens before the final certificate exists, but it should not be mistaken for a full HTTPS health check.
The results table is the main decision surface. A green method result means the expected token matched. A mismatch means the resource responded but did not contain what you expected. An error means the package could not complete that method cleanly at all, which may point to DNS propagation, network reachability, redirects, TLS, or helper-service issues. The coverage tab then tells you whether the problem is isolated or systemic across the checked domains.
Use concurrency, timeout, and max-domain limits pragmatically. Higher concurrency speeds up larger batches, but it can also create more simultaneous failures if a shared upstream problem exists. Timeouts that are too aggressive can turn slow-but-correct responses into false negatives.
The package works through a remote helper endpoint at function.simplified.tools/check_alt_dcv. The browser assembles a request that includes the normalized domain list, the token, enabled methods, DNS settings, HTTP path, redirect policy, TLS validation choice, timeout, concurrency, and maximum domain count. The helper then performs the configured checks and returns per-domain method results that the page summarizes.
DNS validation supports TXT and CNAME lookup modes. The DNS name template can include {domain}, which is replaced for each domain in the batch. Resolver choice currently switches between Cloudflare and Google DNS-over-HTTPS behavior, which is useful when you want to compare whether the problem is local to one resolver path or is visible across both major public resolvers.
HTTP and HTTPS validation use the configured relative path and check whether the fetched body contains the expected token. Redirect following can be enabled or disabled, and HTTPS has a separate TLS-validation toggle. That separation is deliberate: token presence and TLS trust are related but not identical checks. A domain can serve the right token over HTTPS and still fail trust validation if the serving certificate is self-signed or mismatched.
| Input or option | Package behavior | Why it matters |
|---|---|---|
| CSR extraction | Parses the CSR for common name and SAN DNS entries | Reduces domain-entry mistakes before the check begins |
| DNS type | Checks either TXT or CNAME answers for the expected token | Matches the CA-specific DNS proof style you are testing |
| DNS name template | Substitutes {domain} into the requested record name |
Supports predictable validation subdomains such as _pki-validation |
| HTTP / HTTPS path | Fetches a relative resource and searches the body for the token | Lets the same token be tested at the exact DCV path in use |
| Follow redirects | Allows or blocks redirect chains during HTTP(S) checks | Helps distinguish direct-hosting errors from redirect behavior |
| Validate TLS | Controls whether HTTPS trust failures are treated as blocking | Useful when DCV happens before the final certificate is installed |
| Outcome | What the package saw | Typical next step |
|---|---|---|
| OK | The configured method found the expected token | Use that method as a ready validation path |
| Mismatch | The method responded, but the token content was wrong or absent | Inspect the record or file content and the token value itself |
| Error | The method could not complete due to transport or helper failure | Check DNS propagation, path reachability, redirects, or TLS settings |
| Skipped | The method was disabled for this run | Ignore unless the wrong methods were enabled |
The most important distinction is between mismatch and error. A mismatch usually means the path is reachable but the token is wrong or missing. An error usually means the path could not be tested reliably at all, which is a different class of problem. The coverage panel makes that easier to see when you are working across many domains.
A DNS-only success does not mean HTTP validation is ready, and an HTTP-only success does not mean DNS validation is ready. This checker is method-specific by design, so the successful method should match the issuance path you actually intend to use.
A team pastes a CSR, extracts all SAN hostnames, and validates the same token across DNS and HTTP. The matrix quickly shows which hostnames are ready and which are still failing, without having to test every name manually.
HTTPS validation is enabled with TLS trust disabled so the package can confirm whether the file content is correct before the final certificate exists. If the token matches under that mode but fails once TLS validation is re-enabled, the next step is trust repair, not token repair.
No. It is a readiness checker that helps you spot problems before the real validation attempt.
Because the token can still be served correctly before the final trusted certificate is installed on that host.
Because they are checking different proof paths. One can be ready while the other is still misconfigured.