TLS Libraries Disagree on Which Signed Certificates Pass Name Restrictions

A signed certificate can pass one TLS validator and fail another on Name Constraints. CERT/CC describes differences in DNS case comparison, IPv4-mapped IPv6 handling, URI host parsing and wildcard matching. For a security impact, someone would need a trusted signature over chosen fields and an application that authorizes the identity one validator accepts. That accepted peer name can grant access to services. Mixed service-mesh, edge and backend validation paths deserve a check with the specific certificate chains your PKI issues. Those restrictions belong to the issuing CA, while the validator at each endpoint decides whether a particular peer name fits them. pyca/cryptography checked wildcard SANs without applying the parent restriction to the requested peer name. Its project advisory calls this an uncommon certificate topology. GnuTLS fixed its case-sensitive Name Constraints defect in upstream 3.8.13.

Update pyca/cryptography on affected verification paths from 46.0.5 or earlier to at least 46.0.6. Check your distribution’s backported GnuTLS build where applicable. CERT/CC is also coordinating with Go, Apple, OpenSSL, LibreSSL and wolfSSL.

Record the library and build at each TLS endpoint, then test permitted and excluded names against each with the same roots and peer name. Keep issued leaf names explicit and restrict sensitive services with an application-layer peer allow-list. Confirm that excluded identities fail validation and cannot get authorized. Save each endpoint’s accept-or-reject result with its peer name and installed library build to compare the same chain after an upgrade. A valid signature alone cannot tell you whether every validator enforced the same name rule.