Same certificate, different answers: how TLS libraries enforce X.509 Name Constraints
1SEAL-2026-012 · Published 2026-10-14
Published
Name Constraints restrict the names that a subordinate certificate authority may certify. Oleh Konko (1seal) reported findings on how TLS libraries enforce them; CERT/CC coordinated the disclosure and published three vulnerability notes on 13 and 14 October 2026. Some reports describe implementation defects; others concern behaviour that RFC 5280 does not fully specify. Fixes have been released for several libraries; other reports are merged upstream, in triage, disputed or declined. According to CERT/CC, the findings matter only where an attacker can obtain a trusted signature over chosen certificate fields, an affected validation path is reachable, and the application uses the accepted name for authorization. The notes do not report exploitation.
Per-finding status
Per-finding status, dates, sources and what to do: paperlock.org/findings
Credits
Reported by Oleh Konko (1seal). Disclosure coordinated by CERT/CC.
References
Coordinator
- VU#573195 — Name-Constraint Inconsistency in RFC 5280 Implementation (13 October 2026)
- VU#948176 — Multiple TLS Libraries can Bypass Delegation Enforcement (14 October 2026)
- VU#410595 — Google BoringSSL Name Constraints Bypass in SAN Validation Logic (14 October 2026)
Related 1seal record
- 1SEAL-2026-002 · AWS-LC: CommonName constraint bypasses
Contact
Questions about this research: labs@1seal.org
Found a security issue in 1seal itself? Follow our security policy.