link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

Domain Control Validation (DCV) Methods

Information

Article Number	000009184

Archived Date

Title	Domain Control Validation (DCV) Methods

URL Name	Domain-Control-Validation-DCV-Methods

Summary	This article explains how Domain Control Validation (DCV) is used and must be completed before issuing an SSL certificate

Description

What is DCV?
A Domain Control Validation (DCV) is used by the Certificate Authority (ie Sectigo) before issuing an SSL certificate to verify the person making the request is in fact authorized to use the domain related to that request.

After submitting your CSR, you must choose one of the three methods provided by Sectigo.
Only the domain owner or someone authorized by the domain owner may validate with Sectigo.

The 3 available methods to complete DCV are:

Email based
DNS CNAME based
HTTP/HTTPS Hashing methods.

Email Based:

Domain Control can be proven by responding to a CA/B forum approved email.
The email listed on the WHOIS record can be used for Domain Control Validation.
If the WHOIS is privatized, one of the following emails has been pre-approved by the CA/B forum to prove domain ownership:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

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.

Example : for a certificate request for an FQDN of *.mail.internal.example.com, we would look for the CNAME in these places and in this order:

mail.internal.example.com
internal.example.com
example.com
The Authorization Domain Name is the one we find it on.

Two hashes of the CSR are generated before submission to Sectigo. A CNAME DNS record is created under the Authorization Domain Name.
We call the content of the CNAME the Request Token.
The content of the Request Token is described in more detail in sections 7 and 8, below.

The format of the CNAME will be:
‘_’ <MD5 hash>.Authorization Domain Name. CNAME <SHA-256 hash>.[<uniqueValue>.]sectigo.com.

note : the leading underscore at the start of the MD5 hash.

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

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

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

Then the request is submitted to Sectigo, the presence of this CNAME DNS record is checked, and if found, domain control is proven.

When ordering a certificate through Sectigo’s web-interface

Hash values are calculated and presented via the web-interface during the order process.
They are on the same screen as the DCV email-address options.
Both the MD5 and SHA-256 hash values of the CSR are shown, and must be added to DNS as a CNAME record as the above instructions show before continuing with the order.

Note the following: Should you wish to generate Hashes on your own

Generate hashes from the CSR before the order is submitted.
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 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

HTTP/HTTPS (File Based Authentication)

HTTP based DCV requires that a HTTP server be running on port 80 or that an HTTPS server be running on port 443 of the Authorization Domain Name that exactly matches the FQDN for which the certificate is requested.
This method cannot be used for validating certificates with Wildcard names.
We follow CNAME when completing HTTP based DCV.
Two hashes of the CSR are generated before submission to Sectigo.
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.
We call this text file the Request Token .
When validating a Multi Domain Certificate using HTTP method, the file must be uploaded on each FQDNs that are designated to validated using HTTP method.

Example: A CSR is generated with the CN=www.example.com

The Authorization Domain Name should be www.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 ‘sectigo.com’ on the next line.

c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f sectigo.com

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 so:

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

Once the order is received by Sectigo and HTTP based DCV is specified, the Sectigo 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 same file should be accessible through all the FQDNs that are present in the Subject Alternative Names of the certificate request.

When ordering a certificate through Sectigo’s web-interface

Hash values are calculated and presented via the web-interface during the order process.
They are on the same page as the DCV email-address options.
Both the MD5 and SHA-256 hash values of the CSR are shown, and must be saved to the file served from your HTTP server as above before continuing with the order.

When ordering a certificate through Sectigo’s API

Generate the hashes from the CSR before the order is submitted to Sectigo.
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 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.

When the AutoApplySSL call is made , an additional parameter must be specified to indicate use of HTTP/S based DCV. This parameter is called ‘dcvMethod’ and must be set to the UPPERCASE value: HTTP_CSR_HASH for HTTP on port 80 or HTTPS_CSR_HASH for HTTPS on port 443.

Request Tokens

A Request Token is the pieces of text that we ask you to put in a file on your webserver, or in a DNS response, to indicate to us that this server really is under your control.
There are 2 pieces of information that are always in a Sectigo validation token and, if you’re a high-volume user or if you reuse public keys a lot then there will probably be a third.

