ADR 0016: iPXE enforces X.509 name constraints - #1184
Merged
Conversation
Records why the fix for the HTTPS netboot failure went into iPXE rather than into FOG's certificate issuance. FOG's Web CA carries a critical nameConstraints extension. iPXE knows five extensions and refuses any critical one it does not recognise, so it cannot parse the CA FOG bakes into it, and HTTPS netboot fails with "Operation not supported (https://ipxe.org/3c16e283)". The two features -- constrained issuance and CA-embedded iPXE -- are wired to enable each other and were mutually incompatible. The decision is to teach iPXE the extension rather than stop marking it critical. Criticality exists so that a verifier which cannot enforce a constraint refuses the certificate instead of ignoring it; removing it would convert every such verifier from fail-closed to fail-open to accommodate one that happens to be ours. Also records the two implementation choices that are easy to get wrong in a way that fails open -- enforcing per path rather than per issuer, and refusing unenforceable constraints when the extension is parsed rather than when names are compared -- and the deliberate deviation from a strict RFC 5280 reading for the commonName of an end entity with no subjectAltName, which x509_check_name() would otherwise accept as a host name outside the permitted set. Implementation is FOGProject/fog-ipxe#6. The FOG_IPXE_VERSION pin bump follows once that is released.
This was referenced Aug 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Records the decision behind FOGProject/fog-ipxe#6.
Why
createSSLCA()issues the web certificate through aFOG Web CAintermediate, and_nameConstraints()gives that intermediate a criticalnameConstraintsextension. Separately,buildipxe.shbakes.fogCA.peminto iPXE viaCERT=/TRUST=whenever the netboot protocol is HTTPS — which_resolveNetbootProto()selects automatically whenrebuildIpxeWithMyCAis set.Those two features are mutually incompatible. iPXE's
x509_extensions[]knows five extensions andx509_parse_extension()refuses any critical one it doesn't recognise, so iPXE cannot parse FOG's own Web CA:Both branches were affected —
working-1.6since 2026-08-10,dev-branchsince 2026-08-09.What it records
criticalflag, and why the flag is the whole point.commonNameof an end entity with no SAN, whichx509_check_name()would otherwise accept as a host name outside the permitted set.--no-web-name-constraintsflag) and what each costs.Follow-up
The
FOG_IPXE_VERSIONpin bump lands once fog-ipxe cuts a release, on both branches.🤖 Generated with Claude Code