{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/573195#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### 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).","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/573195"}],"title":"Go, OpenSSL, Apple, LibreSSL, pyca, wolfSSL Name-Constraint Inconsistency in RFC 5280 Implementation","tracking":{"current_release_date":"2026-10-13T18:27:20+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.50"}},"id":"VU#573195","initial_release_date":"2026-10-13 18:27:20.252800+00:00","revision_history":[{"date":"2026-10-13T18:27:20+00:00","number":"1.20261013182720.1","summary":"Released on 2026-10-13T18:27:20+00:00"}],"status":"final","version":"1.20261013182720.1"}},"vulnerabilities":[{"title":"Name Constraints validation in Go crypto/x509, Apple Security.","notes":[{"category":"summary","text":"Name Constraints validation in Go crypto/x509, Apple Security.framework, OpenSSL, LibreSSL, pyca/cryptography, and wolfSSL implements inconsistent parsing rules for DNS name comparison, IPv4/IPv6 canonicalization, URI authority resolution, and wildcard expansion, which allows an attacker to obtain a certificate from a Name-Constrained intermediate CA and bypass restriction for excluded domains or IP ranges via tailored Subject Alternative Names."}],"ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#573195"}]}],"product_tree":{"branches":[]}}