Repository navigation
feat: add DigiCert TLS G5 cross-signs (RSA4096 by Global Root G2, ECC P384 by Global Root G3) - #417
Merged
Merged
Conversation
No keystore in ca-bundle.crt.metadata trusts DigiCert TLS RSA4096 Root G5, so compatible-mode bundling anchors G5 RSA4096 chains at a root that every modelled platform scores as untrusted. DigiCert Global Root G2 is trusted by the NSS, Windows, macOS, iOS and Ubuntu stores. Import the G5-by-G2 cross-sign into release 2026.10.2 so ubiquitous bundling can anchor these chains at G2: - DigiCert TLS RSA4096 Root G5, issued by DigiCert Global Root G2 serial 07A1278A2127F2B4C42170ECEC734B4E sha256 60c2666da5e2332170e1d3bfcd95bf8c9a6d4e63473f3a8bbb8cf42b3f9f038a valid 2026-03-31 to 2036-03-30 Of the six G5-by-G2 cross-signs in CT, this is the one to carry: - The 2023 cross-signs (serials 053BB5C8..., 0D6F6C9F...) were revoked by DigiCert on 2026-05-15. - The 2026-06-10 cross-signs restrict certificate policies to EV/DV/OV and omit IV; this one asserts anyPolicy. - The digicert.cn variants point AIA and CRL at China endpoints. It is not on the current Global Root G2 CRL. It shares the G5 root's key, so clients that trust G5 directly can still terminate there. The cross-sign must be removed before it expires on 2036-03-30. Add tests that exactly one G5-by-G2 cross-sign is present and that ubiquitous chain selection anchors G5-issued CAs at G2.
lgarofalo
approved these changes
Oct 27, 2026
DigiCert TLS ECC P384 Root G5 has the same gap as the RSA4096 G5 root: no keystore in ca-bundle.crt.metadata trusts it. DigiCert has no G2 cross-sign for it; the ECC equivalent is issued by DigiCert Global Root G3, which the NSS, Windows, macOS, iOS and Ubuntu stores trust. Import into release 2026.10.2: - DigiCert TLS ECC P384 Root G5, issued by DigiCert Global Root G3 serial 0DF2A81F6BBE9A48DACFF728F67AB1FC sha256 3142f99d358d9b500e5cdd2dff8f719a8ccecf589652334848522cca807d0807 valid 2026-03-31 to 2036-03-30 It asserts anyPolicy, uses digicert.com endpoints, and is not on the current Global Root G3 CRL. The 2022 G3 cross-sign (serial 0DD88F3D...) is revoked; the 2026-06-10 one restricts certificate policies. The cross-sign must be removed before it expires on 2036-03-30. Make the G5 cross-sign tests table-driven over both hierarchies.
mitch292
marked this pull request as draft
October 27, 2026 16:33
Resolve the cert.db conflict with #416 by taking master's database and re-importing both DigiCert G5 cross-signs into release 2026.10.2, then regenerating int-bundle.crt and certdata/int-bundle.txt.
mitch292
marked this pull request as ready for review
October 27, 2026 17:41
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
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.
Summary
No keystore in
ca-bundle.crt.metadatatrusts either DigiCert TLS G5 root. That means compatible (ubiquitous) bundling currently anchors every G5 chain at a root that all modelled platforms score as untrusted.This PR imports one cross-sign per G5 hierarchy into release
2026.10.2, so those chains anchor at the older DigiCert root. G2 and G3 are both trusted by the NSS, Windows, macOS, iOS and Ubuntu stores.07A1278A2127F2B4C42170ECEC734B4E0DF2A81F6BBE9A48DACFF728F67AB1FC60c2666da5e2332170e1d3bfcd95bf8c9a6d4e63473f3a8bbb8cf42b3f9f038a3142f99d358d9b500e5cdd2dff8f719a8ccecf589652334848522cca807d0807DigiCert has not issued a cross-sign from the ECC G5 root to G2. The only ECC cross-signs are issued by G3.
Why these cross-signs and not the others
CT shows several cross-signs for each G5 root. This PR adds exactly one per root, on purpose: if several were in the pool, ubiquitous selection would choose between them on tie-breakers alone. The others were rejected for these reasons:
053BB5C8…,0D6F6C9F…) were revoked 2026-05-15, according to the Global Root G2 CRL. The ECC cross-sign from 2022 (0DD88F3D…) is revoked according to the Global Root G3 CRL.digicert.cn.Neither added cert is on its issuer's current CRL (both CRLs last updated 2026-10-23). Each cross-sign has the same key as its G5 root, so clients that trust G5 directly still terminate there.
Impact
Changes
cert.db: both cross-signs imported into int release2026.10.2. Bundles for earlier releases regenerate byte-for-byte unchanged.int-bundle.crt,certdata/int-bundle.txt: regenerated withcfssl-trust bundle/certdump. The diff contains only these two certificates, andca-bundle.crtis unchanged.certdata/digicert_g5_cross_sign_test.go(table-driven over both hierarchies):Testing
go test ./... -count=1andgo vet ./certdata/pass.int-bundle.crt, the new tests fail for each hierarchy as expected, for exampleanchors at "DigiCert TLS ECC P384 Root G5", want "DigiCert Global Root G3".bundler.Bundleusing the Ubiquitous flavor:DigiCert G5 TLS RSA4096 SHA384 2021 CA1→[CA1, G5-by-G2], root G2.