HTTP Practical Demonstration DCV method common mistakes

To validate your domain using the HTTP Practical Demonstration DCV method, you need two items:

  1. A random value (provided by DigiCert)
  2. The URL or location where you need to place the fileauth.txt file with the random value on your website (e.g., http://[yourdomain.com]/.well-known/pki-validation/fileauth.txt)

The URL (http://[yourdomain.com]/.well-known/pki-validation/fileauth.txt) 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 fileauth.txt file you add the generated random value to.

Below are some of the more common issues we run into when troubleshooting reasons the HTTP Practical Demonstration check fails. The HTTP Practical Demonstration DCV process is designed to keep an unauthorized individual from using a domain they do control to validate and get a certificate for a domain they don't control, such as one of yours.

Don't modify the DigiCert-provided URL

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, with this URL: [http://yourdomain.com]/.well-known/pki-validation/fileauth.txt, don't add www to it ([http://]www.yourdomain.com]/.well-known/pki-validation/fileauth.txt), or capitalize a letter that wasn't capitalized in the original URL ([http://[yourdomain.com]/.well-known/PKI-validation/fileauth.txt).

Don't place the fileauth.txt file on a different domain or subdomain

To complete domain control validation for yourdomain.com, place the fileauth.txt file on the exact domain you want validated. We won't look at a different domain or subdomain to find the random value. We only look at the domain you want to have validated (i.e., the domain in your certificate order).

For example, if you need [yourdomain].com validated, you will use this URL for this domain: http://[yourdomain].com/.well-known/pki-validation/fileauth.txt. Don't place the fileaut.txt file on sub.[yourdomain].com or modify the URL and place it on [yourotherdomain].com -- it won't work. We can't find the fileaut.txt file on these domains. We are looking for it on [yourdomain].com, the domain from your certificate order.

[your-domain] and www.[your-domain]

To validate www.[your-domain] and [your-domain], you must place the fileauth.txt file on both www.[your-domain] and [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.

Free base domain SAN

If you received a free base domain SAN on your SSL/TLS 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.

Don't include additional content in the fileauth.txt file

When you create the fileauth.txt file, copy the DigiCert-provided random value and paste it into the file. Don't add the word "token", "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 fileauth.txt file on a page with multiple redirects

When using the HTTP Practical Demonstration DCV 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 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. You can 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 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.