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


Comodo: What is the DCV challenge DCV?

The DCV challenge -standing for Domain Control Validation- is a procedure to let us know that the person requesting a certificate is dully authorized to do so by the domain's technical manager. It is an additional vetting .
The validation of the DCV challenge sets the certificate issuance.

The different kinds of DCV challenge

You can choose among several kinds of DCV challenge when placing your certificate orders:

The DCV E-mail

It is quite simple: an e-mail -carrying a security code- is sent to an e-mail address visible 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 e-mail addresses list depends on the requested FQDN (Internet address to be secured and provided in the CSR) of the order form (test it here now).
If none of those e-mail addresses is valid you can edit the contact information of your domain name's registration data via your domain name supplier.

You can also modify the address during the final vetting. This address can be changed on your certificate status page as well.

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'll actually be able to receive e-mails on one of the generic addresses above. Run some tests by sending e-mails to those addresses.
Make sure as well that your anti-spam system won't hold e-mails from dcv@tbs-dcv.com.

If you are not the recipient of any of those addresses ask the persons who are to forward the DCV e-mails to you.

But we do advise to create an e-mail address not existing yet (administrator@dom.ain?) that would point directly at you. You'll save a lot of time and won't have to wait for someone to forward you the e-mail.

If you are a supplier requesting a certificate for one of your customers you'll have to pass the information on. If you manage their domain names as well make sure there is a redirection from the generic address to your customer e-mail address.

When is this e-mail sent?

The DCV e-mail is sent when the audit process is over and right after the final vetting phone call. It is sent after the vettings for a reissuance.
From your certificate status page you can follow the audit progress and have the e-mail re-sent to the selected address.

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

The DCV HTTP

Introduced in June 2012, the DCV HTTP validation is a new alternative to the DCV e-mail.

How does it work?

While placing your certificate technical request, a file is created from your CSR. Place this file in the .well-known/pki-valiation/ sub-directory of your website (the file must be reachable via internet in HTTP). After the final vetting phone call, a robot will check the presence and the content of this file. If everything is consistent with the information you provide during the order, the certificate is automatically delivered.

Please note: This file is created at the order. If a CSR correction is requested during the audit process, a new file will be generated. It will then be available from your certificate's status page.

Please also note that a new unique value is generated at each request so a reissue or renewal using the same CSR will contain a new file to deploy.

As well: Let's imagine you want a certificate to secure subdom.domain.com, the robot will search for the file in the .well-known/pki-valiation/ sub-directory of subdom.domain.com. For multi-site certificate securing several sub-domains, one file will have to be placed in the .well-known/pki-valiation/ sub-directory of each sub-domain.

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.

Case of wildcard SANs and certificates : the file must be placed in the .well-known/pki-valiation/ sub-directory of the domain to be secured. Example: if you want to secure *.dom.domain.com, the file will have to be found under dom.domain.com/.well-known/pki-valiation/.

This file must have a .txt extension, must not be renamed nor edited.

In case of reissuance or renewal

The .txt file depends entirely on the CSR. Any operation requiring the creation of a new pair of keys will lead to the creation of a new file and the DCV will have to be validated again. On the other hand, if the keys remain the same the file won't change either. So no new handling will be requested for a renewal using the original order CSR.

IP addresses of Sectigo servers

Need to configure authorizations for the HTTP file access? Here are the IP addresses of Sectigo servers:

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

The DCV HTTPS

The DCV HTTPS works operates on the exact same basis then the DCV HTTP. The only difference is that the file must be reachable in HTTPS.

Nota: It does not matter that the already installed certificate is valid or not, is a self-signed one, or that it has been issued by an unrecognized certification authority.

The DCV DNS - The specialist's solution

It is a technical handling that aims to add a CNAME entry to your server DNS configuration. Once the final vetting phone call done, a robot checks those parameters then delivers the certificate if the data is consistent.

How does it work?

At your certificate request submission, your CSR is hashed, a new unique and secret value is added, and the resulting values will be provided to configure your sever using the following format:

{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 chose a hosting company such as OVH or GANDI,the configuration will not be taken into account instantaneously. It takes from 10mn to an hour for the modification to be effective (not to mention the propagation time defined in your DNS configuration: TTL).

Furthermore, if a CSR modification is requesting during the audit, then the new one will also be hashed. You will then have to update your server configuration will those new values.

Please also note that a new unique value is generated at each request so a reissue or renewal using the same CSR will contain a new file to deploy.

Specific procedures

Multiple site certificates

The rule concerning multiple site certificate is quite simple:

1 FQDN = 1 DCV

Yet processes have been created to limit technical handling for both DCV e-mail and DCV HTTP validations.

Example: If you used the same e-mail address to register several FQDNs, you'll receive one e-mail for those FQDNs.

Nota: DCV validations for each FQDN are independents meaning you can choose the DCV e-mail for one FQDN and DCV HTTP for an other.

From your certificate status page you will also be able to switch DCV validation methods once the order placed.

How to relaunch the DCV challenge?

No matter the type of DCV challenge you selected, it is always possible to be relaunched (either by asking for the e-mail to be sent again or for the robot to check again the .txt file or the DNS configuration).

To do so, go on your certificate status page and click on the 'Follow up on DCV challenge' button.

Which products are concerned?

All TBS X509 and Comodo certificates. The procedure is applied to new orders, renewals or reissuances.

DCV DNS, HTTP and HTTPS: The robot schedule

If, during its first visit, the robot does not find the file, it comes again regularly:

  • 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)