Can't assemble TLS cert chain where server includes root about ipxe HOT 5 CLOSED

Additional note from RFC 8446 § 4.4.2:

Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.

So yeah, if my understanding is correct and the issue lies with how we handle root-bearing cert chains, then the present behavior does align with the RFC, as "trust anchor MAY be omitted" certainly seems to imply "trust anchor MAY NOT be omitted".

EDIT: RFC 8446 is specifically TLS 1.3, but ipxe.org/crypto says we only support up to 1.2. Regardless, RFC 5246 § 7.4.2 for TLS 1.2 has similar implications.

from ipxe.

I haven't been able to reproduce pulling a kernel (which seems to have a very strong resemblance to html... how about that) from https://digicert.com, so I'm gonna guess that case was either a transient issue or I got some wires crossed when pruning that output. Made some decent progress, though.

I've applied some local changes to vomit some more debugging message. If we try to hit https://foo.herokuapp.com, we get:

TLS in tls parse chain
TLS 0xef004 found certificate *.herokuapp.com
TLS 0xef004 found certificate DigiCert SHA2 High Assurance Server CA
TLS 0xef004 found certificate DigiCert High Assurance EV Root CA (<--- !!!!!!)
TLS 0xef004 we done saying hello
VALIDATOR happy birthday
VALIDATOR 0xef404 "*.herokuapp.com" validating X509 chain 0xeda74
VALIDATOR step
VALIDATOR no ocsp
VALIDATOR 0xef404 "DigiCert High Assurance EV Root CA" is self-signed; we're not
 going to try to find a cross-signed cert.
TLS 0xef004 certificate validation failed: Permission denied (http://ipxe.org/02
16eb3c)

(emphasis mine). Note that the server gives us the full chain, all the way to the root (which is self-signed). Now, there's a cross-signed version of that self-signed cert that would work just fine here, but we don't even try to grab it.

If we try to hit https://www.digicert.com, we get:

TLS in tls parse chain
TLS 0xef004 found certificate digicert.com
TLS 0xef004 found certificate DigiCert SHA2 Extended Validation Server CA
TLS 0xef004 we done saying hello
VALIDATOR happy birthday
VALIDATOR 0xef3e4 "digicert.com" validating X509 chain 0xeda84
VALIDATOR step
VALIDATOR no ocsp
VALIDATOR let's download some shit for 'DigiCert SHA2 Extended Validation Server
 CA'
VALIDATOR in validator start download
VALIDATOR 0xef3e4 "digicert.com" downloading issuer of "DigiCert SHA2 Extended V
alidation Server CA"'s cross-signature from http://ca.ipxe.org/auto/582fb9d4.der

Since this server doesn't provide the root in its chain, iPXE tries to complete the chain with its cross-signed roots and then things largely work.

Seems like we should try to find cross-signed alternatives before we give up on self-signed certs. In my testing, removing this block makes things work. I'll throw a PR out there for discussion.

from ipxe.

Finally got the "Mozilla list of public CA certificates" file to load (it was timing out yesterday; it redirects to this, which seems to more reliably load).

Anyway, it seems to include the root cert I care about. Checking in firefox, the serial in certdata.txt matches the root for the chain that Firefox assembles, so that seems to rule out my Firefox install being wonky.

from ipxe.

Attaching ipxe_sad.txt, with verbose x509 logging, pulled from qemu.

Downside, it's got a lot of terminal escape sequences in there so it'll be messy in a text editor.

Upside, cat it for pretty colors.

from ipxe.

Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.

So yeah, if my understanding is correct and the issue lies with how we handle root-bearing cert chains, then the present behavior does align with the RFC, as "trust anchor MAY be omitted" certainly seems to imply "trust anchor MAY NOT be omitted".

Your understanding is correct, and this should now be fixed via #1152

from ipxe.