Re: [Acme] CSR CN contents for multiple identifiers -- from a recent implementor/integrator

[Jörn Heissler <[e-mail]>]

On Sun, Mar 17, 2019 at 00:35:59 -0400, Michael Richardson wrote:
> 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.

2985 is correct:

   Attribute types that are useful especially in PKCS #10 certification
   requests are the challenge password and the extension-request
   attribute.  The attributes would be used in the attributes field of a
   CertificationRequestInfo value.


> 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.

The section in rfc8555 is indeed misleading. We all missed this bug because
everyone (but you, else you would have missed that too) knows that
multiple domain names go into the extension, not the subject.

> Reading the source code to boulder it's clear that you can only get
> multiple names by including multiple subjectAltName extensions.

You need exactly one extension, with multiple names inside. Not sure if
multiple extensions would or should work.

Example how to create a working request:


$ cat > san.cnf <<EOF
[req]
req_extensions = ext
utf = yes
prompt = no
distinguished_name = dn
default_md = sha256

[dn]
commonName = example.net

[ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.net
DNS.2 = ietf.org
DNS.3 = *.ietf.org
EOF


$ openssl req -config san.cnf -new -newkey ed25519 -nodes
Generating a ED25519 private key
writing new private key to stdout
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIC+1PEmlW9iIJPB0J02qQzqjBL5Lt8vBaNC/Huavkh4Y
-----END PRIVATE KEY-----
-----
-----BEGIN CERTIFICATE REQUEST-----
MIHVMIGIAgEAMBYxFDASBgNVBAMMC2V4YW1wbGUubmV0MCowBQYDK2VwAyEAg9zI
pMZW4ftJbRyFmg84aw0vTlsqIX5QSh/y0dZvJxmgPzA9BgkqhkiG9w0BCQ4xMDAu
MCwGA1UdEQQlMCOCC2V4YW1wbGUubmV0gghpZXRmLm9yZ4IKKi5pZXRmLm9yZzAF
BgMrZXADQQCwe/6G5L2855of3/HGF4F9en7+TnRnIv202z32WSGnjtVdPpjD7eCx
zAE6KvvjeV4LlswpiRjVQG8p2I110yIM
-----END CERTIFICATE REQUEST-----


(ed25519 only used for the brevity, not sure if it's supported
anywhere yet! Use RSA or ECC!)

base64-decode the request into example.csr
Dumped it looks like this:

$ dumpasn1 -ad example.csr
  0 213: SEQUENCE {
  3 136: . SEQUENCE {
  6   1: . . INTEGER 0
  9  22: . . SEQUENCE {
 11  20: . . . SET {
 13  18: . . . . SEQUENCE {
 15   3: . . . . . OBJECT IDENTIFIER commonName (2 5 4 3)
 20  11: . . . . . UTF8String 'example.net'
       : . . . . . }
       : . . . . }
       : . . . }
 33  42: . . SEQUENCE {
 35   5: . . . SEQUENCE {
 37   3: . . . . OBJECT IDENTIFIER curveEd25519 (1 3 101 112)
       : . . . . }
 42  33: . . . BIT STRING
       : . . . . 83 DC C8 A4 C6 56 E1 FB 49 6D 1C 85 9A 0F 38 6B
       : . . . . 0D 2F 4E 5B 2A 21 7E 50 4A 1F F2 D1 D6 6F 27 19
       : . . . }
 77  63: . . [0] {
 79  61: . . . SEQUENCE {
 81   9: . . . . OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
 92  48: . . . . SET {
 94  46: . . . . . SEQUENCE {
 96  44: . . . . . . SEQUENCE {
 98   3: . . . . . . . OBJECT IDENTIFIER subjectAltName (2 5 29 17)
103  37: . . . . . . . OCTET STRING, encapsulates {
105  35: . . . . . . . . SEQUENCE {
107  11: . . . . . . . . . [2] 'example.net'
120   8: . . . . . . . . . [2] 'ietf.org'
130  10: . . . . . . . . . [2] '*.ietf.org'
       : . . . . . . . . . }
       : . . . . . . . . }
       : . . . . . . . }
       : . . . . . . }
       : . . . . . }
       : . . . . }
       : . . . }
       : . . }
142   5: . SEQUENCE {
144   3: . . OBJECT IDENTIFIER curveEd25519 (1 3 101 112)
       : . . }
149  65: . BIT STRING
       : . . B0 7B FE 86 E4 BD BC E7 9A 1F DF F1 C6 17 81 7D
       : . . 7A 7E FE 4E 74 67 22 FD B4 DB 3D F6 59 21 A7 8E
       : . . D5 5D 3E 98 C3 ED E0 B1 CC 01 3A 2A FB E3 79 5E
       : . . 0B 96 CC 29 89 18 D5 40 6F 29 D8 8D 75 D3 22 0C
       : . }

> 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?

Yes, this does warrant an errata. "Identifiers" is plural,
but multiple dns identifiers just cannot go into the subject.
At least nobody does this.

Does "either" in the sentence mean "exactly one" or "at least one"?
It usually works to put one identifier into the subject, and all of them
into the extension.