File-Based Authentication for SSL Certificates

File-based authentication is one of the Domain Control Validation (DCV) methods supported for SSL Certificate issuance and reissue. The process works by placing a small text file at a specific location on your web server, where the Certificate Authority (CA) can retrieve it over Hypertext Transfer Protocol (HTTP) to confirm that you control the domain.

This page covers how to set up file-based authentication, important requirements when your SSL Certificate covers both the root domain and the www subdomain, server configuration for common platforms, and troubleshooting steps when validation fails. Learn About The Trustico® Validation Procedure 🔗

File Placement Requirements

After you place your order, the Trustico® system will generate a unique verification file containing specific content. You will need to upload this file to your web server inside the following directory :

/.well-known/pki-validation/

This directory path is an industry standard location for domain validation files, defined by the Internet Engineering Task Force (IETF). Most web servers serve files from this location by default, which makes it the appropriate place for validation files.

Important : If your SSL Certificate covers both the root domain and the www subdomain, the verification file must be reachable at both locations.

For an SSL Certificate covering example.com and www.example.com, the file must be available at example.com/.well-known/pki-validation/ and at www.example.com/.well-known/pki-validation/. If the file is only reachable at the root, reissues will silently exclude the www subdomain from the new SSL Certificate.

If you cannot place the file at both locations, consider using Canonical Name (CNAME) based or e-mail based Domain Control Validation (DCV) instead. Both methods automatically include the www subdomain without requiring the file at the www location.

Implementation Steps

The following steps assume you have shell access to your web server. The example commands use example.com as a placeholder for your actual domain. Substitute your domain name where required.

First, create the required directory structure on your web server :

mkdir -p /var/www/example.com/.well-known/pki-validation/

The -p flag ensures that all necessary parent directories are created if they do not already exist. The command creates the full directory path in a single step.

Next, create the verification file. The Trustico® tracking system provides the exact filename, which is derived from the MD5 hash of your Certificate Signing Request (CSR), along with the three lines of content that the file must contain.

The contents of the file must include the SHA-256 hash of your Certificate Signing Request (CSR) on the first line, the text "sectigo.com" on the second line, and optionally a unique value on the third line. The exact values are provided in your order confirmation.

cat > /var/www/example.com/.well-known/pki-validation/MD5HASH.txt << EOF
SHA256_HASH_OF_CSR
sectigo.com
EOF

The content must match exactly what was provided in your order confirmation. A single character difference will cause validation to fail. The MD5HASH.txt portion of the path must be replaced with the actual MD5 hash filename provided through the tracking system.

Set the correct file permissions :

chmod 644 /var/www/example.com/.well-known/pki-validation/MD5HASH.txt

The permission setting 644 allows the file to be read by everyone but only written by the owner. This is the standard permission for web-accessible files, allowing the web server to serve the file while preventing unintended modification.

Server Configuration

Some web servers require additional configuration to serve files from the /.well-known/ directory. The configuration block depends on the web server software in use.

For Apache, add the following directive to the appropriate virtual host configuration file :

<Directory "/var/www/example.com/.well-known">
    Allow from all
</Directory>

This Apache directive specifically allows access to the .well-known folder while leaving the rest of the security configuration in place.

For Nginx, add the following location block to the appropriate server block :

location /.well-known {
    allow all;
}

This Nginx block permits access to the .well-known directory. After making changes to either Apache or Nginx configuration, the web server must be reloaded for the changes to take effect.

Troubleshooting

If validation is failing, several commands can help diagnose the cause. The first check confirms that the verification file exists and has the correct permissions :

ls -la /var/www/example.com/.well-known/pki-validation/

The command displays a detailed list of files in the validation directory, showing permissions, ownership, and file sizes. The verification file should have permissions of 644 and be readable by the web server user.

The next check tests whether the file is actually reachable over Hypertext Transfer Protocol (HTTP) from outside the server :

curl -v http://example.com/.well-known/pki-validation/MD5HASH.txt

The curl command shows exactly what the Certificate Authority (CA) sees when retrieving the verification file. A successful response shows HTTP/1.1 200 OK followed by the file contents. If the response is a redirect, error code, or different content, the validation will fail.

If the SSL Certificate covers both the root domain and the www subdomain, the same check should be repeated against the www location :

curl -v http://www.example.com/.well-known/pki-validation/MD5HASH.txt

Both responses must return HTTP/1.1 200 OK with the correct file contents for the SSL Certificate to include both names.

Web server logs can also reveal validation issues. For Apache, log entries appear in the error log :

tail -f /var/log/apache2/error.log

For Nginx, the equivalent log location is :

tail -f /var/log/nginx/error.log

These commands display real-time log entries as the validation system attempts to retrieve the file, which can help identify permission or configuration issues that block successful validation.

Security Practices

After your domain has been validated and your SSL Certificate has been issued, the verification file can be removed :

rm /var/www/example.com/.well-known/pki-validation/MD5HASH.txt

The verification file content is not sensitive, but maintaining a clean server environment is recommended. The file will only be needed again at the next reissue, when a new verification file will be generated.

Alternative Domain Control Validation (DCV) Methods

File-based authentication is one of several Domain Control Validation (DCV) methods that Trustico® supports. Other methods include Canonical Name (CNAME) based validation through your Domain Name System (DNS) records, and e-mail based validation through pre-defined administrative addresses at your domain. Each method has its own requirements and limitations, and the appropriate choice depends on the access you have to your web server, your Domain Name System (DNS) records, and your e-mail infrastructure. Learn About The Trustico® Validation Procedure 🔗

