Re: [Acme] CSR CN contents for multiple identifiers -- from a recent implementor/integrator
Jörn Heissler <acme-specs@joern.heissler.de> Sun, 17 March 2019 08:06 UTC
Return-Path: <acme-specs@joern.heissler.de>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B494612788C for <acme@ietfa.amsl.com>; Sun, 17 Mar 2019 01:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.051
X-Spam-Level:
X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuAvFwQJUgp4 for <acme@ietfa.amsl.com>; Sun, 17 Mar 2019 01:06:51 -0700 (PDT)
Received: from lvps87-230-93-31.dedicated.hosteurope.de (kappa.tutnicht.de [87.230.93.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6DF128D0B for <acme@ietf.org>; Sun, 17 Mar 2019 01:06:50 -0700 (PDT)
Received: from [10.255.0.6] (helo=carrot.tutnicht.de) by lvps87-230-93-31.dedicated.hosteurope.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <acme-specs@joern.heissler.de>) id 1h5Qoh-00006K-90; Sun, 17 Mar 2019 09:06:47 +0100
Date: Sun, 17 Mar 2019 09:06:45 +0100
From: Jörn Heissler <acme-specs@joern.heissler.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: acme@ietf.org
Message-ID: <20190317080645.GC22283@carrot.tutnicht.de>
References: <29180.1552797359@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye"
Content-Disposition: inline
In-Reply-To: <29180.1552797359@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/kILi3sfnD9FJqIp7sC9UMSu7uGE>
Subject: Re: [Acme] CSR CN contents for multiple identifiers -- from a recent implementor/integrator
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Mar 2019 08:06:54 -0000
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.
- [Acme] CSR CN contents for multiple identifiers -… Michael Richardson
- Re: [Acme] CSR CN contents for multiple identifie… Jörn Heissler