[edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

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?

Thank you very much!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110111): https://edk2.groups.io/g/devel/message/110111
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 1817 bytes --]

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[Laszlo Ersek]

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

How exactly did you configure your VM (runnig presumably ArmVirtQemu or
OVMF) to accept the root certificate?

See the SetCaCerts() function in
"OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c".

See also the "HTTPS Boot" section in "OvmfPkg/README"

If you build OVMF with DEBUG_VERBOSE enabled (pass
"--pcd=gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel=0x8040004F" to
"build"), and attach the firmware log (search "OvmfPkg/README" for
"debugcon"), that might help with the analysis.

It's quite possible that the certificate chain you've created is not
accepted by how edk2 uses OpenSSL, but we need to check more closely to
determine that. Can you include a textual dump of your CA cert / server
cert, too?

Laszlo

> 
> 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?
> 
> Thank you very much!
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110127): https://edk2.groups.io/g/devel/message/110127
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/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 6198 bytes --]

Hi Laszlo,

First of all thank you very much for your reply!

I'm using QEMU with OVMF. All the steps to reproduce this are:

* generate the root key

> 
> openssl genrsa -out rootCA.key 4096

* create and sign the root certificate
> 
> openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out
> rootCA.crt

* Create a config file with the following content (I basically want a self-signed certificate for the IP 192.168.120.1 )

> 
> [req]
> default_bits = 4096
> default_md = sha256
> distinguished_name = req_distinguished_name
> x509_extensions = v3_req
> prompt = no
> [req_distinguished_name]
> C = US
> ST = VA
> L = SomeCity
> O = MyCompany
> OU = MyDivision
> CN = 192.168.120.1
> [v3_req]
> keyUsage = keyEncipherment, dataEncipherment
> extendedKeyUsage = serverAuth
> subjectAltName = @alt_names
> [alt_names]
> IP.1 = 192.168.120.1

* create the key
> 
> openssl genrsa -out myip.key 2048

* create the csr
> 
> openssl req -new -key myip.key -out myip.csr -config config

* sign the csr
> 
> openssl x509 -req -in myip.csr -CA rootCA.crt -CAkey rootCA.key
> -CAcreateserial -out myip.crt -days 500 -sha256

* Then, I generate the.der certificate to be installed using the UEFI UI
> 
> openssl x509 -in rootCA.crt -outform der -out rootCA.der
> 

* Then, I use the UI to install it (the rootCA.der one)

I've uploaded all the files here in case (https://drive.google.com/drive/folders/19Yo3sWZJBe43augVIFFvEXNQU8rIqGIV?usp=sharing) .

The dump of rootCA.crt is

> 
> 
> 
> openssl x509 -in rootCA.crt -text -noout
> 
> 

