CERT/CC finds TLS libraries disagree on certificate name constraints

CERT/CC finds TLS libraries disagree on certificate name constraints

19 October 2026: CERT/CC has published a vulnerability note, VU#948176, with 13 records showing that widely used TLS libraries apply X.509 Name Constraints differently, so a certificate name that one library rejects may be accepted by another. Fixes are out for GnuTLS, pyca/cryptography and wolfSSL, while reports against Go, Apple's Security framework, Mozilla NSS and others are still in triage or under coordination.

Not yet independently verified. The GnuTLS (3.8.13) and pyca/cryptography (46.0.6) fixes are confirmed on each project's own pages; for wolfSSL we follow its CVE record, which differs from CERT/CC's note, and several reports remain in triage or disputed. We will update this when it can be confirmed, and remove this note.

Why name constraints matter

Name Constraints are the certificate extension that keeps a subordinate certificate authority inside an allowed namespace, for example a company CA that may only issue for its own domains. If libraries disagree on what falls inside that namespace, a CA constrained to one set of names might mint a certificate that some clients accept for another. CERT/CC is careful about the risk: the records matter only when an attacker can get a trusted signature over chosen certificate fields, reach an affected validation path, and the application uses the accepted identity to make an authorisation decision. "Validator disagreement alone is not exploitation," the note says.

Status by library

• GnuTLS: case-sensitive comparison of some names, CVE-2026-3833, fixed in 3.8.13.
• pyca/cryptography: DNS constraints checked against the certificate's SANs but not the requested peer name, CVE-2026-34073, fixed in 46.0.6.
• wolfSSL: URI name constraints not enforced, CVE-2026-5263, fixed in 5.9.1 according to wolfSSL's CVE record (CERT/CC's note gives CVE-2026-3547 and 5.9.0, but that CVE is an unrelated ALPN parsing flaw); a wildcard issue addressed in PR 9991.
• OpenSSL: a fix for an @ in the URI path, query or fragment (PR 30319) is in all versions supported as of 10 September 2026; a separate userinfo report is in triage.
• AWS-LC: wildcard Common Name issue fixed; a Unicode question under coordination. s2n-tls is in triage.
• Go crypto/x509: two reports in triage; the IPv4-mapped IPv6 report was judged below Go's security bar.
• Apple Security.framework: three reports submitted in March 2026 still in triage. Mozilla NSS and LibreSSL reports are under coordination.
• Mbed TLS: non-critical Name Constraints are not enforced in the reported configuration; the vendor treats support as a feature request.

A companion note, VU#410595, covers five BoringSSL findings: two fixed in March 2026, one accepted, one disputed and one declined.

What operators can do now

CERT/CC's advice is to confirm how the libraries actually in use behave, keep leaf certificates to explicit Subject Alternative Names, and treat issuance policy at the CA as the first control. A second validator only helps if it uses the same inputs and fails closed. Teams running private PKI with constrained intermediates, common for internal services and IoT fleets, have the most reason to update the three fixed libraries and to test edge cases such as wildcards, IP addresses and URI names.

Sources

• CERT/CC: VU#948176, X.509 Name Constraints handling in TLS libraries, 19 October 2026
• CERT/CC: VU#410595, BoringSSL name constraints findings, 19 October 2026
• CVE-2026-5263: wolfSSL URI nameConstraints not enforced (CVE record) - read 23 October 2026
• GnuTLS security advisories - read 23 October 2026
• pyca/cryptography changelog, 46.0.6 - 25 March 2026