TLS Libraries Disagree on Which Signed Certificates Pass Name Restrictions

A signed TLS certificate can pass one library’s name check and fail another’s. CERT/CC’s October 13 vulnerability note puts it plainly: “A certificate that one library accepts may be rejected by another.” If your service mesh, CDN edge and backend use different certificate validators, they may make different authorization decisions from the same signed chain. Each service that relies on a delegated CA must decide whether the signed name falls inside that CA’s permitted namespace.

Researcher Oleh Konko brought these differences to CERT/CC. They span DNS case handling, IP address forms, URI host parsing and wildcard names. The potential security consequence needs a specific deployment: someone must obtain a trusted signature on chosen certificate fields, reach an affected validation path and have an application use the accepted identity to authorize access. The same validation differences can also break a legitimate connection when one component rejects a certificate another accepts.

A constraint travels with the CA

Name Constraints in RFC 5280 restrict the names a subordinate certificate authority can sign for. The restriction travels down the certificate path and applies to relevant subject names and subject alternative names, or SANs. A validator checks the signed chain against those permitted or excluded subtrees. In an enterprise PKI, that check can help keep a delegated CA inside its assigned namespace.

CERT/CC found two kinds of disagreement. Some validators make implementation mistakes where the standard specifies a rule; others make different choices where it leaves a behavior open. DNS comparisons should ignore case, for example. The record for CVE-2026-3833 describes GnuTLS comparing some DNS and email constraints case-sensitively. GnuTLS lists 3.8.13 as its security release, and CERT/CC identifies that version as the fix. A separate Go report concerns case handling when looking up a wildcard’s parent constraint, rather than routine hostname comparison.

For IP names, the specification gives IPv4 and IPv6 separate encodings. Some libraries treat an IPv4-mapped IPv6 address differently from its IPv4 form, so the choice of form can change which restriction applies. For URIs, the validator has to extract a host before applying a host constraint. RFC 3986’s authority syntax allows optional user information before @ and a port after the host. CERT/CC describes differences around @ in a path, query or fragment and around a colon in user information. It identifies one merged OpenSSL change for the former case; operators should assess each parsing case against the actual library build rather than treating that change as a blanket URI fix.

Wildcard names expose a second check

A wildcard SAN names a range of possible peers. RFC 5280 defines the certificate’s name restrictions but leaves wildcard SAN behavior open. pyca/cryptography’s advisory for CVE-2026-34073 describes a specific gap: the library checked the SAN in the child certificate but did not also apply the restriction to the peer name being verified. A wildcard certificate could therefore pass for a peer whose explicit name was excluded higher in the chain. The project calls the required certificate topology uncommon and rates the issue low severity; ordinary Web PKI topologies avoid it.

The pyca changelog credits Konko and records the fix in 46.0.6. pyca advises users to upgrade from 46.0.5 or earlier to 46.0.6 or newer. This is a Python cryptography verification-path issue, so inventory the applications that actually use its X.509 verification APIs and check their installed package versions. Upgrading an unrelated TLS library in the same process will leave that application path unchanged.

CERT/CC also names Go’s crypto/x509, Apple’s Security.framework, OpenSSL, LibreSSL and wolfSSL among projects in coordination. Its vendor table lists their responses as Unknown. For those deployments, compare your specific validator and release against project guidance and a local test of the certificate chains your PKI issues before treating an update as a complete fix.

Test the identity your service authorizes

Start with the places where certificate names grant access: mutual-TLS service identities, delegated enterprise CAs and internal clients that validate signed peer chains. Record which component performs chain validation, which library and build it runs, the trust anchors it uses, and which identity the application ultimately authorizes. This separates a failed TLS handshake from a policy decision farther into the request path.

Run the same representative certificate chains through each validator in that path. Include your permitted and excluded DNS subtrees, the IPv4 and IPv6 forms you issue, URI SANs if your PKI uses them, and wildcard leaves if you allow them. Feed each validator the same trust roots and peer identity; compare acceptance or rejection at the TLS endpoint with the application’s authorization result. Where results differ, tighten issuance to explicit SANs and apply an application-layer allow-list for identities that can reach sensitive services. A second validator adds protection only if it sees the same inputs and rejects the connection when either check fails.

Make both validators agree before access

Update pyca/cryptography to at least 46.0.6 on affected verification paths and GnuTLS to a build containing its 3.8.13 fix; for distribution packages, verify the vendor’s backport rather than comparing upstream numbers alone. Keep leaf certificates to explicit SANs where your issuance policy permits, and restrict application access to expected peer identities. Then retest your issued chains at each real endpoint with the same trust anchors and peer name. The expected result is that every validator rejects an excluded identity and the application grants access only to an allowed one. Record each endpoint’s accept-or-reject result with its library build so the next upgrade can be checked against it. A certificate can be validly signed even when its name is accepted differently, so signature-validity logs alone cannot tell you which identity passed the policy check.