> 
> 
> 
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 3b:b2:13:59:44:8a:2a:d2:ba:29:a0:e9:25:e1:32:6d:5a:e6:24:7b
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
> Validity
> Not Before: Oct 25 12:45:16 2023 GMT
> Not After : Aug 14 12:45:16 2026 GMT
> Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (4096 bit)
> Modulus:
> 00:90:9f:da:83:ac:88:44:4d:5c:1e:e7:8d:21:4b:
> 98:18:c9:d9:c0:b7:db:d4:f7:e1:54:b6:e4:e5:a8:
> c7:78:1f:47:f1:09:a6:fe:b5:08:c5:75:84:c5:26:
> 6d:c9:d2:9c:86:2d:09:3b:7e:10:ee:c6:21:fe:c1:
> b1:6c:f8:84:6c:e4:9f:92:29:46:9c:98:d6:9e:60:
> 39:b9:35:6c:2c:85:11:75:6b:e1:92:64:81:43:6e:
> cc:57:c5:eb:bd:a5:d3:40:99:d5:d0:db:6a:f0:51:
> 52:ed:72:31:c4:8a:06:19:d7:d4:1b:3b:d7:fc:a7:
> c4:25:b0:54:a0:10:c3:f5:0a:7b:25:36:95:84:b4:
> a4:85:66:9c:5c:93:af:ab:0a:6f:76:12:57:ed:b5:
> e3:09:93:a6:a3:3c:cc:f7:2e:83:25:1b:d2:3c:46:
> 36:3b:0d:17:87:84:dd:2e:88:7a:bb:ad:9d:5f:62:
> 78:68:d2:46:8f:21:08:53:ba:20:c0:15:28:7b:9a:
> f7:82:5d:27:46:0c:0f:5e:48:0e:f2:75:0b:22:98:
> 32:c6:e7:b3:21:3b:a1:e6:1b:f0:63:e2:6a:b6:ff:
> 94:d7:09:52:be:38:d0:a5:96:f6:1f:bb:b5:9f:11:
> 2b:ab:1d:39:dc:88:d5:ae:79:f3:9f:8c:72:5c:6c:
> b7:a1:51:62:af:69:2e:b4:ad:85:23:85:a0:7f:6d:
> 69:18:86:bd:07:f2:25:e2:4b:db:af:32:d0:bf:c7:
> a2:32:1f:7a:c9:bc:74:11:1c:a7:fb:99:5c:33:9b:
> 98:9a:fc:94:e3:40:2f:47:a6:b0:1f:28:23:4f:66:
> 3e:e6:84:47:8c:ed:f9:d0:8f:a6:b0:b5:37:77:91:
> bd:7d:cb:c0:f4:6e:07:e3:a2:c1:2e:16:1d:60:46:
> b9:66:6b:59:f8:83:91:17:21:20:ce:58:a6:a9:5b:
> fa:32:e6:47:32:b9:e5:5d:11:a0:d0:22:1e:2c:79:
> 42:d9:e4:99:55:6c:3d:9d:b2:94:7d:b9:09:7b:e2:
> 85:a5:bc:87:9e:50:2f:09:08:f9:f9:fd:0e:95:bb:
> 35:6d:f5:10:b7:81:e5:92:79:e5:23:55:48:7f:ce:
> 3f:cd:5f:4a:68:1f:33:25:7b:06:07:f1:74:76:de:
> 32:2e:89:10:0f:53:97:85:c7:c5:8a:e1:1a:8b:d7:
> 56:3b:d6:ab:07:a7:aa:e8:94:06:ba:ba:23:a5:87:
> f1:e1:fd:a6:2b:d0:63:54:f6:68:c2:be:d3:1a:d2:
> eb:6c:28:65:dd:c3:97:cb:23:d2:9e:f7:49:3e:da:
> 50:bf:98:0b:ec:96:50:9d:c4:4c:e7:81:05:ff:8c:
> 9a:ea:29
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> 31:18:EA:B2:10:C7:11:64:D6:5E:39:91:91:BE:D6:A4:10:24:9D:69
> X509v3 Authority Key Identifier:
> 31:18:EA:B2:10:C7:11:64:D6:5E:39:91:91:BE:D6:A4:10:24:9D:69
> X509v3 Basic Constraints: critical
> CA:TRUE
> Signature Algorithm: sha256WithRSAEncryption
> Signature Value:
> 37:76:7a:0c:12:d2:37:91:5a:8f:5a:20:34:bb:f5:3e:cc:f8:
> a3:e8:53:85:d8:99:2a:76:17:c5:e5:ae:fe:17:c9:f6:a1:ab:
> 15:4b:23:d8:84:f3:97:b8:c3:6c:30:1e:9f:2f:e3:3c:40:44:
> 5c:99:d3:d0:1b:47:fc:20:20:82:7c:58:61:d7:5e:fd:f4:73:
> da:a6:a1:65:e9:f9:48:b1:6f:9a:85:c6:fa:58:0e:39:78:2f:
> dd:dd:ff:ad:23:b7:df:fe:c0:a6:33:f2:25:ca:a5:2e:d9:99:
> 65:bb:6f:dc:cc:1f:23:07:99:87:fc:02:4b:fa:b6:25:34:56:
> c2:1a:2b:f2:04:8d:82:1f:d3:8c:46:32:0f:9b:32:31:b3:b5:
> d2:87:50:5e:13:f6:10:80:d2:d4:bc:b2:96:db:db:f1:c2:3a:
> f7:9c:a4:04:59:3a:db:a8:6f:f5:f0:46:7e:00:20:b9:6c:4e:
> f6:49:05:20:97:3d:73:6c:c2:2b:d6:c2:70:ea:46:cf:60:9f:
> c3:82:46:cc:ab:e0:c0:cb:b4:e5:62:72:d4:28:77:56:e9:97:
> ea:bc:d1:40:89:20:75:86:5f:1e:06:cc:d5:0f:49:dc:3a:cc:
> fe:70:32:a1:9a:d2:ab:e4:30:f4:34:5b:cc:93:02:00:26:68:
> 71:85:93:86:f7:d3:9d:91:c7:fb:21:e3:13:bd:8f:8c:05:f7:
> da:5f:8d:88:68:37:c0:5f:bc:62:94:96:bc:b3:8d:b3:d3:0d:
> 5a:47:00:a3:97:69:6b:27:d4:56:ff:c2:6c:ac:97:61:60:67:
> d3:59:dc:44:39:b0:4f:60:45:2b:0e:fc:2e:ce:a0:c0:93:4d:
> 69:f9:8b:77:15:76:0d:b3:5b:e8:a2:5a:c5:a6:55:2e:74:d8:
> 46:74:16:30:26:2c:9f:6d:49:06:1a:e4:d1:63:06:f4:be:dd:
> b0:5e:b5:c1:61:d8:3f:89:e4:96:66:bf:6d:d5:14:61:60:87:
> 32:31:61:ef:47:8a:53:61:42:35:df:d1:e0:a4:46:c6:97:ac:
> 43:06:c5:a3:bb:d0:a0:18:2a:e3:6b:6d:b5:c7:5c:19:31:ff:
> 66:f7:31:71:0f:eb:6d:db:33:f5:fe:90:bf:db:96:f7:02:60:
> 97:98:89:c5:dc:5f:80:74:6e:6b:67:ec:8b:33:1e:f2:63:05:
> 20:ee:eb:6d:2f:40:c0:2d:5a:49:8e:90:80:8b:f6:10:7d:90:
> e2:ea:72:33:90:ab:1f:76:07:41:29:3e:da:e0:58:b6:dc:81:
> 66:e1:f6:f2:0f:99:2a:71:50:bf:c2:0f:50:ab:b7:50:3b:55:
> 50:7d:eb:ba:73:2d:bb:8e
> 
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110130): https://edk2.groups.io/g/devel/message/110130
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 14292 bytes --]

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

