JOIN OUR AFFILIATE NETWORK

Join our affiliate network and become a local SSL expert

♦ learn more about our program ♦
Menu
picture of tbs certificates
picture of tbs certificates
Certificates
Our products range
Partners
Support
Focus


Sectigo: What is the DCV challenge?

The DCV (Domain Control Validation) challenge is used to verify that the applicant for a certificate has the agreement of the technical operator of the domain name he wants to secure. This technique is used to reinforce the security of SSL certificates, It is an additional vetting .
The validation of the DCV challenge sets the certificate issuance.

The different kinds of DCV challenge

Several DCV validation methods will be offered to you when you submit your technical orders for certificates:

The DCV E-mail

The principle is simple: an e-mail containing a security code is sent to a single address present in the domain ownership title (whois) or to one of the following generic addresses:

  • admin@dom.ain
  • administrator@dom.ain
  • hostmaster@dom.ain
  • webmaster@dom.ain
  • postmaster@dom.ain

The list of possible e-mail addresses is proposed to you according to the requested FQDN (Internet address to be secured registered in the CSR) on the order form (test here now).
If none of the emails in the list corresponds to a valid address, you can still modify the contact information entered in your domain name registration via your domain name provider.

It is possible to change this e-mail during the final verification. You will also be able to change this address and have the e-mail resent from your status page.

How to get prepared?

To pass this control, you will have to be the recipient of the DCV e-mail.

You are invited to check right now that you can receive e-mails on one of the generic addresses described above. Send yourself test emails.
Also check that your anti-spam system accepts emails from dcv@tbs-dcv.com.

If you do not usually receive any of these addresses, please inform the people who do receive them of the need to forward of the need to forward DCV emails to you.

However, we recommend that you request the creation of an address that does not yet exist (administrator@dom.ai.ne ?) and that it be sent directly to you. This way, no more time wasted waiting for the e-mail to be sent back to you.

If you are a service provider, and the ordered certificates are for your customers, you should inform them. If you also manage their domain names make sure that there is a cross-reference between one of the generic addresses described above and your customer's your customer's e-mail address.

When is this e-mail sent?

The email is sent at the end of the audit process, just after the final verification call. For reissues, the email is sent after the checks are completed.
From your certificate status page, you can follow the progress of the different steps of your file and then have this control e-mail automatically sent to the selected address.

See: What does the DCV e-mail challenge look like?

The DCV HTTP

Implemented in June 2012, the DCV HTTP validation is an alternative to the DCV E-mail validation.

How does it work?

When you submit your technical certificate order, a file is created from your CSR. Place this file in the .well-known/pki-validation/ subdirectory of your site in HTTP (the latter must be accessible via the Internet). After the final verification call, a robot will check the presence of this file and its content. If the information is consistent with the information given during the order the certificate will be delivered. Translated with www.DeepL.com/Translator (free version)

Please note The file is created when the order is placed. If a CSR correction is requested during the audit phase, a new file will be generated. You can retrieve it on the status page of your certificate.

It should also be noted that a new unique value is generated for each request, so a refactoring or renewal with the same CSR will contain a new file to deploy.

As well For example, if you apply for a certificate for ssdom.domain.com, the system will look for the file in the .well-known/pki-validation/ subdirectory of ssdom.domain.com. So for multiple site certificates securing multiple subdomains, a file must be placed in the .well-known/pki-validation/ subdirectory of each subdomain.

If you are using a Windows Server, the creation of the .well-known directory might be difficult, this is why we have published a documentation about this step.

Nota If you have enabled SNI on your server, the DCV Sectigo validation robot may not find the file even though it is in the right place.
If you have difficulties to validate the DCV, try to change the method (by email or DNS) if possible, or contact our support department.

Case of wildcard SANs and certificates The file must be placed in the .well-known/pki-validation/ subdirectory of the secured domain. Example: if you want to secure *.dom.domain.com the file should be visible under dom.domain.com/.well-known/pki-validation/.

This file must have a .txt extension, must not be renamed and its content must not be edited.

In case of reissuance or renewal

The .txt file is entirely dependent on the CSR. Any operation requiring the creation of a new key will generate the creation of a new file and the DCV validation will have to be redone. On the other hand, if the private key does not change the file remains the same, so a renewal using the original CSR will not require any new manipulation.

IP addresses of Sectigo servers

Need to set up permissions for access to your HTTP file? Here are the Sectigo IP:

  • 91.199.212.132
  • 91.199.212.148
  • 2a0e:ac00:0231:8080:d00c:12ff:fe51:5511

The DCV HTTPS

The HTTPS DCV works on the same principle as the HTTP DCV with the only difference that the file must be placed on the site in HTTPS.

Please note It doesn't matter if the already installed certificate is valid or not, self-signed or even issued by an unrecognized certification authority.

The DCV DNS - The specialist's solution

This is a technical manipulation consisting of adding a CNAME entry to the DNS (Domain Name Service) configuration of your server. Once the final verification call is made, a robot comes to check these parameters and then delivers the certificate if everything is in conformity.

How does it work?

When you submit your certificate request, your CSR is hashed, a unique and secret value is added to it and the resulting values are communicated to you for the configuration of your server which will then have the form :

{CSR MD5 hash}.FQDN CNAME {reformatted CSR SHA-256 hash}.{unique value}.comodoca.com

For example:

c7fbc2039e400c8ef74129ec7db1842c.www.mydomain.com CNAME 298a056d3e2f3018bda514defb18129dc5af459e.comodoca.com.

Warning If you use a hosting company such as OVH or GANDI, this configuration is not taken into account instantly. It takes between 10mn and one hour for the modification to be effective (without counting the propagation time defined in the configuration of your DNS: TTL).

Also, as for the DCV HTTP challenge, if the CSR is modified during the audit then it will be hashed again. You will then have to update your DNS configuration.

It should also be noted that a new unique value is generated with each request, so a reissue or renewal with the same CSR will contain a new record to deploy.

Specific procedures

Multiple site certificates

The rule concerning multiple site certificate is quite simple:

1 FQDN = 1 DCV

However, methods have been put in place to limit as much as possible the number of manipulations to be performed by the client, whether in the case of DCV E-mail or DCV HTTP.

Example If several FQDNs have the same e-mail address in their WHOIS, only one e-mail is sent to this address.

Nota The DCV validations for each FQDN are independent of each other which means that you can choose the e-mail DCV for one FQDN and the HTTP DCV for another.

Once you have submitted your application, you can also modify the DCV validation type for each site to be secured from the status page of your certificate.

How to relaunch the DCV challenge?

Regardless of the type of challenge selected, it is always possible to ask for a retry, either by resending the email, or by asking the robot to come back and check the .txt file or the DNS configuration.

Just go to the status page of your certificate and click on the button 'DCV challenge follow-up'.

Which products are concerned?

All TBS X509 and Sectigo brand certificates, on initial order, renewal and reissue.

DCV DNS, HTTP and HTTPS: The robot schedule

If, on its first pass, the robot does not find the file, then it returns regularly at set times:

  • first visit: after the final vetting phone call
  • 10 minutes after
  • 20 minutes after
  • 40 minutes after
  • 80 minutes after
  • 160 minutes after
  • 320 minutes after
  • 640 minutes after
  • 1280 minutes after
  • and every 1440 minutes (1 day)