TLS libraries diverge on X.509 Name Constraints
Free public brief. The indicators, the detections with Splunk SPL already written (plus Elastic and KQL where they apply), and a Slack alert the next time this touches a vendor you run are in the app — free account, no card.
CERT/CC details inconsistent Name Constraints enforcement across major TLS libraries, enabling possible certificate validation bypass in mixed environments.
CERT/CC published Vulnerability Note VU#573195 describing systemic differences in how TLS libraries (Go crypto/x509, Apple Security.framework, OpenSSL, LibreSSL, pyca/cryptography, wolfSSL, and others) implement RFC 5280 X.509 Name Constraints. The inconsistencies span DNS name case-sensitivity, IPv4/IPv6 address handling, URI-authority parsing with userinfo, and wildcard SAN matching — some stemming from genuine implementation defects, others from ambiguity in the RFC itself. Two CVEs are called out specifically: CVE-2026-3833, a GnuTLS case-sensitivity defect in DNS name comparison (fixed in 3.8.13), and CVE-2026-34073, a pyca/cryptography flaw where Name Constraints were checked against certificate SANs but not the actual requested peer name (fixed in 46.0.6). Related wildcard and URI Name Constraints bypass issues have also been reported in rustls/webpki, LibreSSL, and wolfSSL via linked advisories.
Exploitation requires an attacker to obtain a validly signed certificate with crafted fields, a reachable code path using the affected validator, and an application that trusts the resulting identity for authorization decisions — this is not a simple remote exploit and there is no evidence of in-the-wild exploitation. The practical risk is highest in mixed-validator environments such as service meshes, CDNs, and enterprise PKI deployments, where the same certificate may be accepted by one component and rejected by another, creating inconsistent trust decisions that are hard to detect because the certificate itself is validly signed.
CERT/CC is coordinating disclosure with the affected projects. Defenders operating high-assurance PKI should update affected libraries (GnuTLS ≥3.8.13, pyca/cryptography ≥46.0.6, and forthcoming fixes for OpenSSL, LibreSSL, wolfSSL, rustls/webpki), test their specific validator against deployment requirements, restrict leaf certificates to explicit SANs, and layer issuance-policy or application-level allow-lists where library behavior diverges.
Mentioned in this report
Source reporting: https://kb.cert.org/vuls/id/573195
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, its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply), the actors and CVEs it names as live profiles, and the vendor research on the same campaign — the primary source the news paraphrased, cited and read directly.
It sits in a corpus of 13,854 reports from 146 sources, 616 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. Name the vendors you run and Slack hears about the reports that touch them — about forty a week that are yours, not the four hundred that are not.
Create a free account What it costs