In order to install the certificate I did something very naive:

1) I deployed an OS to the machine
2) Stored rootCA.der under /boot/efi/EFI/BOOT/

3) Restarted the machine

4) press F2 and install the certificate as it was available in the storage

5) select HTTPS boot in the boot list.

My nginx server is pretty simple, and it's configured as

server {

listen [::]:5248;

listen 5248;

server_name 192.168.120.1 ;

ssl_certificate path_to_myip.crt;

ssl_certificate_key path_to_myip.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers HIGH:!aNULL:!MD5;


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110132): https://edk2.groups.io/g/devel/message/110132
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 13340 bytes --]

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

I've enabled the DEBUG mode and I've extracted the following logs (my HTTPS server IP is 10.0.2.254 in this example)

> 
> 
> 
> >>Start HTTP Boot over IPv4
> 
> 

> 
> 
> 
> InstallProtocolInterface: BA23B311-343D-11E6-9185-5820B1D65299 7DCBA180
> .MnpAddFreeTxBuf: Add TxBufWrap 7E5DC118, TxBuf 7E5DC141
> MnpAddFreeTxBuf: Add TxBufWrap 7DBB8018, TxBuf 7DBB8041
> MnpAddFreeTxBuf: Add TxBufWrap 7DBB9818, TxBuf 7DBB9841
> MnpAddFreeTxBuf: Add TxBufWrap 7E4BB018, TxBuf 7E4BB041
> MnpAddFreeTxBuf: Add TxBufWrap 7E4BB698, TxBuf 7E4BB6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7E4BA018, TxBuf 7E4BA041
> MnpAddFreeTxBuf: Add TxBufWrap 7E4BA698, TxBuf 7E4BA6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF5018, TxBuf 7DDF5041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF5698, TxBuf 7DDF56C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF4018, TxBuf 7DDF4041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF4698, TxBuf 7DDF46C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF3018, TxBuf 7DDF3041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF3698, TxBuf 7DDF36C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF2018, TxBuf 7DDF2041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF2698, TxBuf 7DDF26C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF1018, TxBuf 7DDF1041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF1698, TxBuf 7DDF16C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF0018, TxBuf 7DDF0041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDF0698, TxBuf 7DDF06C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEF018, TxBuf 7DDEF041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEF698, TxBuf 7DDEF6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEE018, TxBuf 7DDEE041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEE698, TxBuf 7DDEE6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDED018, TxBuf 7DDED041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDED698, TxBuf 7DDED6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEC018, TxBuf 7DDEC041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEC698, TxBuf 7DDEC6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEB018, TxBuf 7DDEB041
> MnpAddFreeTxBuf: Add TxBufWrap 7DDEB698, TxBuf 7DDEB6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DB7F018, TxBuf 7DB7F041
> MnpAddFreeTxBuf: Add TxBufWrap 7DB7F698, TxBuf 7DB7F6C1
> MnpAddFreeTxBuf: Add TxBufWrap 7DB5F018, TxBuf 7DB5F041
> ...InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 7E92F420
> 
> InstallProtocolInterface: 3AD9DF29-4501-478D-B1F8-7F7FE70E50F3 7E3D2038
> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 7E3D67B0
> 
> Station IP address is 10.0.2.199
> InstallProtocolInterface: 7A59B29B-910B-4171-8242-A85A0DF25B5B 7DB5E6A0
> InstallProtocolInterface: 65530BC7-A359-410F-B010-5AADC7EC2B62 7DDECE38
> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 7DDEDD20
> InstallProtocolInterface: 00CA959F-6CFA-4DB1-95BC-E46C47514390 7DDEEE48
> InstallProtocolInterface: 1682FE44-BD7A-4407-B7C7-DCA37CA3922D 7DDEEE68
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 7DB4DC98
> HttpNotify: Event - 1, EventStatus - Success
> TlsDoHandshake SSL_HANDSHAKE_ERROR State=0x4 SSL_ERROR_SSL
> TlsDoHandshake ERROR 0xA000086=L14:R86
> HttpNotify: Event - 2, EventStatus - Aborted
> HttpNotify: Event - 3, EventStatus - Aborted
> TcpOnAppAbort: connection reset issued by application for TCB 7DDEBD18
> 
> URI: https://10.0.2.254:5248/images/bootx64.efi  Error: Could not retrieve
> NBP file size from HTTP server.  Error: Unexpected network error.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110206): https://edk2.groups.io/g/devel/message/110206
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 4279 bytes --]

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

