The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request. about posh-acme HOT 3 CLOSED

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.

from posh-acme.

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

from posh-acme.

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.

from posh-acme.