Common mistakes: HTTP practical demonstration DCV method
To validate your domain using the HTTP Practical Demonstration and HTTP Practical Demonstration with unique filename DCV methods, you need at least two items. You need a third item for the unique filename method.
A DigiCert-generated random value.
A DigiCert-generated unique filename (for HTTP Practical Demonstration with unique filename only).
The URL or location where you need to place the .txt file containing the random value on your website:
http://[domain-name]/.well-known/pki-validation/fileauth.txt.
http://{domain-name}/.well-known/pki-validation/{unique-filename}.txt
The URL does two things:
It contains the FQDN (fully qualified domain name) of the domain you want us to validate.
It tells us where to look so that we can find the .txt file with the DigiCert-generated random value..
Below are some of the more common issues we encounter when troubleshooting why HTTP Practical Demonstration checks fail. The HTTP Practical Demonstration DCV process is designed to prevent 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.
Don’t modify the URL provided
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 .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).
Don’t place the .txt on a different domain or subdomain
To complete domain control validation for [your-domain], place the .txt file on the exact domain you want 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 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 .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 .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.
[your-domain] and www.[your-domain]
To prevalidate www.[your-domain] and [your-domain], you must validate www.[your-domain] and [your-domain] separately. 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 knowledgebase article.
Free base domain SAN
If you received a free base domain SAN on your SSL certificate, make sure to place the .txt file on the base domain. We need to validate the domain on the SSL/TLS certificate order.
Don’t include any additional content in the fileauth.txt file
When you create the .txt file, copy the DigiCert provided token value and paste it in the file. Don't add the word "token", or "value", or any other text.
Because we only read the first 2kb of the fileauth.txt file, additional text blocks us from validating your control over the domain.
Don’t place the .txt file on a page with multiple redirects
When using the HTTP Practical Demonstration method for domain validation, the .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 .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 .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 .txt file on a page with multiple redirects, we won’t be able to locate the file. Multiple redirects block us from locating the .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 and 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 .txt and validate your control over http://multiple-redirect.com.