cve🔗

cve::cve-2024-0567🔗

Tests CVE-2024-0567.

Produces the following valid trust graph:

leaf -> A1 -> (A <-> B <-> C) -> Root A

In other words: leaf is signed by intermediate A1, which in turn is signed by A, which is mutually cross-signed by CAs B and C. This naively results in a cycle, which can be resolved because A is also present as a self-signed root in the trusted set.

B and C also have subordinate CAs (B1 and C1), but these do not factor into the constructed chain.

Affects GnuTLS prior to 3.8.3.

This testcase is an independent recreation of the testcase in the patch, for CABF conformance.

Expected result	Validation kind	Validation time	Features	Importance	Conflicts
SUCCESS	SERVER	N/A	N/A	undetermined	N/A

Harness	Result	Context
`pyca-cryptography-46.0.5`	✅	chain built successfully
`openssl-3.0.19`	✅	N/A
`openssl-3.6.1`	✅	N/A
`openssl-1.1`	✅	N/A
`gocryptox509-go1.26.1`	✅	N/A
`openssl-3.2.6`	✅	N/A
`rust-webpki`	✅	N/A
`openssl-3.3.6`	✅	N/A
`certvalidator-0.11.1`	❌ (unexpected failure)	The path could not be validated because the end-entity certificate contains the following unsupported critical extension: subject_alt_name
`gnutls-certtool-3.8.3`	❌ (unexpected failure)	Chain verification output: Not verified. The certificate is NOT trusted. The name in the certificate does not match the expected.
`openssl-3.5.5`	✅	N/A
`rustls-webpki`	✅	N/A
`openssl-3.4.4`	✅	N/A

cve::cve-2025-61727🔗

Tests CVE-2025-61727.

Produces the following chain:

root -> ICA (NC: forbid: bar.example.com) -> EE (SAN: *.example.com)

This chain exercises an ambiguity between RFC 5280 and RFC 9525: RFC 5280 says that name constraints apply to subjects and SANs, while RFC 9525 defines wildcard semantics and matching of peer names against wildcards. Together, neither spec defines how name constraints apply to peer names when a subject matches a peer name but doesn't directly match a name constraint.

In practice, validators should behave defensively and reject chains where a subject name might match a peer name that would violate the name constraint, even if the subject name itself doesn't match the name constraint. For example, *.example.com does not match the bar.example.com constraint, but would accept bar.example.com as a peer name.

Expected result	Validation kind	Validation time	Features	Importance	Conflicts
FAILURE	SERVER	N/A	N/A	undetermined	N/A

Harness	Result	Context
`pyca-cryptography-46.0.5`	❌ (unexpected success)	chain built successfully
`openssl-3.0.19`	❌ (unexpected success)	N/A
`openssl-3.6.1`	❌ (unexpected success)	N/A
`openssl-1.1`	❌ (unexpected success)	N/A
`gocryptox509-go1.26.1`	✅	N/A
`openssl-3.2.6`	❌ (unexpected success)	N/A
`rust-webpki`	✅	UnknownIssuer
`openssl-3.3.6`	❌ (unexpected success)	N/A
`certvalidator-0.11.1`	✅	The path could not be validated because intermediate certificate 1 contains the following unsupported critical extension: name_constraints
`gnutls-certtool-3.8.3`	✅	Chain verification output: Not verified. The certificate is NOT trusted. The name in the certificate does not match the expected.
`openssl-3.5.5`	❌ (unexpected success)	N/A
`rustls-webpki`	✅	NameConstraintViolation
`openssl-3.4.4`	❌ (unexpected success)	N/A