1. Home
2. /
3. TLS/SSL & S/MIME
4. /
5. Domain control validation

Domain control validation

4 min read

When ordering and renewing a TLS/SSL certificate, it will always be checked whether the applicant for the certificate is also the owner of the domain. Before the introduction of the DSGVO this was usually done by comparing the WHOIS data. Since this is no longer possible with the DSGVO, the CAs have now introduced three new authentication methods.

In the SSL manager you select the authentication method during the order process in the form section Authentication Settings. These methods are offered for authentication:

• EMAIL
• DNS
• FILE

Email

• The CA sends an authentication email to the applicant. The CA uses one of the five alias email addresses that you selected in the SSL Manager when ordering. Available for selection:

Please make sure that no greylisting is activated for the selected email address. This can cause problems with the delivery of the confirmation email.

• admin@example.com
• administrator@example.com
• hostmaster@example.com
• postmaster@example.com
• webmaster@example.com

If it is a certificate order for a subdomain within the common name, e.g. shop.example.com, identical mailboxes below the subdomain are available for selection in addition to the above alias email addresses:

• admin@shop.example.com

• administrator@shop.example.com

• hostmaster@shop.example.com

• postmaster@shop.example.com

• webmaster@shop.example.com

• The email that the CA sends to the selected email address contains a link that takes you to the confirmation page. Click on the link and confirm the data there. This completes the authentication process.
  For certificates with multiple domains (SANs), one confirmation email is sent for each FQDN. The Domain Control Validation is only complete when all domains specified in the certificate are confirmed.

The selection of the alias email address is always made only for the domain in the Common Name. Possible additional domains (SANs) automatically receive the same alias.

A re-sending of the authentication email can be initiated at any time via the SSL Manager in the order administration by clicking on the button Tools → Resend Confirmation Email.

An MX record must be set for the domain used to send the consent email.

DNS

With this authentication method, an additional DNS resource record must be created in the zone of the domain. The values of the record are displayed in the SSL Manager if the authentication method DNS is selected. After sending the certificate request, the CA queries the zone of the domain in the Domain Name System for this specific entry. If the entry exists and is correct, the authentication is completed.

Enter the values read from the SSL Manager into the DNS within 24 hours, otherwise they will expire and must be regenerated.

If the domain uses InterNetX nameservers and the SSL Manager is linked to AutoDNS, our system can automatically add the DNS record required for authentication to the DNS zone.

You can link AutoDNS and SSL Manager account in the previous SSL Manager interface via “User settings”.

For certificates with multiple domains (SANs), the DNS resource record displayed in the SSL Manager must be stored for each FQDN in the respective zone. The Domain Control Validation is only completed with the authentication of all domains specified in the certificate.

Example DigiCert:
_dnsauth.example.com

300 IN TXT "2020022813545049ntlwc1jhic911eicvqn0fk6q2zv4huzexz8si5p4jrj7jtst"

Example Comodo:
_9d0c17f937737a7ad33cac6696c6287b.example.com

300 IN CNAME 98ece627031af27a45fa3551cc060a57.da0f1240b6e3744e87b2182b56d98aeb.3p1e6w2n.comodoca.com.

The CA checks the DNS resource record at intervals and several times within 24 hours of the start of the job. In order to complete the authentication as quickly as possible, we recommend that the zone entry is, at best, stored directly when the certificate request is sent. If you use our TLS/SSL-API, our Real-time Issuance helps you.

FILE

With this authentication method, a file is stored on the web server in the directory of the domain with which the CA checks the ownership of a domain.

• Order a certificate as usual
• After the order has been accepted by the CA, switch to Request Management.
• Select the corresponding order. In the Request Details, which you can call up with the button Info, you will find information on the name, path and content of the required file in the tab Status under the item Authentication.
• Create this file with these values on the web server in the directory of the domain.
• Then call up the file in the browser to check whether everything was created correctly.
• The CA now checks several times whether the file was set correctly. Authentication is complete when the file has been successfully checked. The file can then be deleted again.

Be aware to create the entry only for the domain that is displayed in the order details. Please also note that on the server side no automatic URL forwarding to the www subdomain for the displayed path is allowed. 

Example DigiCert:
example.com/.well-known/pki-validation/fileauth.txt

FILENAME:
/.well-known/pki-validation/fileauth.txt
FILE CONTENT:
2018112007555401i23owspz4su5ry9q31j6rlhw89e4wwd2tz8jt9a0rpl36u1n

Example Sectigo:
example.com/.well-known/pki-validation/fileauth.txt

FILENAME:
/.well‐known/pki‐validation/7B01CAC706906D6B85AB18XE73307BAB.txt
FILE CONTENT:
be7c69cc03k36c69fd5e4f91256327487500bd4a507f14ab765d7fa2c8e1ebc7
comodoca.com

Note that the file name is always generated dynamically by Sectigo and must therefore be created each time. The file must be accessible via “http://”.

Note that no forwarding is active and that the file is available at the URL specified by the CA.