1. ( required ) The SHA-256 hash of your PKCS#10 CSR.

The hash 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.
You MUST use a hex (base 16) representation of the hash.

2. ( required ) the string ‘sectigo.com’

This isn’t just because we like to see our name in lights.
This ensures that the Request Token has been generated for Sectigo to validate and thereby helps to prevent a possible replay attack on the validation process.

3. ( optional ) uniqueValue

This is an alphanumeric value that may be up to 20 characters long.
It is generated by you, the applicant, and you will need to pass this same unique value to us when you submit the CSR.

note : It is not permissible to re-use the same Request Token for more than one certificate.
This means that a subsequent order, e.g. a renewal, for a certificate which uses exactly the same CSR as the original order will fail.

There are several ways to ensure each CSR (and therefore each Request Token) is unique.

You could use a fresh key-pair for every request.
You could request a different list of domain names in the CSR. E.g. a CSR for (a.example.com, b.example.com) will be different from a CSR using the same key but with the order of the domains changed to be (b.example.com, a.example.com).
You can include other material in the CSR which is not to be part of the certificate but whose presence will be sufficient to ensure the uniqueness of the CSR.

Example : a challenge password may be included in the CSR as an attribute.

This is trivially done using the OpenSSL command line tool and specifying a challenge password when prompted, but may also be implemented in any other way to include a challenge password (or other content) as an Attribute in accordance with RFC2986.
If none of those work for you then you may specify the additional unique element to the Request Token by incorporating a uniqueValue into the request token as described above.
Remember, you only need add this extra unique element if you intend to use the same CSR with multiple certificates.

Format of Request Tokens and examples

Please note that the content of the Request Token is defined in the prior section in this document, section 7 “Request Tokens”.
Please note that in the following examples the MD5 hash value is always hex encoded and must always be upper-cased.

HTTP based DCV
When using HTTP based DCV

The Request Token should appear as successive lines in a text file.
The file should be entirely composed of characters in the US 7 bit ASCII set.
There should be no BOM (Byte Order Mark) at the start of the file.
Successive lines in the text file may be separated either by single linefeed (LF, ‘\\n’, 0x0A) characters, or by carriage return + linefeed (CRLF, ‘\\r\\n’, 0x0D 0x0A) pairs.
The URL to be checked is formed in this way: http[s]://<Authorization Domain Name>/.well-known/pki-validation/<MD5 hash>.txt

Example : http://example.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt might contain: c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f sectigo.com 10af9db9tu

note that third line (10af9db9tu), the optional uniqueValue. If you’re not supplying a uniqueValue then omit that third line.

DNS CNAME based DCV
When using DNS CNAME based DCV

The Request Token should appear as successive labels in the CNAME RDATA (i.e. the right hand side of your DNS CNAME definition).
The format is always of the form: ‘_’ <MD5 hash>.<Authorization Domain Name> CNAME <SHA-256 hash>.[<uniqueValue>.]sectigo.com.

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

Example 1:
using hex (base-16) encoding, and splitting the SHA-256 hash into two labels (i.e. inserting a ‘.’
In the middle of the SHA256 hash value), a DNS record may be setup as:

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

Example 2:
using hex (base-16) encoding, and splitting the SHA-256 hash into two labels (i.e. inserting a ‘.’
In the middle of the SHA256 hash value), and including a uniqueValue, a DNS record may be setup as:

_c7fbc2039e400c8ef74129ec7db1842c.example.com. CNAME c9c863405fe7675a3988b97664ea6baf.442019e4e52fa335f406f7c5f26cf14f.10af9db9tu.sectigo.com.

note:

You can use any method (Email/HTTP/CNAME) for validating Standard FQDNs, but you can not use HTTP method for validating Wildcard Names.
Multi-domain certificates can use a different mechanisms for each FQDN in the request.

Re-issuing / Re-issues of the certificates require re-validation.

The re-issue does not require revalidation of already-validated FQDNs if the same private key is used to generate the CSR for reissue.
If a new private key is used to generate the CSR, then the order must have DCV re-performed by one of the available methods for all FQDNs in the request before the certificate can be issued.
This will also apply to re-issues that facilitate the addition or removal of domains for multi-domain certificates.

