{"vuid":"VU#573195","idnumber":"573195","name":"Go, OpenSSL, Apple, LibreSSL, pyca, wolfSSL Name-Constraint Inconsistency in RFC 5280 Implementation","keywords":null,"overview":"### Overview\r\nThis note covers differences in how TLS libraries interpret X.509 Name Constraints. A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify.\r\n\r\n### Description\r\nThe observed differences concern DNS name comparison, IP address handling, URI-authority parsing, and wildcard matching. These include both implementation defects and behavior not fully specified by RFC 5280.\r\n\r\n**DNS-name comparison.** RFC 5280 requires case-insensitive matching for DNS names. GnuTLS compared some names' case-sensitivity at the time of reporting (CVE-2026-3833, later fixed in 3.8.13). A distinct Go report concerns case handling in wildcard parent-constraint lookup, not ordinary hostname comparison.\r\n\r\n**IP address handling.** RFC 5280 defines separate IPv4 and IPv6 encodings and does not say whether IPv4-mapped IPv6 addresses should be treated as IPv4. Some libraries treat the two forms as different, so a constraint written for one form may not apply to the other.\r\n\r\n**URI-authority parsing.** RFC 3986 allows optional userinfo before the host. Implementations differ on which host they extract when `@`, a colon, or a query or fragment is present. OpenSSL merged PR #30319 for an `@` in the path, query, or fragment; a separate userinfo-colon report is not covered by that confirmation. Related differences have been reported in other libraries. A well-formed single `@` is handled per RFC 3986 by most implementations.\r\n\r\n**Wildcard matching.** RFC 5280 does not define wildcard SAN semantics. Wildcard-related reports include LibreSSL and wolfSSL. pyca/cryptography checked DNS Name Constraints against certificate SANs but not the requested peer name (CVE-2026-34073, fixed in 46.0.6), as described in the linked vendor advisory.\r\n\r\nThese differences come from independent design choices. Where the RFC is clear, some reports describe defects; where it is silent, disagreement is expected. No single library should be assumed correct for every deployment.\r\n\r\n### Impact\r\nAn attacker would need a trusted signature over chosen certificate fields, a reachable affected validation path, and an application that uses the accepted identity for authorization. Validator disagreement alone does not establish exploitation. Mixed service-mesh, CDN, or enterprise PKI environments may see different results for the same certificate. Detection is difficult because the certificate can be validly signed.\r\n\r\n### Solution\r\nCERT/CC is coordinating with the affected projects:\r\n* Go's `crypto/x509`\r\n* Apple's `Security.framework`\r\n* OpenSSL*\r\n* LibreSSL\r\n* `pyca/cryptography`\r\n* wolfSSL\r\n\r\nOperators who need high-assurance Name Constraints should test the validator they currently run against their deployment requirements, apply available updates, and keep leaf certificates to explicit SANs (Subject Alternative Names). A second validator helps only when it uses the same inputs and fails closed. Issuance policy and application-layer allow-lists remain useful complements where libraries differ.\r\n\r\n### Acknowledgements\r\nThanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.\r\n\r\nSupporting materials include test corpus v3.0.1 and VENDOR_MATRIX_2026-09-06.json (available to case participants; public links will follow agreed disclosure arrangements).","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["[RFC 5280 §4.2.1.10 — Name Constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10)","[RFC 5280 §4.2.1.6 — Subject Alternative Name](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)","[RFC 3986 §3.2 — URI Authority Component](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2)","[CVE-2026-3833 — GnuTLS Name Constraints case-sensitivity](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-3833)","[GnuTLS 3.8.13 Release](https://www.gnutls.org/news.html)","[CVE-2026-34073 — pyca/cryptography wildcard Name Constraints bypass](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-34073)","[GHSA-m959-cc7f-wv43 — pyca/cryptography wildcard advisory](https://github.com/pyca/cryptography/security/advisories/GHSA-m959-cc7f-wv43)","[GHSA-xgp8-3hg3-c2mh — rustls/webpki wildcard Name Constraints bypass](https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh)","[GHSA-965h-392x-2mh5 — rustls/webpki URI Name Constraints bypass](https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5)","[pyca/cryptography v46.0.6](https://cryptography.io/en/latest/changelog/)","[OpenSSL PR #30319](https://github.com/openssl/openssl/pull/30319)","[OpenSSL PR #30318](https://github.com/openssl/openssl/pull/30318)"],"cveids":[],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-10-13T18:27:20.422031Z","publicdate":"2026-10-13T18:27:20.252800Z","datefirstpublished":"2026-10-13T18:27:20.433572Z","dateupdated":"2026-10-13T18:27:20.252797Z","revision":1,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":259}