Enforce X.509 name constraints, so HTTPS netboot works against FOG's CA

[mastacontrola]

The bug

FOG issues its web certificate through a FOG Web CA intermediate carrying a critical nameConstraints extension. iPXE's x509_extensions[] table knows five extensions — basicConstraints, keyUsage, extKeyUsage, authorityInfoAccess, subjectAltName — and x509_parse_extension() refuses any critical extension it doesn't recognise.

So iPXE cannot parse FOG's own Web CA:

https://<server>/fog/service/ipxe/boot.php... Operation not supported (https://ipxe.org/3c16e283)

3c16e283 is -ENOTSUP_EXTENSION, "Unsupported extension". It reads like a TLS or DNS fault — the binary boots, iPXE starts, reports HTTPS among its features, and only then can't read the certificate it was handed.

This affects any install where _resolveNetbootProto() selects HTTPS, which it does automatically whenever rebuildIpxeWithMyCA is set. Both working-1.6 and dev-branch are affected.

Why fix iPXE rather than the CA

The obvious one-liner is to stop marking the constraints critical. That flag exists so a verifier which cannot enforce a constraint refuses the certificate rather than ignoring it. Dropping it converts every such verifier from fail-closed to fail-open in order to accommodate one that happens to be ours. Full reasoning in fogproject ADR 0016.

Design

Enforced in x509_validate_chain(), not x509_validate(). A constraining CA binds every certificate below it, not only the one it signed. path_remaining can live in x509_validate() because an inherited integer collapses to one value (x509_set_valid()); a set of permitted subtrees does not. Checking only the immediate issuer is correct for a depth-3 chain and silently wrong for anything deeper — and the failure mode is a chain that gets accepted.

Unenforceable constraints are refused at parse time. Only dNSName and iPAddress subtrees are implemented; any other subtree type, and any minimum/maximum, fails the certificate. Checking at parse time rather than at comparison time matters: a constraint on a name type that no certificate in the chain happens to use would otherwise never be examined, and the chain would be accepted without the constraint having been enforced — support in appearance only.

dNSName constraints also cover the commonName of an end entity with no SAN. Strictly, RFC 5280 constrains the subject DN through directoryName subtrees, which are refused above. But x509_check_name() accepts a commonName as a host name, so without this a compromised constrained CA could issue CN=somewhere.else with no SAN and be trusted for it. Deliberately narrow: only when there is no SAN at all, and never for CA certificates.

Testing

x509 self-test goes from 173 to 300 assertions. Coverage includes the label-boundary near-miss (notexample.com vs constraint example.com), IPv4/IPv6 subtree mismatch, excluded overriding permitted, an unconstrained name type, the commonName fallback, and a leaf two levels below the constrained CA — the case an immediate-issuer-only implementation would wrongly accept.

• Every fixture cross-checked with openssl verify, so the expectations aren't just this implementation agreeing with itself. contrib/name-constraints/ holds the generator rather than leaving the DER as magic blobs.
• Mutation-tested. Six deliberate breakages — immediate-issuer-only, no CN check, no label boundary, ignore excluded, accept unenforceable types, ignore the IP netmask — all six caught.
• Verified against a real FOG server chain: fails to parse on stock v2.0.0, validates with the patch.

patches/ is new

This repository overlays configuration onto a pristine upstream checkout rather than forking it, and that stays the intent. Patches apply after the existing git reset --hard, so every build starts from pristine upstream and re-applies the full set; a patch that stops applying fails the build rather than silently producing a binary without it. IPXEVER is a fixed tag, so they can't rot between builds.

The patch is written to upstream's standards so it can be offered to ipxe/ipxe. That's a separate decision and carrying it here doesn't depend on it.

🤖 Generated with Claude Code