fix: Additional cert validation and sanity checks#187
Conversation
awilliams1-cb
commented
Jul 13, 2026
awilliams1-cb
commented
- Validate that externally provided certs link to the repo-provided trusted intermediates prior to adding them the certificate chain used in signature validation
- Short circuit validation early if provided root and intermediate certificate were not successfully extracted or are null
- Added new tests to validate logic, existing tests still pass
✅ Heimdall Review Status
|
| // Pin: the runtime intermediate must be issued by our pinned static | ||
| // intermediate; this also rejects a self-signed intermediate injected here. | ||
| const runtime = new X509Certificate(new Uint8Array(runtimeIntermediate.rawBytes)); | ||
| if (runtime.ca && runtime.verify(staticInter.publicKey)) { |
There was a problem hiding this comment.
Could we fail closed if this runtime pin does not verify? Otherwise the root may still be trusted and verification can fall back to shorter static/root-issued paths.
There was a problem hiding this comment.
Our trusted-root.json has two certificates to try and build the cert chain against. If we fail early then we would short-circuit before both certificates have been checked. Implicitly a shorter path wouldn't be able to validate against the signature unless the shortened path actually did sign. In that case, the shorter path would only be the cb static intermediate which would fail even before the signature because the leaf wouldn't connect back up to it.
| if (runtime.ca && runtime.verify(staticInter.publicKey)) { | ||
| certChain.push(runtimeIntermediate); | ||
| } | ||
| certChain.push(rootCert); |
There was a problem hiding this comment.
Could we confirm the intended trust model here? Since Sigstore treats each cert in certChain as a trust anchor, adding the external root may allow paths that skip the runtime/static hierarchy.
There was a problem hiding this comment.
The certs being added are being validated against the trusted intermediate, so if the root cert doesn't link to the trusted intermediate, or static intermediate isn't linked to the trusted intermediate, then they aren't added as a trust anchor. So there is no circumvention of the trusted intermediate with the addition of the hierarchy verification.
Now if the verified root or any verified intermediate (including the ones that are already in this repo) were to directly issue the leaf, then yes that would count. Our verification only ensures that a given signature originates from the cert chain that we build using the trusted roots stored in this repo.
jackchuma
left a comment
jackchuma
left a comment
There was a problem hiding this comment.
LGTM - my comments are just minor nits that could optionally be addressed in a follow up
4 participants
