Troubleshooting HTTP File Based Domain Control Validation (DCV)

HTTP file based Domain Control Validation (DCV) looks simple, a small file at a known path, yet it fails more often than any other validation method, and almost always for one of a handful of reasons.

This guide works through those reasons in the order they actually occur, assuming the file itself has already been created according to the setup instructions. Learn About File Based Authentication 🔗

The File Sits in the Wrong Place

The verification file must be reachable under the well-known validation path of the domain, at /.well-known/pki-validation/, and nowhere else counts. A file accidentally placed in the site root, or in a well-known folder missing the pki-validation level, returns a not found response to the Certificate Authority (CA) and the check fails silently from your perspective.

Test the exact address in a browser or with curl before expecting validation to pass. The full file contents should come back, not a redirect, an error page, or an empty response.

Coverage Includes www but the File Does Not

When the SSL Certificate covers both the root domain and the www subdomain, the file must be reachable at both locations. Serving it only at the root quietly excludes the www name at issuance, which is one of the most common and least obvious failures of this method.

Sites where root and www serve identical content usually pass both automatically, while split configurations need the file deployed twice.

Redirects Get in the Way

Sitewide redirect rules frequently sweep the validation path along with everything else. A redirect from HTTP to HTTPS is generally tolerated when it stays on the same domain, but redirects to a different hostname, a country-specific site, or a login page break the check outright.

Exclude the well-known path from redirect rules, serve the file, and restore the rules after issuance when policy demands it.

Security Layers Block the Checker

A Web Application Firewall (WAF), a bot challenge page, or geographic blocking can all return something other than the file to an automated visitor. Validation requests now also arrive from multiple network perspectives worldwide under Multi-Perspective Issuance Corroboration (MPIC), so a file reachable from your own country but blocked elsewhere still fails. Learn About Multi-Perspective Issuance Corroboration (MPIC) 🔗

Allow the validation path through these layers for the duration of issuance, then retighten.

Past placement and reachability, the file itself becomes the suspect.

The Content or Encoding Is Off

The file contents must match the issued instructions exactly, and invisible problems count. A byte order mark added by a Windows editor, trailing whitespace, or smart quotes introduced by a word processor all change the bytes on the wire. Recreate the file in a plain text editor when in doubt.

Case matters in the filename as well, since the name derives from a hash and must match character for character on case sensitive servers.

The Domain Itself Cannot Be Resolved

Validation begins with a DNS lookup, so a domain whose name servers are unreachable from the wider internet never gets as far as the file. Certification Authority Authorization (CAA) records are also checked on every issuance, and a DNS configuration that fails CAA lookups blocks issuance even with a perfect file in place. Learn About CAA Records 🔗

When Everything Checks Out

If the file is reachable at every covered name, free of redirects and blocks, and byte-exact, validation normally completes shortly after the next check. Progress is always visible against your order in the tracking system, which is the quickest way to confirm whether the check has passed. View Our Tracking & SSL Management 🔗