TLS Libraries Skip Name Constraint Checks in GnuTLS, wolfSSL, OpenSSL

Security researchers have identified thirteen distinct ways that widely used Transport Layer Security libraries fail to enforce X.509 Name Constraints. According to CERT/CC, these flaws allow a subordinate certificate authority to issue certificates outside its permitted namespace. Some vendors have already released patches, while others are still reviewing the reports or have rejected them as security issues.

In plain English

Name Constraints restrict the domain names or IP addresses a subordinate Certificate Authority can issue. If a library fails to check these constraints correctly, an attacker with a compromised or misconfigured subordinate CA could create a valid certificate for a domain they do not own. This could allow them to impersonate legitimate services, such as email or web servers, bypassing the trust boundaries set by the root CA.

The background

The CERT/CC advisory highlights inconsistencies in how libraries handle DNS case sensitivity, wildcards, IP address formats, and URI parsing. For example, GnuTLS performed case-sensitive comparisons on certain DNS names, which contradicts RFC 5280 requirements. Similarly, pyca/cryptography failed to validate DNS constraints against the requested peer name. These discrepancies mean a certificate might be accepted by one library but rejected by another, creating validation gaps.

What changes now

Vendors have responded at different speeds. GnuTLS fixed its case-sensitivity issue in version 3.8.13, addressing CVE-2026-3833. The pyca/cryptography library resolved its validation gap in version 46.0.6, fixing CVE-2026-34073. wolfSSL patched its URI parsing flaw in version 5.9.0, remedying CVE-2026-3547. OpenSSL merged a fix for URI path parsing on 10 September 2026, confirming it is in all supported versions. However, reports for Go, Apple, Mozilla NSS, and LibreSSL remain under triage or coordination.

Who needs to act first

Teams should prioritize updating systems that expose TLS endpoints to the internet, as these face the highest risk of exploitation. Before deploying patches, verify that the new library versions are compatible with your application stack. Roll out updates to a small subset of servers first to ensure stability. For systems where updates are not immediately possible, monitor logs for unusual certificate validation errors or unexpected connections. Consider restricting trust to internal certificate authorities only if your architecture allows it.

What to do and how to stay safe: GnuTLS

• Inventory all systems using TLS libraries such as GnuTLS, wolfSSL, OpenSSL, and pyca/cryptography to determine if they run vulnerable versions.
• Apply available patches for GnuTLS 3.8.13, pyca/cryptography 46.0.6, wolfSSL 5.9.0, and the latest OpenSSL versions as soon as possible.
• Monitor certificate validation logs for discrepancies that might indicate a library is accepting certificates it should reject.
• Review your subordinate CA configurations to ensure name constraints are set to critical, as some libraries may ignore non-critical constraints.

Step-by-step guide: 7 Configuration Errors That Expose Systems to Zero-Day Exploits

General security guidance from the Vuln Post newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Does this flaw affect all TLS libraries?

No, CERT/CC identified thirteen specific records affecting libraries like GnuTLS, wolfSSL, OpenSSL, Go, and others, with varying statuses.

Is there a fix for Mbed TLS?

No, the vendor treats the lack of enforcement for non-critical name constraints as a feature request, not a security bug.

What caused the GnuTLS vulnerability?

GnuTLS performed case-sensitive comparisons on DNS names, while RFC 5280 requires case-insensitive matching, leading to incorrect validation.