TLS libraries diverge on X.509 Name Constraints
CERT/CC details inconsistent X.509 Name Constraints handling across GnuTLS, OpenSSL, Go, wolfSSL and others, with no active exploitation reported.
Sourcekb.cert.org — open the original
What to check
- Applies to
- The 3 CVEs named below. Whether you run an affected version is not assessed: check the versions the source lists.
- Exploitation
- No exploitation in the wild and no public exploit is recorded for the CVEs named.
CERT/CC Vulnerability Note VU#948176 documents thirteen related findings about how various widely-used TLS/X.509 libraries implement RFC 5280 Name Constraints, a mechanism intended to restrict the namespace a subordinate CA can issue certificates for. The core issue is inconsistency: different libraries handle DNS case-sensitivity and wildcard SAN matching, IPv4 vs IPv4-mapped IPv6 address matching, URI SAN host extraction, Common Name fallback for leaf certificates without SANs, and enforcement of non-critical Name Constraints extensions differently. Some disagreements could allow a certificate to be accepted by one validator's logic when it should be rejected, under the right CA trust and application conditions.
Affected software includes GnuTLS (CVE-2026-3833, fixed in 3.8.13), pyca/cryptography (CVE-2026-34073, fixed in 46.0.6), wolfSSL (CVE-2026-3547, fixed in 5.9.0), with further reports in various triage/coordination states for Go's crypto/x509, OpenSSL (partially fixed via merged PR #30319), Apple Security.framework, Mozilla NSS, LibreSSL, AWS-LC (wildcard CN fixed, Unicode CN under coordination), s2n-tls, and Mbed TLS (disputed as a feature gap rather than a vulnerability).
CERT/CC stresses that validator disagreement alone is not exploitation — an attacker would need a trusted CA signature over crafted certificate fields, a vulnerable validation path, and an application relying on that identity for authorization. No in-the-wild exploitation is reported. Defenders relying on Name Constraints for CA containment should verify the actual behavior of libraries in use, restrict leaf certificates to explicit SANs, treat CA issuance policy as the primary control, and apply vendor patches (GnuTLS 3.8.13, pyca/cryptography 46.0.6, wolfSSL 5.9.0) as they become available.
Mentioned in this report
Source reporting: https://kb.cert.org/vuls/id/948176
Free public brief. The indicators are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its extracted indicators and live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,436 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs