From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 24EC978003C for ; Sat, 28 Oct 2023 15:23:01 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=M2RGgkGocNER+kWLPhxX3a78anBJYilfRy7Vm+oUGLM=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698506580; v=1; b=aL7CWO/lx8wcp7ZdByr2buZQdNkhjryze7E3XXxUhSsMa2V0FLsjoUoPxg+d7lNNNDYGPl8a r7Kzr/sApvhdfrdbDOVrs5hISLqsAYr0YrOE+h5qzbJo27Tp1U3huCIfbvzXrOvoClBOym9++iQ Oi3K0ucUbMJKKseKw62j2JJg= X-Received: by 127.0.0.2 with SMTP id I7cgYY7687511xWJXpMoqo7U; Sat, 28 Oct 2023 08:23:00 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.19831.1698506580016350394 for ; Sat, 28 Oct 2023 08:23:00 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650--4lq-XUPMdKhGRI5YoGlVA-1; Sat, 28 Oct 2023 11:22:55 -0400 X-MC-Unique: -4lq-XUPMdKhGRI5YoGlVA-1 X-Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5A5E3811E7B; Sat, 28 Oct 2023 15:22:55 +0000 (UTC) X-Received: from [10.39.192.70] (unknown [10.39.192.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C6A652166B26; Sat, 28 Oct 2023 15:22:54 +0000 (UTC) Message-ID: <515c91c9-74e8-339e-45c5-adf0cb8d3542@redhat.com> Date: Sat, 28 Oct 2023 17:22:53 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate To: devel@edk2.groups.io, jacopo.r00ta@gmail.com References: From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: Y6bt6VMaYCjUmmBKvzDeERaUx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="aL7CWO/l"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 10/26/23 14:37, jacopo.r00ta@gmail.com wrote: > Hi there, > > I was trying to HTTPs boot a virtual machine with the following > scenario: > > 1) I have a self signed root CA /root.crt /and then I use it to sign > another self signed certificate /myip.crt /for the IP address X.X.X.X > 2) I have an NGINX server configured to use SSL with the /myip.crt > /certificate and its key. > 3) I have a UEFI virtual machine configured to HTTPs boot and trust > the CA certificate /root.crt /. > > Unfortunately the machine fails in the SSL handshake step and then the > UEFI config page is shown again. Using for example /curl --cacert > root.crt X.X.X.X /it works perfectly fine (also forcing curl to use > tls 1.2). > > In addition to that, if I do not use a root certificate for the > server's IP (i.e. I do not build a chain of certificates), the machine > boots fine. > > Unfortunately I don't have a physical server to make a real test. Is > this a missing feature, a bug, or am I doing it completely wrong? I'm responding here, because it would be difficult to answer under your further individual thread additions. (1) Please don't trim the OVMF debug log. I need to see the whole thing, from start to finish. In particular, OVMF contains fw_cfg integration with the host for setting the accepted CA certificates. By the time HTTPS boot is attempted, that may or may not have been done already. So I need to look at both parts of the log -- it's possible that your CA certificate is right, but OVMF is not considering it at all, from the time you enroll the certificate on the setup TUI. The best general approach for logs is to just attach them in whole (preferably compressed), because you don't know what I'll have to look at in it. If you don't feel comfortable sharing the full log with the list, you can send it to me off-list. (2) Your certificate generation commands look *superficially* right to me, but that's exactly where the issue may be, and I don't have to time to reproduce your exact setup. A few years ago we had an issue (a security issue) exactly around the binary IP address "subject alt name". You can read more about it here: [edk2-devel] [PATCH v2 0/8] support server identity validation in HTTPS B= oot (CVE-2019-14553) https://listman.redhat.com/archives/edk2-devel-archive/2019-October/00960= 1.html (See also and onward.) I *think* your server certificate setup satisfies row number 5 in the test matrix, and so it should work, but I can't tell without trying it myself (and I don't have time for that). So, instead I suggest that you take the certificate generator script from that comment, and go through all the test cases yourself. If you find behavior that differs from the penultimate column (that is, the "edk2 patched status" column), then we have a regression. (In particular, on row #5, the status is "accept".) If all those test cases still work fine (and your own certs don't), then your certificate setup probably contains the problem. (3) You didn't include a textual dump of your *server* certificate; that certificate could be quite relevant. (4) Your SSL error code is "L14:R86"; that just stands for ERR_LIB_SSL (decimal 20, from "include/openssl/err.h.in") and SSL_R_CERTIFICATE_VERIFY_FAILED (decimal 134, "certificate verify failed", from "crypto/err/openssl.txt"). Unfortunately, this doesn't tell us much. (5) Using cURL as the baseline is -- surprisingly -- precisely the *wrong* thing to do here. When we were working on the CVE-2019-14553 bugfix (see above), we found that the issue affected cURL as well. David Woodhouse suggested that I report it to the cURL maintainer, and I did, at . Ultimately, the maintainer decided this wasn't a security issue, but sort of a bug compatibility feature. Namely, Windows HTTPS clients older than -- if memory serves -- Windows 10 *never* consider "subjectAltName.iPAddress". Thus, HTTPS server operators that (i) have no DNS domain names assigned, yet (b) intend to serve such older Windows clients, have no choice but to put their IP addresses in *at least* their certs' Common Names -- and then they frequently don't care for setting "subjectAltName.iPAddress" at all. In turn, cURL wants to accept such server certificates (if they are otherwise valid), for compatibility. (In the test matrix, you can see these cases marked with "COMPAT/1".) Thus, edk2 is stricter than cURL, and so it's quite possible that your *server* certificate satisfies cURL, but does not satisfy edk2. In the cURL log, we find "common name: 10.0.2.254 (matched)", but that alone will not satisfy edk2. Edk2 will look for the binary "iPAddress subjectAltName" in the certificate. Now, I do see, in your "openssl" config file, the v3_req -> alt_names -> IP.1 setting, and indeed that should suffice. I expect some nuance around those parts goes wrong, though. Again, if the original test cases still work for you, then the problem is likely somewhere in your own certificate generation. ... can you try replacing IP.1 =3D 192.168.120.1 with just IP =3D 192.168.120.1 in the [alt_names] section of your config file? Or even, directly specify subjectAltName =3D IP:192.168.120.1 in the config file? Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110248): https://edk2.groups.io/g/devel/message/110248 Mute This Topic: https://groups.io/mt/102201552/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-