On 10/26/23 14:37, jacopo.r0...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
