picture of tbs certificates
picture of tbs certificates
Our products range

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

Once the certificate is ordered, it is possible from your status page to request the e-mail to be sent to an address present in the domain ownership title (WHOIS) on the condition that the access to the WHOIS does not request a CAPTCHA validation. There won't be any manual handling to retrieve the WHOIS e-mail addresses.

It is possible to change this address and have the e-mail resent at any time 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 nowthat you can receive e-mails on one of the generic addresses described above. Send yourself test e-mails.
Also check that your anti-spam system accepts e-mails from

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 e-mails to you.

However, we recommend that you request the creation of an address that does not yet exist ( ?) 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 e-mail is sent as soon as the request is transferred to the certification authority.
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?


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

Note: Since December 1st 2021 and a CA/B Forum decision, the HTTP or HTTPS DCV method cannot be used for wildcard certificates anymore. Only the methods by email or DNS will be proposed to you.

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 (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, the system will look for the file in the .well-known/pki-validation/ subdirectory of So for multiple site certificates securing multiple subdomains, a file must be placed in the .well-known/pki-validation/ subdirectory of each subdomain.

Also to be notedfor Sectigo product: if you want the free SAN (with or without www), you must place the file on both FQDNs. This will give, for example for, a file accessible at these two addresses:

  • http(or https)://
  • http(or https)://

If the file is not present on the concerned SAN, it will not be included in the certificate.

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.

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

In case of reissuance or renewal

A new file is created for each new request whether it is a new order, a reissuance or a renewal.

IP addresses of Sectigo servers

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

  • 2a0e:ac00:0231:8080:d00c:12ff:fe51:5511
  • 2a0e:ac00:0231:8080::/64


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 :

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

For example: CNAME

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)