I see different behavior domain name treated in pebble versus letsencrypt/bypass staging ACME servers. If there is a domain name in the subject of the CSR CN=… , which is not part of the SAN, letsencrypt and bypass requires validation identifier for that domain name too. However, pebble totally disregards what is in the Subject’s common name of the CSR, and replaces the subject for the certificate, having a domain name from the SAN section.
Letsencrypt’s error:
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Error finalizing order :: Order includes different number of names than CSR specifies",
"status": 403
}
Bypass’ error:
{"type":"urn:ietf:params:acme:error:badCSR","detail":"CSR and order identifiers differ","code":403,"message":"BAD_CSR","details":"HTTP 403 Forbidden"}
Pebble’s error:
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Order includes different number of DNSnames identifiers than CSR specifies",
"status": 403
}
With a specific CSR having the above qualification for a test case, I have to decide which test server to fail. Pebble or letsencrypt/bypass.
Or, my ACME client should strait refuse a CSR having a a domain only in the subject CN and not part of the SAN?
Or, do I have to put different code in my client https://github.com/bruncsak/ght-acme.sh for pebble than for the other ACME servers?
The RFC8555 is clear about this:
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.
I think that is an issue to submit to pebble development, they fail implementing that section of the RFC.