1SEAL-2026-002: Name Constraints bypass in aws-lc via CommonName fallback

summary

two linked certificate validation vulnerabilities in aws-lc, Amazon's fork of BoringSSL, allow certificates to bypass RFC 5280 Name Constraints when the certificate contains a commonName (CN) but no subjectAlternativeName (SAN) extension.

the first vulnerability allows a wildcard CN (e.g., *.example.com) to pass hostname verification in contexts where Name Constraints should prohibit it. the second allows a raw Unicode CN to bypass the cn2dnsid equivalence check while still being accepted by hostname verification, creating an inconsistency between what Name Constraints validates and what hostname verification accepts.

both vulnerabilities affect environments that rely on Name Constraints for namespace segmentation in private PKI: SPIFFE/SPIRE workload identity, Kubernetes mTLS, service mesh, IoT device identity, and internal enterprise PKI.

published advisories

advisory	package	vulnerable	patched	severity (AWS)
GHSA-3jrg-j22w-mpmc	AWS-LC	>= v1.61.0, < v1.71.0	v1.71.0	Medium
GHSA-394x-vwmw-crm3	aws-lc-sys (Rust)	>= 0.32.0, < 0.39.0	0.39.0	Medium

no CVE IDs were assigned by AWS CNA. no CVSS scores were published.

workarounds (per AWS advisory): applications that set X509_CHECK_FLAG_NEVER_CHECK_SUBJECT to disable CN fallback are not affected. applications that only encounter certificates with dNSName SANs (standard for public WebPKI) are also not affected. otherwise, upgrade.

severity

severity dispute

affected versions

component	vulnerable range	fixed version
aws-lc (C)	>= v1.61.0, < v1.71.0	v1.71.0
aws-lc-sys (Rust crate)	>= 0.32.0, < 0.39.0	0.39.0
s2n-tls	transitive via aws-lc	update aws-lc dependency

aws-lc is used by s2n-tls, which is used by AWS SDKs and services for TLS operations. AWS states that customers of AWS services do not need to take action.

findings

finding 1: wildcard CN bypass (1SEAL-2026-002a)

root cause

when a certificate contains a commonName but no SAN extension, aws-lc hostname verification falls back to matching the CN against the requested hostname. the NAME_CONSTRAINTS_check_CN function calls cn2dnsid to convert the CN to a DNS identifier for constraint checking. however, cn2dnsid does not handle wildcard CNs — it skips them, returning without performing Name Constraints validation.

the wildcard CN then reaches hostname verification, which does support wildcard matching. the result: a wildcard CN bypasses Name Constraints entirely while still matching hostnames.

attack scenario

an attacker who controls a constrained intermediate CA can issue a certificate with CN=*.example.com and no SAN. Name Constraints that should restrict this CA to a specific namespace (e.g., .internal.corp) are not applied. the certificate passes hostname verification for any hostname matching *.example.com, breaking the namespace boundary that Name Constraints are supposed to enforce.

finding 2: Unicode CN equivalence gap (1SEAL-2026-002b)

root cause

the cn2dnsid function in aws-lc converts commonName values to DNS identifiers for Name Constraints checking. it rejects CNs containing raw Unicode characters (non-ASCII bytes), returning without validation. however, the hostname verification path accepts these same raw Unicode CNs when comparing against the requested hostname.

this creates an inconsistency: cn2dnsid says "I can't validate this CN" and skips it, but hostname verification says "this CN matches" and accepts it. Name Constraints are never applied to the CN because cn2dnsid opted out, but the certificate is still used because hostname verification opted in.

attack scenario

an attacker who controls a constrained intermediate CA can issue a certificate with a CN containing Unicode characters that, after processing, match a target hostname. Name Constraints are not applied because cn2dnsid rejects the Unicode input. hostname verification accepts the certificate because it processes the CN through a different path.

exploitation requirements

both findings require:

1. a private PKI environment using RFC 5280 Name Constraints for namespace segmentation
2. a constrained intermediate CA (attacker-controlled or compromised)
3. the constrained CA issues a certificate with CN but no SAN extension
4. the relying party uses aws-lc (directly or via s2n-tls) for certificate validation

these conditions are standard in private PKI deployments: SPIFFE/SPIRE, Kubernetes mTLS, service mesh, IoT, and enterprise PKI environments routinely operate with constrained intermediate CAs and may issue CN-only certificates.

fix

fixed in aws-lc v1.71.0 and aws-lc-sys v0.39.0, published March 19, 2026.

• aws-lc users: upgrade to v1.71.0+
• aws-lc-sys (Rust) users: upgrade to v0.39.0+
• s2n-tls consumers: update the aws-lc transitive dependency. check lock files for version pins.

timeline

date	event
2026-02-28	reported to AWS Security via aws-security@amazon.com
2026-03-10	CERT/CC coordination case submitted (VRF#26-03-LDFDW)
2026-03-10	AWS confirmed fix in progress, targeting March 19 release
2026-03-18	AWS CNA determined: GHSA for both findings, CVE not in scope
2026-03-19	aws-lc v1.71.0 and aws-lc-sys v0.39.0 released
2026-03-19	GHSA-3jrg-j22w-mpmc (aws-lc) and GHSA-394x-vwmw-crm3 (aws-lc-rs) published
2026-03-19	public disclosure

credit

discovered by Oleh Konko (1seal) as part of a systematic audit of TLS certificate validation infrastructure.

references

• GHSA-3jrg-j22w-mpmc (aws-lc)
• GHSA-394x-vwmw-crm3 (aws-lc-rs)
• aws-lc repository
• CWE-295: Improper Certificate Validation
• CVE-2022-21656 (same bug class in Envoy)
• RFC 5280 section 4.2.1.10 (Name Constraints)