From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.groups.io with SMTP id smtpd.web10.34.1571160495776664197 for ; Tue, 15 Oct 2019 10:28:15 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2167430ADBA1; Tue, 15 Oct 2019 17:28:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-240.ams2.redhat.com [10.36.117.240]) by smtp.corp.redhat.com (Postfix) with ESMTP id BF21260C5D; Tue, 15 Oct 2019 17:28:13 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553) To: David Woodhouse , devel@edk2.groups.io, "Wu, Jiaxin" , "Wang, Jian J" , Bret Barkelew Cc: Richard Levitte References: <20190927034441.3096-1-Jiaxin.wu@intel.com> <69774fe6-ea00-44b9-5468-c092dea6cd36@redhat.com> <8106467c9f4132c831d0aa604e897fe9d4dda12a.camel@infradead.org> <895558F6EA4E3B41AC93A00D163B727416F5D921@SHSMSX107.ccr.corp.intel.com> <777053db79600eb90a19945700293d14f4978344.camel@infradead.org> <6bb5d2f6-ec6f-1766-e19b-03fd45c1bc12@redhat.com> <9A4966EE-76CD-465C-A6CA-70DD9E38D834@infradead.org> <850a81a8-2cdc-0708-4ff7-db9825fdaedc@redhat.com> <23699ae3-10c2-037c-b3f5-ac8f5bea1fb7@redhat.com> <7962663e410ddb2652a9e3075589a1e3d6488213.camel@infradead.org> From: "Laszlo Ersek" Message-ID: Date: Tue, 15 Oct 2019 19:28:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7962663e410ddb2652a9e3075589a1e3d6488213.camel@infradead.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Tue, 15 Oct 2019 17:28:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/15/19 17:57, David Woodhouse wrote: > On Thu, 2019-10-10 at 20:03 +0200, Laszlo Ersek wrote: >> (I can't test it easily myself, as I don't even know how to create a >> server certificate with a SAN -- any kind of SAN, let alone GEN_IP.) > > I had to look it up again, but here goes... > > $ cat v3.ext > subjectAltName = @alt_names > [alt_names] > DNS.1 = lersek-test.redhat.com > IP.2 = 192.168.124.2 > IP.3 = fd33:eb1b:9b36::2 > $ openssl req -nodes -newkey rsa:2048 -keyout key.pem -out cert.csr > ... > $ openssl x509 -signkey ca-key.pem -in cert.csr -req -days 3650 -out cert.pem -extfile v3.ext I'm not familiar with this x509 invocation ("-signkey"). Thus far I've used x509 to sign self-signed certificate requests with a CA key: openssl x509 -req -in request.csr -out signedcert.pem \ -CA ca-cert.pem -CAkey ca-key.pem [-CAcreateserial] I guess "-signkey ca-key.pem" is a shorthand for the (-CA, -CAkey) pair? (I've tried to look at the manual; I couldn't say I'm wiser now.) Either way: why do we add the subject alternative names when the CA signs the request? Shouldn't the *original* certificate request state what alternative names can stand for the same subject? (I don't even understand how a CA can usefully insert such an extension; after all, it cannot be signed by the original certificate requestor!) The "openssl req" command too seems to accept "-extensions" -- why are we not required to use that? To me it seems like the only acceptable place, to add alternative names. Thanks! Laszlo