To validate your domain using the HTTP Practical Demonstration DCV method, you need two items:
The URL does two things:
Below are some of the more common issues we run into when troubleshooting the reasons HTTP Practical Demonstration checks fail. The HTTP Practical Demonstration DCV process is designed to keep an unauthorized individual from using a domain they control to validate and get a certificate for a domain they don’t control, such as one of yours.
If you modify the URL in any way (change to the FQDN, capitalize a lowercase letter, forget to add a period, etc.), we won’t find the fileauth.txt file with our generated random value in it.
For example, if we provide you with this URL: [http://your-domain]/.well-known/pki-validation/fileauth.txt, don’t add www to it ([http://
www.your-domain]/.well-known/pki-validation/fileauth.txt) or capitalize a letter that wasn’t capitalized in the original URL ([http://your-domain]/.well-known/ PKI -validation/fileauth.txt).
To complete domain control validation for [your-domain], place the fileauth.txt file on the exact domain you want to have validated—the one we generate the URL for. We won’t look at a different domain or subdomain to find our random token. We only look at the domain you want to have validated (such as the domain on your certificate order).
For example, if you need [your-domain] validated, we generate a URL for this domain – [http://yourdomain]/.well-known/pki-validation/fileauth.txt.
Don’t place the fileauth.txt file on [sub.your-domain] or modify the URL and place it on [your-other-domain] – it won’t work. We can’t find the fileauth.txt file on these domains. We are looking for it on [your-domain], the domain from your certificate order or the domain you submitted for prevalidation.
To validate www.[your-domain] and [your-domain], you must place a unique fileauth.txt file on www.[your-domain] and another one on [your-domain]. As of November 16, 2021, you can only use the file-based DCV method to demonstrate control over fully qualified domain names (FQDNs), exactly as named. To learn more about this change, see the Domain validation policy changes in 2021 knowledge base article.
If you received a free base domain SAN on your SSL certificate, make sure to place the fileauth.txt file on the base domain. We need to validate the domain on the SSL/TLS certificate order.
When you create the fileauth.txt file, copy the DigiCert provided token value and paste it in the file. Don't add the word "token" or any other text.
We only read the first 2kb of the fileauth.txt file. Any additional text blocks us from validating your control over the domain.
When using the HTTP Practical Demonstration method for domain validation, the fileauth.txt file may be placed on a page that contains up to one redirect. With a single redirect, we are still able to locate the fileauth.txt file and verify your control over the domain.
For example, you need a certificate for http://example.com, but the page redirects to https://www.example.com. That’s okay. Place the fileauth.txt file on the http://example.com page. We will still be able to follow the single redirect to validate your control over http://example.com.
However, if you place the fileauth.txt file on a page with multiple redirects, we won’t be able to locate the file. Multiple redirects block us from locating the fileauth.txt file and validating your control over the domain.
For example, you need a certificate for http://multiple-redirect.com, but the page redirects to https://www.multiple-redirect.com, then redirects again to https://www.single-redirect.com. In this case, you must still place the fileauth.txt file on the http://multiple-redirect.com page. However, you will need to disable the second redirect (https://www.single-redirect.com) long enough for us to locate the fileauth.txt and validate your control over http://multiple-redirect.com.