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 576D6D800F3 for ; Tue, 31 Oct 2023 11:26:58 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=sIrM6Eq6OXMyynNjaqoMU4+h21GgDTCRngygisinmFY=; 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=1698751617; v=1; b=qGXpDphe9ptn5e2xJdR+GkKoYpEetGIAP7mBOrxWq0ydpxIKu8X1noAo6GocHtbkDrxo3mna Q1Q2ves4ZZgJur7iq9RJ6R33eYdOsAd8/6sXgWPxbHHH22Te/MW6LBIh3kvxIqU9xxOUGAnq//D 3AIsWWPPjFR2I7ILEwxKMnQo= X-Received: by 127.0.0.2 with SMTP id JUpxYY7687511xz5OfHpWwoh; Tue, 31 Oct 2023 04:26:57 -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.web10.183632.1698751616356818033 for ; Tue, 31 Oct 2023 04:26:56 -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-524-z9FoRiNbO4uwD1-DlKxuUA-1; Tue, 31 Oct 2023 07:26:52 -0400 X-MC-Unique: z9FoRiNbO4uwD1-DlKxuUA-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (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 041D28870A3; Tue, 31 Oct 2023 11:26:52 +0000 (UTC) X-Received: from [10.39.195.34] (unknown [10.39.195.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6C1CD10F4D; Tue, 31 Oct 2023 11:26:51 +0000 (UTC) Message-ID: Date: Tue, 31 Oct 2023 12:26:50 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate To: jacopo.r00ta@gmail.com, devel@edk2.groups.io References: <515c91c9-74e8-339e-45c5-adf0cb8d3542@redhat.com> <7135.1698732628313427950@groups.io> From: "Laszlo Ersek" In-Reply-To: <7135.1698732628313427950@groups.io> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 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: rBQHyKrAVWJ5lXgwmaxeOmT6x7686176AA= 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=qGXpDphe; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On 10/31/23 07:10, jacopo.r00ta@gmail.com wrote: > Hi Laszlo, > > If I generate the certificate like > > /openssl req -new -nodes -x509 -days 365 -keyout server.key -out > server.crt -config config / > > it works perfectly fine (with the original configuration). > > The problem stands with the *chain* of certificates, meaning that I > have a root certificate (let's call it A) and sign another one for an > IP (let's call it B). Then in the image server with such IP I set the > certificate B, and in the VM I trust the certificate A. Unless I > missed something, this scenario is not covered in > https://listman.redhat.com/archives/edk2-devel-archive/2019-October/00960= 1.html > > . > > Could you confirm this is supposed to work? Absolutely. The expectation is not to enroll the server certificate directly in OVMF, but to enroll the CA certificate. In the message you link above, the certificate generation script is embedded. There is a section that generates the CA certificate: > openssl req -x509 -nodes \ > -subj /CN=3D"$CA_NAME" \ > -out "$CA_NAME".crt \ > -keyout "$TMP_CA_KEY" and then there is a function that generates a CA-issued certificate: > # Create a CA-issued certificate. > # Parameters: > # $1: Common Name > # $2: IPv4 or IPv6 address literal, to be used in SAN; or empty string > gencrt() > { > local CN=3D"$1" > local SANIP=3D"$2" > local STEM > local EXT > > if test -z "$SANIP"; then > # File name stem consists of Common Name only. No certificate extensi= ons. > STEM=3Dsvr_$CN > EXT=3D > else > # File name stem includes Common Name and IP address literal. > STEM=3Dsvr_${CN}_${SANIP} > > # SAN IP extension in the certificate. Rewrite the ad-hoc extensions = file > # with the current SAN IP. > echo "subjectAltName=3DIP:$SANIP" >| "$TMP_EXT" > EXT=3D"-extfile $TMP_EXT" > fi > STEM=3D${STEM//[:.]/_} > > # Generate CSR. > openssl req -new -nodes \ > -subj /CN=3D"$CN" \ > -out "$TMP_CSR" \ > -keyout "$STEM".key > > # Sign the certificate request, potentially adding the SAN IP. > openssl x509 -req -CAcreateserial $EXT \ > -in "$TMP_CSR" \ > -out "$STEM".crt \ > -CA "$CA_NAME".crt \ > -CAkey "$TMP_CA_KEY" \ > -CAserial "$TMP_CA_SRL" > } As you see, this function does generate a Certificate Signing Request, and then signs it with the CA certificate. Importantly, it's the CA certificate from the first step that is supposed to be enrolled in OVMF, then. ... However, this actually makes me notice a difference, between your commands and mine! (1) In your setup, you add the Subject Alt Name IP Address when generating the CSR (note "-config config"): openssl req \ -new \ -key myip.key \ -out myip.csr \ -config config <---------- this here and then sign the CSR openssl x509 \ -req \ -in myip.csr \ -CA rootCA.crt \ -CAkey rootCA.key \ -CAcreateserial \ -out myip.crt \ -days 500 \ -sha256 (2) Whereas in my setup, the Subject Alt Name IP Address is NOT added when generating the CSR (note the lack of any "-config" option): openssl req \ -new \ -nodes \ -subj /CN=3D"$CN" \ -out "$TMP_CSR" \ -keyout "$STEM".key Instead it is added when the CA signs the CSR (see "-extfile $TMP_EXT"): openssl x509 \ -req \ -CAcreateserial \ -extfile $TMP_EXT \ <------------- this here -in "$TMP_CSR" \ -out "$STEM".crt \ -CA "$CA_NAME".crt \ -CAkey "$TMP_CA_KEY" \ -CAserial "$TMP_CA_SRL" ... Yes, I think that is exactly the problem on your end. Namely, I have now done two things: (a) I've re-run my script from the above link. From the output files, I've picked the *server* certificate called "svr_192_168_124_2_192_168_124_2.crt". This is the server certificate that has the IP address in *both* the Common Name field, *and* in the "Subject Alt Name IP Address" field. I've dumped this certificate to text form: $ openssl x509 -in svr_192_168_124_2_192_168_124_2.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 1f:1a:ac:bf:ff:56:be:04:ff:fe:49:ff:e7:8b:9d:e6:0c:8d:63:dd Signature Algorithm: sha256WithRSAEncryption Issuer: CN =3D TianoCore_BZ_960_CA Validity Not Before: Oct 31 10:57:30 2023 GMT Not After : Nov 30 10:57:30 2023 GMT Subject: CN =3D 192.168.124.2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: [...] Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: IP Address:192.168.124.2 X509v3 Subject Key Identifier: 2C:98:BC:EF:85:61:7F:05:42:8E:75:47:0B:66:80:4C:AD:3F:50:30 X509v3 Authority Key Identifier: 06:9A:9D:09:7C:11:63:6B:79:11:8B:B0:C1:7E:7A:7E:2C:98:32:0B Signature Algorithm: sha256WithRSAEncryption Signature Value: [...] Please consider especially the "X509v3 extensions" section! Under which, you will find the crucial bit X509v3 Subject Alternative Name: IP Address:192.168.124.2 (b) I have downloaded your files from , and dumped your "myip.crt" file. That is the server certificate -- the output of the signing of the Certificate Signing Request: $ openssl x509 -in myip.crt -text -noout Certificate: Data: Version: 1 (0x0) Serial Number: 73:ae:c1:b2:9f:3d:18:0f:89:07:17:d1:90:bc:cc:5b:bc:3a:bd:cb Signature Algorithm: sha256WithRSAEncryption Issuer: C =3D AU, ST =3D Some-State, O =3D Internet Widgits Pty Ltd Validity Not Before: Oct 26 17:12:26 2023 GMT Not After : Mar 9 17:12:26 2025 GMT Subject: C =3D US, ST =3D VA, L =3D SomeCity, O =3D MyCompany, OU = =3D MyDivision, CN =3D 192.168.120.1 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: [...] Exponent: 65537 (0x10001) Signature Algorithm: sha256WithRSAEncryption Signature Value: [...] Note that you don't have an "X509v3 extensions" section under Data; consequently you also don't have a "X509v3 Subject Alternative Name" section with an IP address in it. And that's precisely why edk2 rejects the server certificate. The openssl-x509(1ossl) manual page contains the following obscure, but important hint -- note the second paragraph: -req By default a certificate is expected on input. With this option a PKCS#10 certificate request is expected instead, which must be correctly self-signed. X.509 extensions included in the request are not copied by default. X.509 extensions to be added can be specified using the -extfile option. So when you run "openssl x509 -req" as quoted under (1) above, for signing the CSR, then openssl explicitly throws away any extensions that may be present in the Certificate Signing Request. You need to specify the Subject Alt Name IP Address manually when *signing* the CSR, using the "-extfile FILENAME" option, where FILENAME is supposed to contain the line subjectAltName=3DIP:YOUR_IP_ADDRESS ... Finally, I've even dumped your Certificate Signing Request "myip.csr": $ openssl req -in myip.csr -text -noout Certificate Request: Data: Version: 1 (0x0) Subject: C =3D US, ST =3D VA, L =3D SomeCity, O =3D MyCompany, OU = =3D MyDivision, CN =3D 192.168.120.1 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: [...] Exponent: 65537 (0x10001) Attributes: (none) Requested Extensions: Signature Algorithm: sha256WithRSAEncryption Signature Value: [...] As you can see, even in your CSR, the "Requested Extensions" section is empty. The "subjectAltName" stanza of your "-config" option, when you generate the CSR in step (1), is entirely ignored! In summary, any X.509 extension that you want in the final server certificate -- specifically the "Subject Alternative Name / IP Address" one -- must be added when you *sign* the CSR with the CA key, not when you *generate* the CSR. 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 (#110399): https://edk2.groups.io/g/devel/message/110399 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-