pebble: Certificate request subject commonName domain is not taken into account
RFC8555 tells:
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.
When the subject of the CSR has CN=abc.dom.org and the subjectAltName has only DNS:xyz.dom.org, by the RFC an order must be created with both abc.dom.org and xyz.dom.org as identifiers. After making the order ready, the submitted CSR is not accepted with the following error:
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Order includes different number of DNSnames identifiers than CSR specifies",
"status": 403
}
For reference see: https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 15 (5 by maintainers)
Commits related to this issue
- Include the domain in the SAN of the CSR Allows autocert to work with Pebble (see https://github.com/letsencrypt/pebble/issues/304). — committed to trevordixon/crypto by trevordixon 4 years ago
- Include the domain in the SAN of the CSR Allows autocert to work with Pebble (see https://github.com/letsencrypt/pebble/issues/304). — committed to trevordixon/crypto by trevordixon 4 years ago
- Include the domain in the SAN of the CSR Allows autocert to work with Pebble (see https://github.com/letsencrypt/pebble/issues/304). — committed to trevordixon/crypto by trevordixon 4 years ago
- Include the domain in the SAN of the CSR Allows autocert to work with Pebble (see https://github.com/letsencrypt/pebble/issues/304). — committed to trevordixon/crypto by trevordixon 4 years ago
- Include the domain in the SAN of the CSR Allows autocert to work with Pebble (see https://github.com/letsencrypt/pebble/issues/304). — committed to trevordixon/crypto by trevordixon 4 years ago
- acme/autocert: include the domain in the SAN of the CSR More compliant with the spec and allows autocert to work with Pebble (see letsencrypt/pebble#304). Fixes golang/go#39746. Change-Id: I0f41d5b... — committed to golang/crypto by trevordixon 3 years ago
- acme/autocert: include the domain in the SAN of the CSR More compliant with the spec and allows autocert to work with Pebble (see letsencrypt/pebble#304). Fixes golang/go#39746. Change-Id: I0f41d5b... — committed to LewiGoddard/crypto by trevordixon 3 years ago
- acme/autocert: include the domain in the SAN of the CSR More compliant with the spec and allows autocert to work with Pebble (see letsencrypt/pebble#304). Fixes golang/go#39746. Change-Id: I0f41d5b... — committed to BiiChris/crypto by trevordixon 3 years ago
The above looks good, thanks for hashing it out! It sounds like maybe a useful addition to Pebble would be for it to have a more explicit error in this case. For instance, “The CSR’s Subject commonName contains a domain name that is not in the subjectAlternativeNames of the CSR.”
What do you think?
@bruncsak looks much better IMO 😃
So here is the patch to my client, fixing the comments: https://github.com/bruncsak/ght-acme.sh/commit/3d46cf6aa3377a113bd36ec95cdce509e3533b50
Oh, I see what you mean. All ACME servers are compatible with RFC8555, but different additional restriction on the CSR are not excluded which leads to incompatible behavior. So my code is correct and needed, just the comments are misleading.