It's too bad RFC8555's section 7.4 elides the CSR in the POST /acme/order/TOlocE8rfgo/finalize HTTP/1.1 on page 47, or I could just decode it and see what's in it to answer my questions :-)
(I rather wish that all RFCs that include content that is the result of
cryptographic operations included the full examples (including private
keys used) in an appendix... but)
{And I'm sorry that I didn't know I should ask this question six months ago.}
Looking through the LetsEncrypt community, at least one system
requests multiple DNS names (WRONGLY) by doing:
/CN=name1;name2
As getting subjectAltName extensions into CSRs can be painful,
I would have thought that the correct answer was:
/CN=name1/CN=name2
but that seems to rejected as well. The rfc2985 reference for CSRs does not
help at all. I think maybe it should be rfc2986? In any case, 2986
does not help either.
rfc8555: Identifiers of type "dns" MUST appear either in the commonName
I'm not actually sure I know what this sentence means.
Many commercial CAs actually have you specify multiple names during the
web interface part. I think that the "dns" part applies to the SAN
only, and not the CN part.
Reading the source code to boulder it's clear that you can only get
multiple names by including multiple subjectAltName extensions.
The above sentence seems to imply they could be in CN or SAN.
If that's intended, then there is a bug in boulder.
If that's not intended, then the text needs a tweak.
..does this warrant an errata?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
