Request token

A request token is the text value that Sectigo requires you to place either in a file on your web server or in a DNS response to prove control over a domain. A Sectigo validation token always contains two required components. High‑volume users or those who frequently reuse public keys will typically include a third, optional component.

Request token components

The token may contain the following information:

  1. SHA-256 hash of your PKCS#10 CSR (required) — The hash must be generated from the DER-encoded (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. sectigo.com (required) — This string binds the token explicitly to Sectigo’s validation system and helps prevent replay attacks.

  3. uniqueValue (optional) — This is an alphanumeric value that may be up to 20 characters long. You generate this value and include the same uniqueValue in your API request. A request token must not be reused across certificate orders.

If the same CSR is reused and the token is identical, the original order will fail.

Ensure token uniqueness

The request token must be unique. You can ensure this by doing the following:

  • Use a fresh key-pair for every request.

  • Request a different list of domain names in the CSR. For example, 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.

  • 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. For 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 in thr preceding information.

Add this extra unique element only if you intend to use the same CSR for multiple certificates.

Format of request token

In the following examples the MD5 hash value is always hex encoded and must always be upper-case.

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 Byte Order Mark (BOM) 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 and linefeed (CRLF, ‘\r\n’, 0x0D 0x0A) pairs.

The URL to be checked is formed in the following way: http[s]://<Authorization Domain Name>/.well-known/pki-validation/<MD5 hash>.txt.

For example, http://example.com/.well-known/pki-validation/C7FBC2039E400C8EF74129EC7DB1842C.txt can contain the following information:

c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f
sectigo.com
10af9db9tu

The third line 10af9db9tu is the optional uniqueValue parameter. If you’re not supplying a uniqueValue parameter, omit the third line.

DNS CNAME based DCV

When using DNS CNAME based DCV, the request token should appear as successive labels in the CNAME RDATA, on 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.

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.

The following demonstrates an example of using hex (base-16) encoding, and splitting the SHA-256 hash into two labels by inserting a period (.) symbol. In the middle of the SHA- 256 hash value, a DNS record may be setup as:

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

The following demonstrates an example of using hex (base-16) encoding, and splitting the SHA-256 hash into two labels. That means inserting a period (.) in the middle of the SHA-256 hash value, and including a uniqueValue, so that the DNS record may be setup as:

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

DNS TXT Random Value based DCV

When using DNS TXT random value based DCV, the random value should appear as the TXT RDATA — the value part of the DNS TXT record. The random value needs to be created under the authorization domain name.

The format is always of the form: _pki-validation.<Authorization Domain Name>. TXT <RandomValue>

_pki-validation.example.com. TXT mpMS+ypFldU3yEOTA2gbFw==