Most Popular Questions

Frequently asked questions covering file-based authentication for Domain Control Validation (DCV), the requirement to make the verification file available at both the root and www locations when the SSL Certificate covers both, server configuration for Apache and Nginx, and how to troubleshoot when validation fails.

File-Based Authentication Defined

File-based authentication is one of the Domain Control Validation (DCV) methods supported for SSL Certificate issuance and reissue. It works by placing a small text file at a specific location on your web server, where Sectigo® acting as the Certificate Authority (CA) can retrieve it over Hypertext Transfer Protocol (HTTP) to confirm that you control the domain.

Required Directory for the Verification File

The verification file must be placed inside the /.well-known/pki-validation/ directory on your web server. This directory path is an industry standard location for domain validation files.

File Placement for SSL Certificates Covering Both Root and www

If your SSL Certificate covers both the root domain and the www subdomain, the verification file must be reachable at both locations. For an SSL Certificate covering example.com and www.example.com, the file must be available at example.com/.well-known/pki-validation/ and at www.example.com/.well-known/pki-validation/. If the file is only reachable at the root, reissues will silently exclude the www subdomain.

Alternative Methods When File Placement at www Is Not Possible

If you cannot place the verification file at both the root and www locations, consider using Canonical Name (CNAME) based or e-mail based Domain Control Validation (DCV) instead. Both methods automatically include the www subdomain without requiring the file at the www location.

Server Configuration for Apache and Nginx

Some web servers require additional configuration to serve files from the /.well-known/ directory. For Apache, add a Directory directive allowing access to the .well-known folder. For Nginx, add a location block permitting access to the .well-known directory. After making changes, the web server must be reloaded for the changes to take effect.

File Permissions for the Verification File

The verification file should have permissions of 644, which allows it to be read by everyone but only written by the owner. This is the standard permission for web-accessible files, allowing the web server to serve the file while preventing unintended modification.

Testing File Accessibility Before Validation

The curl command can be used to test whether the verification file is reachable over Hypertext Transfer Protocol (HTTP) from outside your server. A successful response shows HTTP/1.1 200 OK followed by the file contents. If the SSL Certificate covers both the root domain and the www subdomain, the same test should be repeated against the www location.

Removing the Verification File After Issuance

After your domain has been validated and your SSL Certificate has been issued, the verification file can be removed. The file content is not sensitive, but maintaining a clean server environment is recommended. A new verification file will be generated at the next reissue.

Ask Trustico® Assistant

For Instant Answers - Start Here When You Have a Question or Need Help

Website Security Checks : Essential Steps to Protect Your Business Online

Website Security Checks : Essential Steps to Pr...

Keep your website secure with the SSL Certificate checks that matter most, from expiry and chain coverage to validation levels, issuance controls, and automation.

Website Security Checks : Essential Steps to Pr...

Keep your website secure with the SSL Certificate checks that matter most, from expiry and chain coverage to validation levels, issuance controls, and automation.

Installing an S/MIME E-Mail Certificate in Mozilla Thunderbird

Installing an S/MIME E-Mail Certificate in Mozi...

Import a PKCS12 E-Mail Certificate into Mozilla Thunderbird, assign it for signing and encryption, and exchange secured messages with any recipient.

Installing an S/MIME E-Mail Certificate in Mozi...

Import a PKCS12 E-Mail Certificate into Mozilla Thunderbird, assign it for signing and encryption, and exchange secured messages with any recipient.

Repackaging a PKCS12 File for macOS Keychain Compatibility

Repackaging a PKCS12 File for macOS Keychain Co...

Fix PKCS12 imports that macOS Keychain Access rejects despite a correct password by re-exporting the file with legacy compatible encryption.

Repackaging a PKCS12 File for macOS Keychain Co...

Fix PKCS12 imports that macOS Keychain Access rejects despite a correct password by re-exporting the file with legacy compatible encryption.

Fixing the IIS Binding Error - A Specified Logon Session Does Not Exist

Fixing the IIS Binding Error - A Specified Logo...

Resolve the IIS binding error stating a specified logon session does not exist by repairing the Private Key association or reimporting correctly.

Fixing the IIS Binding Error - A Specified Logo...

Resolve the IIS binding error stating a specified logon session does not exist by repairing the Private Key association or reimporting correctly.

Converting a Java Keystore to PKCS12 Format

Converting a Java Keystore to PKCS12 Format

Convert a legacy Java KeyStore (JKS) to PKCS12 with one keytool command, verify the contents, and extract PEM files for non-Java platforms when needed.

Converting a Java Keystore to PKCS12 Format

Convert a legacy Java KeyStore (JKS) to PKCS12 with one keytool command, verify the contents, and extract PEM files for non-Java platforms when needed.

The 64 Character Limit on the Common Name Field

The 64 Character Limit on the Common Name Field

Understand the 64 character limit on the Common Name (CN) field, why long hostnames fail at CSR generation, and how Subject Alternative Names solve it.

The 64 Character Limit on the Common Name Field

Understand the 64 character limit on the Common Name (CN) field, why long hostnames fail at CSR generation, and how Subject Alternative Names solve it.

1 / 6