Re-sending DCV Emails
DCV emails can be resent from within the web-interface, or via the API ‘ResendDCVEmail’.
This will resend the DCV email for single-certificate orders, and for multi-domain certificate orders all outstanding (i.e. unvalidated) FQDNs the emails will be resent.

Where a non-email DCV method has been chosen for a domain (as described in sections 4, and 5),

the ResendDCVEmail API may be used to reset the frequency at which the practical control is tested.

www. sub-domains
We no longer consider proof of control of 'www.DOMAIN' as also proving control of 'DOMAIN'.
Previously, if you ordered a certificate from us for the 2 FQDNs (www.example.com and example.com), and validated e.g. using HTTP_CSR_HASH on www.example.com, we took that to also demonstrate control of example.com. That is no longer the case . Both names should be validated using HTTP_CSR_HASH method.

Multi-domain certificates

Multi-domain certificates (MDCs, UCCs) require DCV for all domain names in all orders.
Any of the available mechanisms (email, HTTP , and DNS CNAME) can be used.
The web-based interface for this is provided once the order is placed.
Simply login to your account and locate the order.
You will be presented with a screen that allows for selection of any valid email address to validate each FQDN in the certificate.
Our system will run WHOIS lookups for all domains to provide the email addresses scraped from those records where possible.
You can use the ‘Refresh’ button to update the data on screen – large numbers of FQDNs in a single certificate will take some time for all WHOIS records to be read.
The web interface can also be used to choose the HTTP, HTTPS, or DNS CNAME mechanisms for each FQDN.

You can remove some FQDNs from the certificate if they are unable to be validated, and issue the certificate with only the domains validated to that point.

Multi-domain certificate API Details
The API can be used to request and validate multi-domain certificates via email-based DCV.
The changes to the existing API and processes for ordering are:

Instead of the ‘dcvEmailAddress’ parameter which we use for single-domain certificates, there is a ‘dcvEmailAddresses’ (note the plural) parameter.

This parameter accepts a list of email addresses to use for DCV.

There must be one email address per FQDN in the ‘domainNames’ parameter, and they must be in exactly the same order.
Unlike single certificate orders via the API, our system will not reject orders because of incorrect DCV email addresses.
They will be accepted, but no email will be sent.
They can then be edited via the web-interface.
It is important to pass only valid email addresses for the DCV email address for each domainName.
Valid email addresses can be obtained by either using one of the default 5 (listed earlier in this document), or by calling the GetDCVEmailAddressList API for that domain.
It is also possible for you to perform and independent WHOIS lookup and send an email you can extract from the output to our API.
However, please note that our system can only ‘see’ email addresses on a WHOIS lookup that is from the command-line.
Email addresses visible from web-based WHOIS queries, or any that require human challenge-response systems (e.g. CAPTCHAS) will not be usable by our system, and the order will sit awaiting verification until you login and update the DCV email address via the web-interface.

Our system will attempt to send as few emails as possible. Where several FQDNs exist within the same registered domain name, one email will be sent. The API can also be used to validate domains using the HTTP and DNS CNAME mechanisms. As above, the ‘dcvEmailAddresses’ parameter should be used.

For each domain in the ‘domainNames’ parameter, in order, you can specify one of the following:

A DCV email address as detailed in this document.
The value ‘HTTPCSRHASH’ – for this ‘domainName’ the HTTP DCV mechanism is used.
The value ‘HTTPSCSRHASH’ – for this ‘domainName’ the HTTPS DCV mechanism is used.
The value ‘CNAMECSRHASH’ – for this ‘domainName’ the DNS CNAME DCV mechanism is used.

In addition, if you wish to have all the domains validated by one of the alternative (HTTP or HTTPS or DNS CNAME) mechanisms, then simply pass a single value for the ‘dcvEmailAddresses’ parameter of:

ALLHTTPCSRHASH or
ALLHTTPSCSRHASH or
ALLCNAMECSRHASH This should be the only value passed for the parameter, and will attempt to verify all domains via the same mechanism.