The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request.

[Coleman0701]

Hello @rmbolger,
I am sorry to bother you again. It is not question regarding your ACME client. This is rather question related to ACME server funcionality.

We've been having lots of discussions internally about this paragraph:

The CSR MUST indicate the exact same
set of requested identifiers as the initial newOrder request.
Identifiers of type "dns" MUST appear either in the commonName
portion of the requested subject name or in an extensionRequest
attribute [RFC2985] requesting a subjectAltName extension, or both.
(These identifiers may appear in any sort order.) Specifications
that define new identifier types must specify where in the
certificate signing request these identifiers can appear.

In section https://www.rfc-editor.org/rfc/rfc8555#section-7.4 of the ACME RFC.

I'll give you set of examples :)

Which examples would you validate according to the paragraph above?
(google / youtoube are just examples, it can be anything else, it is about the principal)

Example 1:

NewOrder DNS identifiers:
google.com, youtoube.com

SAN DNS in CSR:

DNS=youtube.com
DNS=google.com

CSR CNs:

CN=Google.org

=================

Example 2:

NewOrder DNS identifiers:
google.com, youtoube.com

SAN DNS in CSR:

DNS=youtube.com
DNS=google.com

CSR CNs:

CN=Ryan Bolger (not a "DNS string")

or

CN=WebServer1 (not a "DNS string")

Here I want to underline that CN can be anything - like server "identity", identity if an administrator, etc.

================

Example 3:

NewOrder DNS identifiers:

google.com, youtoube.com

SAN DNS in CSR:

DNS= youtube.com
DNS= google.com

CSR CNs:

CN = youtube.com
CN= google.com
CN = Google

================

Example 4:

NewOrder DNS identifiers:

google.com, youtoube.com

SAN DNS in CSR:
DNS= youtube.com
DNS= google.com
DNS= google.test.com

CSR CNs:

CN = youtube.com
CN= google.com

================

We might be having some difficulties understanding the meaning of the paragraph. What is your opinion?

Thank you very much for your response

P.S. Your reply wouldn't be a "decisive thing" for us. I don't want you to interpret ACME RFC, I am asking for your opinion.

[rmbolger]

Hi @Coleman0701. I agree that this section is a bit difficult to mentally parse partially because it assumes some additional knowledge about the potential contents of CSRs and the nature of ACME being a protocol that will likely be expanded upon in the future. It's also trying to account for the legacy nature of the CN field in CSRs.

How I interpret this is also based on how it seems to be implemented in the well known public ACME servers.

• The newOrder endpoint is sent a set of 1 or more "identifiers". Currently in the vast majority of cases, these are DNS names. However, there are also ACME extensions that allow for IP addresses and it's likely there will be future extensions that support additional types of identifiers.

• For DNS identifiers specifically, that same set of identifiers must exist in the CSR that is sent during finalization and those identifiers can reside in a CN field, SAN field, or both. (I could be wrong, but I don't think CSRs actually support having more than one CN in the Subject).

• (Implied by the MUST wording) Any identifiers found in the CSR that were not contained in the set from newOrder should be considered an error and rejected.

Where this gets hazy (as your examples show) is how the ACME server interprets what qualifies as an identifier or not in the CN field.

• Example 1 has a google.org CN that was not sent with newOrder which seems like an error.
• Example 2 has a Ryan Bolger CN that could not be confused with a DNS FQDN and could probably be ignored.
• Example 3 has multiple CN values, but I'm not sure this is actually possible to create. Even if it is, the Google single word CN could still potentially be interpreted as an FQDN (think of TLDs like com, net, and org) in which case, it would be an error.
• Example 4 would definitely get rejected because the explicit DNS SAN google.test.com was not included with the newOrder identifiers.

I'd be curious how Boulder or Pebble (Let's Encrypts ACME server implementations) actually respond to these examples.

[rmbolger]

If you'd like more opinions from knowledgeable folks, I'd bring up the topic on the LE Community Forums.

[webprofusion-chrisc]

You could also debate that the CSR is largely included "because it should be" as a throwback to the conventional way of ordering certificates. As most of it is discarded by ACME CAs (for domain validated certs) it could have been omitted from the ACME process altogether. I believe the reason things are ignored/discarded is because the process itself cannot validate them (but they could have been validated prior using some offline process and linked to ACME via EAB). As far as I'm aware CN has long been deprecated for domain validated certs and only the SAN list is considered authoritative.