Apologies for mildly abusing the Issuance Policy category for a question about a non-LE CA.
I've recently been helping a user working with a commercial CA who was having issues with their ACME spec compliance and wildcard certs. The original issue is now fixed, but we're noticing a new oddity in their implementation and I was curious if it might be against CAB BRs.
For a typical wildcard cert order that contains an apex domain identifier and the wildcard identifier, the CA correctly returns 2 different authz URLs for the identifiers. But both authz objects have the same dns-01 token value. So the client ends up only needing to create one TXT record that satisfies both authz challenges. Then the order flow proceeds as normal and results in a valid cert with both identifiers.
So what do we think? Weird, but ok? Or BR no-no and possible mis-issuance condition?
I skimmed the current BRs and section 3.2.2.4.7 almost reads like it's specifically allowed.
Confirming the Applicant’s control over the FQDN by confirming the presence of a
Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for
either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is
prefixed with a Domain Label that begins with an underscore character.
If a Random Value is used, the CA SHALL provide a Random Value unique to the
Certificate request and
So the random value must be unique to the cert request and FQDN. But then there's a note at the end.
Note: Once the FQDN has been validated using this method, the CA MAY also issue
Certificates for other FQDNs that end with all the Domain Labels of the validated
FQDN. This method is suitable for validating Wildcard Domain Names.
And this seems to say that once you've validated the apex with the random value, you're clear to issue for sub-labels or wildcards without additional validation.
I had to look this up, because you cut off some text there. The full quote:
If a Random Value is used, the CA SHALL provide a Random Value unique to the
Certificate request and SHALL not use the Random Value after
i. 30 days or
ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of
validated information relevant to the Certificate (such as in Section 4.2.1 of these
Guidelines or Section 3.2.2.14.3 of the EV Guidelines).
So my reading is different than yours - the BR implies the random value is unique to the cert request only - not the Request + FQDN .
Checking the official definitions in the document supports this, but with a specific detail:
Request Token: A value, derived in a method specified by the CA which binds this demonstration of control to the certificate request. The CA SHOULD define within its CPS (or a document clearly referenced by the CPS) the format and method of Request Tokens it accepts.
The Request Token SHALL incorporate the key used in the certificate request.
A Request Token MAY include a timestamp to indicate when it was created.
A Request Token MAY include other information to ensure its uniqueness.
A Request Token that includes a timestamp SHALL remain valid for no more than 30 days from the time of creation.
A Request Token that includes a timestamp SHALL be treated as invalid if its timestamp is in the future. A Request Token that does not include a timestamp is valid for a single use and the CA SHALL NOT re-use it for a subsequent validation.
The binding SHALL use a digital signature algorithm or a cryptographic hash algorithm at least as strong as that to be used in signing the certificate request.
Note: Examples of Request Tokens include, but are not limited to:
i. a hash of the public key; or
ii. a hash of the Subject Public Key Info [X.509]; or
iii. a hash of a PKCS#10 CSR.
A Request Token may also be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re-use then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests. Note: This simplistic shell command produces a Request Token which has a timestamp and a hash of a CSR.
echo date -u +%Y%m%d%H%Msha256sum <r2.csr | sed
"s/[ -]//g"
The script outputs:
201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f
I tried to stress this bit above:
A Request Token that does not include a timestamp is valid for a single use and the CA SHALL NOT re-use it for a subsequent validation.
I'll let others more familiar with the CA/B rules chime in on that wildcard bit; I just wanted to point out that the token itself may or may not be reused across multiple domains in a CSR depending on how it's constructed -- and the example in the BRs definitions uses a token that is "a timestamp and a hash of a CSR", not a domain in the CSR.