Sectigo Domain Control Validation

Domain control validation, or DCV, is a method used by a CA before a certificate can be issued. It is used to verify the party making the request is in fact authorized to use the domain related to that request. This Domain control validation can be done via the following methods;

• Email challenge-response
• Creation of a file on the domain’s HTTP server
• Creation of a DNS CNAME record for that domain

Single and Multidomain certificates can be validated with any of the available DCV mechanisms. Multi domain certificates can use different mechanisms for each FQDN in the request. For orders placed via our API, the correct values are returned based on the chosen DCV method. For wildcard certificates the file validation method isn't allowed anymore since November 2021.

For File and CNAME validation it's required to use a unique DCV value, re-using the same DCV value is not allowed for Domain Control Validation from July 2017. When ordering a re-issue with the same CSR you can add an extra value (Request Token) to the request via out API or use the provided uniqueValueDcv from our API. Re-issues of certificates require re-validation, the reissue does not require revalidation of already validated FQDNs if the same CSR is used for the reissue. The DCV string is appended with the extra Request Token, so it becomes unique. Reissues of certificates require re-validation. Note: From November 2021 revalidation is required for all already validated FQDNs. 

Email Challenge-Response

When the order is placed, an email address is selected from a shortlist of acceptable options. An email is sent to that address, containing a unique validation code. The email should be received by someone in control of the domain, where they can follow a link provided in the email and enter the validation code, thus proving domain control.

The list of acceptable email addresses for any given domain are:

• admin@
• administrator@
• hostmaster@
• postmaster@
• webmaster@
• Any Admin, Registrant, Tech or Zone contact email address that appears on the domain’s WHOIS record, and is visible to our CA system.
  Note: Due to the GDPR some registrars don't show those email adresses anymore. In these cases, we can't check the e-mail addresses. To avoid possible delay in the certificate issuance, we advise you to use one of the 5 standard email addresses.

HTTP Based DCV

HTTP based DCV requires that a HTTP server runs on port 80 or that an HTTPS server runs on port 443 of the Authorization Domain Name. A firewall should allow the IP addresses '''91.199.212.148''' and '''91.199.212.132''' for access.

Two hashes of the CSR are generated before submission to Sectigo (Comodo). A plain text file is created on the HTTP/S server of the Authorization Domain Name, with one hash as the filename, and one hash within the text file itself. The content of the Request Token is generated as follows:

A CSR is generated with the CN=www.example.com The Authorization Domain Name will be example.com The CSR is hashed using both the MD5 and SHA-256 hashing algorithms.

A text file is created, containing the SHA-256 hash and the domain ‘comodoca.com’ on the next line.

c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f comodoca.com (optional request token)

The file is then named in the format: <MD5 hash>.txt and placed in the /.well -known/pki-validation directory of the HTTP server, like:

 http://example.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt

Once the order is received by Sectigo and HTTP based DCV is specified, the Sectigo CA system checks for the presence of the text file and its content. If the file is found and the hash values match, domain control is proven. The optional request token is required when ordering a renewal or reissue by using the same CSR as with a previous order. These are shown in out Control Panel with the order details and returned via our API.

Please pay attention to the following:

• Generate the hashes from the CSR before the order is submitted.
• The hashes MUST be generated from the DER-encoded (i.e. binary) version of the CSR – not the base64 PEM encoded version. Variations in the PEM encoding can cause differing hash values, whereas the hashes of the DER encoded version will remain constant.
• The file must be created using the UPPERCASE formatting of the MD5 hash, as most HTTP servers are case-sensitive. The Sectigo (Comodo) CA system will only look for the UPPERCASE hash filename.
• The file must be created with a .txt extension.
• The SHA-256 hash within the file is case-insensitive.
• You MUST use a hex (base 16) representation of the hash.

DNS CNAME Based DCV

DNS CNAME based DCV requires the creation of a unique CNAME record, pointed back to Sectigo. We look for the CNAME at every valid Authorization Domain, i.e. we start with the FQDN and then we will strip one or more labels from left to right in the FQDN and will look for the CNAME on each intermediate domain. The optional request token is required when ordering a renewal or reissue by using the same CSR as with a previous order. These are shown in the Control Panel with the order details and returned via our API.

The format of the CNAME will be:

 ‘_’<MD5 hash>.AuthorizationDomainName CNAME <SHA-256 hash>.<uniqueValue>.comodoca.com

Note the leading underscore at the start of the MD5 hash.

For example: A CSR is generated with the CN=www.example.com The CSR is hashed using both the MD5 and SHA-256 hashing algorithms.

 MD5: c7fbc2039e400c8ef74129ec7db1842c
 SHA-256: c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f 

Be aware that a hex (base-16) encoded SHA-256 hash will not fit in a single DNS label because it is too long. The SHA-256 hash should therefore be split into two labels, each 32 characters long.

To perform DNS CNAME based DCV, the following DNS CNAME record may be created before submitting the order:

 _c7fbc2039e400c8ef74129ec7db1842c.example.com CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.comodoca.com.

Or when ordering an renewal or reissue with the same CSR;

_c7fbc2039e400c8ef74129ec7db1842c.example.com CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.<uniqueValue>.comodoca.com.

Be aware that the right part of the CNAME record has to be terminated with a DOT after comodoca.com, to prevent the DNS appending the origin domain, like; ...5f26cf14f.comodoca.com.example.com

Please pay attention to the following:

• Generate the hashes from the CSR before the order is submitted.
• The hashes MUST be generated from the DER-encoded (i.e. binary) version of the CSR – not the base64 PEM encoded version. Variations in the PEM encoding can cause differing hash values, whereas the hashes of the DER encoded version will remain constant.
• The file must be created using the UPPERCASE formatting of the MD5 hash, as most HTTP servers are case-sensitive. The Sectigo CA system will only look for the UPPERCASE hash filename.
• The file must be created with a .txt extension.
• The SHA-256 hash within the file is case-insensitive.
• You MUST use a hex (base 16) representation of the hash.

Generating DER based MD5 hash

To create a MD5 hash for your PEM formatted CSR, the following commands should be used:

• Convert the PEM CSR to DER format with the following OpenSSL command:

 openssl req -in csr.pem -out csr.der -outform DER

• Create the MD5 hash from the DER formatted request (depending on your OS):

 md5 request.der
 md5sum request.der