On the other side, using curl I get

curl --cacert rootCA.crt https://10.0.2.254:5248/ --tls-max 1.2 --tlsv1.2 -vvvvv
*   Trying 10.0.2.254:5248...
* Connected to 10.0.2.254 (10.0.2.254) port 5248 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: rootCA.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=VA; L=SomeCity; O=MyCompany; OU=MyDivision; CN=10.0.2.254
*  start date: Oct 27 14:13:40 2023 GMT
*  expire date: Mar 10 14:13:40 2025 GMT
*  common name: 10.0.2.254 (matched)
*  issuer: C=AU; ST=Some-State; O=Internet Widgits Pty Ltd
*  SSL certificate verify ok.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/1.1
> Host: 10.0.2.254:5248
> User-Agent: curl/7.81.0
> Accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Server: nginx/1.18.0 (Ubuntu)
< Date: Fri, 27 Oct 2023 14:24:12 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
<
* Connection #0 to host 10.0.2.254 left intact


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110213): https://edk2.groups.io/g/devel/message/110213
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3282 bytes --]

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[Laszlo Ersek]

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 Boot (CVE-2019-14553)

  https://listman.redhat.com/archives/edk2-devel-archive/2019-October/009601.html

(See also <https://bugzilla.tianocore.org/show_bug.cgi?id=960#c45> 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 <https://hackerone.com/reports/715413>. 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 = 192.168.120.1

with just

  IP = 192.168.120.1

in the [alt_names] section of your config file?

Or even, directly specify

  subjectAltName = IP:192.168.120.1

in the config file?

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
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/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

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/009601.html.

Could you confirm this is supposed to work?

Thank you very much for your time on this, I appreciate it!

Jacopo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110367): https://edk2.groups.io/g/devel/message/110367
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 1730 bytes --]

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[Laszlo Ersek]

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/009601.html
> <https://listman.redhat.com/archives/edk2-devel-archive/2019-October/009601.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="$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="$1"
>   local SANIP="$2"
>   local STEM
>   local EXT
>
>   if test -z "$SANIP"; then
>     # File name stem consists of Common Name only. No certificate extensions.
>     STEM=svr_$CN
>     EXT=
>   else
>     # File name stem includes Common Name and IP address literal.
>     STEM=svr_${CN}_${SANIP}
>
>     # SAN IP extension in the certificate. Rewrite the ad-hoc extensions file
>     # with the current SAN IP.
>     echo "subjectAltName=IP:$SANIP" >| "$TMP_EXT"
>     EXT="-extfile $TMP_EXT"
>   fi
>   STEM=${STEM//[:.]/_}
>
>   # Generate CSR.
>   openssl req -new -nodes \
>     -subj   /CN="$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="$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 = 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 = 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
<https://drive.google.com/drive/folders/19Yo3sWZJBe43augVIFFvEXNQU8rIqGIV?usp=sharing>,
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 = AU, ST = Some-State, O = 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 = US, ST = VA, L = SomeCity, O = MyCompany, OU = MyDivision, CN = 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=IP: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 = US, ST = VA, L = SomeCity, O = MyCompany, OU = MyDivision, CN = 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



-=-=-=-=-=-=-=-=-=-=-=-
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/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] SSL handshake in HTTPS boot if the certificate was signed with a root certificate

[jacopo.r00ta]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

Hi Laszlo,

Now I see, using the script it works perfectly fine and your explanation was very clear! Thank you very much, I appreciated!

Cheers,

Jacopo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110468): https://edk2.groups.io/g/devel/message/110468
Mute This Topic: https://groups.io/mt/102201552/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 966 bytes --]