Method and evidence

How the findings were assessed, what was tested, and where the evidence stops.

What this research adds

# link to What this research addseveryone

1 · Compared implementations

Certificate chains were run against several widely used validators in four areas: DNS-name comparison, IP address forms, URI authority parsing and wildcards.^M2

2 · Separated causes

Each case records whether the relevant behaviour is defined, underspecified, contested, or outside the RFC’s scope. Where the standard defines a requirement, the implementation can be checked against it. Where it does not, security impact must be assessed against the deployment’s stated policy and the observed behaviour. Disagreement between validators alone does not establish a vulnerability.^{M1 M3}

3 · Linked to fixes

Fixes released in GnuTLS, pyca/cryptography, rustls/webpki, wolfSSL (two reports), AWS-LC, Go and OpenSSL (one report, confirmed by the vendor). Fixes merged upstream for BoringSSL (three records).^§3

6 CVEs carry published credit to 1seal. Exact versions and records are in the table. An upstream fix does not mean every product is updated.^N3

4 · Kept the open ones visible

Some reports remain in triage or under coordination; others are disputed or declined. These labels describe the cited source on its stated date, not necessarily the maintainer’s current work. The reports included in this publication are listed in the findings table, each with the date of its source.

The limit is written in the certificate and the signature is valid; whether the limit holds depends on who reads it. Rules that different systems interpret on their own can fail this way well beyond certificates.

How it works

# link to How it workstechnical

A root authority signs a smaller authority and writes a fence into its certificate: the names it may vouch for. Every validator is supposed to check each new certificate against that fence. The CERT/CC notes record where libraries read the fence differently.^{F1 M1}

Illustration. Validators are unnamed on purpose: which library answers what depends on the finding and the version — see the findings table. “Accepted” is not “correct”: for some cases no single correct answer is established.

DNS case

standard is clear

What the standard says: RFC 5280 requires DNS names to be compared case-insensitively.^M3
What was observed: Some implementations compared DNS names, or the domain part of email constraints, case-sensitively. GnuTLS fixed this in 3.8.13 (CVE-2026-3833).^§3

IP forms

standard is silent

What the standard says: RFC 5280 does not say whether an IPv4-mapped IPv6 address should be treated as IPv4.^M3
What was observed: Implementations handle IP address forms differently. Related reports are in triage, under coordination or were declined.^{M2 §3}

URI constraints

RFC 3986 defines the boundary

What the standard says

RFC 3986 §3.2 defines where the authority part of a URI begins and ends.

What was observed

The reports differ in mechanism:^{M2 §3}

OpenSSL: the scan for @ ran past the end of the authority (fix released; PR #30319, confirmed by OpenSSL for supported versions on 2026-09-10).
A colon in userinfo changed the chosen host in older parsers (OpenSSL’s pre-3.5 parser; BoringSSL, fix merged upstream 2026-05-05).
Apple: userinfo stayed in the extracted host.
wolfSSL: URI constraints parsed but not enforced (fixed in 5.9.1).
rustls/webpki: unsupported URI constraints were accepted; the fix rejects them (fails closed).

Wildcards

standard is silent

What the standard says

RFC 5280 does not define what a wildcard in a certificate name means for Name Constraints.^M3

What was observed

Mechanisms differ:^{M2 §3}

rustls/webpki: wildcards against permitted subtrees (fixed).
BoringSSL: a wildcard covered an excluded specific host (fixed upstream).
pyca/cryptography: the requested name was not checked after SAN checks (fixed).
wolfSSL: fragment wildcards such as *foo.com (fixed in 5.9.1, PR #9991).
Other reports are in triage, under coordination or no fix is confirmed in the cited source.

No test vectors, certificate files or reproduction steps are published here for any finding that is not fixed.

Read further

CERT/CC VU#573195 CERT/CC VU#948176 CERT/CC VU#410595 RFC 5280 §4.2.1.10 RFC 3986 §3.2

Controls and conclusions

# link to Controls and conclusionstechnical

How test controls work and how a conclusion is reached. Generic illustration only; no results are shown.

Three programs, one passing test

Illustration with made-up programs — not results of real libraries.

Program	Allowed case	Forbidden case
Always accepts	accepted	accepted
Always rejects	rejected	rejected
Tells the two apart	accepted	rejected

Test only the forbidden case: two programs give the expected answer — and one of them simply rejects everything.

With a control case, only the program that tells the two apart passes both.

A rejection is an outcome. It does not, by itself, show which rule was enforced.

Even two right answers do not prove the whole implementation is correct, or why it rejected. That is why the corpus has positive and negative controls.

How a conclusion is reached

Different answers do not, by themselves, establish a defect.
Matching answers do not, by themselves, establish correctness.

The applicable requirement
An observation under exact conditions
An established match or violation

Where the rule is ambiguous, the ambiguity is shown, not resolved by vote.
Where the check was not reached, it is not counted as passed.
Where all programs agree, they are still compared with the requirement.

Disagreement tells us where to look. The applicable rule tells us what to expect.

Timeline

# link to Timelinetechnical · press

2026-03-04BoringSSL upstream fix, commit 5774eca, for two records later listed in VU#410595 (.8, .12).^§3
2026-03-06Report sent to CERT/CC.^F3
2026-03-191seal advisory 1SEAL-2026-002 and AWS advisories (AWS-LC), fixed in AWS-LC 1.71.0 / aws-lc-sys 0.39.0.^§3
2026-03-19wolfSSL merges PR #9991 (fragment wildcards) upstream.^§3
2026-03-25pyca/cryptography advisory, CVE-2026-34073, fixed in 46.0.6.^§3
2026-04-08wolfSSL 5.9.1 release notes include PR #9991 (fragment wildcards).^§3
2026-04-09wolfSSL CVE-2026-5263 (URI Name Constraints), fixed in 5.9.1.^§3
2026-04-15rustls/webpki advisories; first fix in 0.103.12.^§3
2026-04-21rustls/webpki 0.103.13: the missed excludedSubtrees case for URI constraints is fixed.^§3
2026-04-29GnuTLS 3.8.13, CVE-2026-3833 (independently co-reported).^§3
2026-05-05BoringSSL upstream fix (commit b84dc60) for the URI colon-before-@ record (VU#410595.9).^§3
2026-09-10OpenSSL confirms PR #30319 is in all then-supported versions.^§3
2026-10-13CERT/CC publishes VU#573195.^F5
2026-10-14CERT/CC publishes VU#948176 and VU#410595.^F5
2026-10-14This page goes live.

Gaps

Exploitation: not reported in the CERT/CC notes.

Facts behind this page (20)

Every statement on this page traces to one of these facts or to a row in the findings table. Turn on “sources” at the top to see the references inline.

F1

Topic: how TLS/X.509 libraries enforce X.509 Name Constraints (RFC 5280 §4.2.1.10).CERT-PUBLIC RFC 5280 §4.2.1.10

F2

Reporter: Oleh Konko, 1seal. CERT/CC acknowledgement: "Thanks to Oleh Konko for discovering and reporting these issues."CERT-PUBLIC CERT/CC VU#573195

F3

Reported to CERT/CC on 6 March 2026.1SEAL-OWN (owner-approved date)

F4

Three CERT/CC notes: VU#573195 (cross-implementation divergence), VU#948176 (delegation containment, 13 records), VU#410595 (BoringSSL, 5 records).CERT-PUBLIC VU#573195 · VU#948176 · VU#410595

F5

CERT/CC published VU#573195 on 2026-10-13, and VU#948176 and VU#410595 on 2026-10-14.CERT-PUBLIC CERT/CC notes

M1

"A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify."CERT-PUBLIC VU#573195

M2

Four areas: DNS-name comparison, IP address handling, URI-authority parsing, wildcard matching.CERT-PUBLIC VU#573195

M3

RFC 5280 requires case-insensitive DNS matching; it does not define wildcard SAN semantics; it does not say whether IPv4-mapped IPv6 should be treated as IPv4.CERT-PUBLIC RFC 5280

M4

The issues matter only when an attacker can obtain a trusted signature over chosen certificate fields, reach an affected validation path, and the application uses the accepted identity for authorization. "Validator disagreement alone is not exploitation."CERT-PUBLIC VU#948176 · VU#573195 · VU#410595

M5

Mixed service-mesh, CDN or enterprise PKI environments may see different results for the same certificate; detection is difficult because the certificate can be validly signed.CERT-PUBLIC VU#573195

M6

"No single library should be assumed correct for every deployment."CERT-PUBLIC VU#573195

M7

Using BoringSSL in a product does not mean that product invokes an affected path.CERT-PUBLIC VU#410595

M8

Operator guidance: test the validator you actually run against your deployment requirements; apply updates; keep leaf certificates to explicit SANs; treat issuance policy as the first control; a second validator helps only when it uses the same inputs and fails closed; application-layer allow-lists remain useful.CERT-PUBLIC VU#573195

M9

Exploitation in the wild: not reported in the CERT/CC notes. That is not the same as "none".GAP

N1

3 CERT/CC vulnerability notes.CERT-PUBLIC CERT/CC VU#573195 · CERT/CC VU#948176 · CERT/CC VU#410595

Unit: CERT/CC vulnerability note
Counting rule: Notes VU#573195, VU#948176 and VU#410595, as published.
Excluded: Nothing else is counted as a note.
Count as of: 2026-10-13 / 2026-10-14 (publication of the notes)

N2

12 libraries named across the three notes; rustls/webpki appears only in references.CERT-PUBLIC CERT/CC VU#573195 · CERT/CC VU#948176 · CERT/CC VU#410595

Unit: library named in a note
Counting rule: Distinct libraries named across the three notes.
Excluded: rustls/webpki appears only in references and is not counted here (it is listed in the findings table).
Count as of: 2026-10-13 / 2026-10-14 (publication of the notes)

N3

6 CVEs with published credit to Oleh Konko / 1seal: CVE-2026-3833 (GnuTLS), CVE-2026-34073 (pyca/cryptography), CVE-2026-5263 (wolfSSL), CVE-2026-93600 and CVE-2026-93601 (rustls/webpki), CVE-2026-33810 (Go). CVE-2026-27137 (Go) fixes a matching mechanism but credits another researcher and is not counted.PUBLIC CVE-2026-3833 · CVE-2026-34073 · CVE-2026-5263 · CVE-2026-93600 · CVE-2026-93601 · CVE-2026-33810

Unit: CVE ID with published credit to Oleh Konko / 1seal
Counting rule: Unique CVE IDs. A CVE counts once even when several finding rows cite it. Advisories (GHSA) are not CVEs and are not counted here.
Excluded: CVE-2026-27137 (Go): fixes a matching mechanism but credits another researcher.
Count as of: 2026-10-14; record dates differ by row, see the findings table

N4

13 records in VU#948176 and 5 in VU#410595: records, not confirmed vulnerabilities.CERT-PUBLIC CERT/CC VU#948176 · CERT/CC VU#410595

Unit: record inside a CERT/CC note
Counting rule: 13 records in VU#948176 and 5 in VU#410595. A record is not a confirmed vulnerability and record statuses differ. The two figures are not summed.
Excluded: Records are not CVEs, GHSAs or findings and are not added to them.
Count as of: 2026-10-13 / 2026-10-14 (publication of the notes)

N6

2 unique GHSA advisories for AWS-LC: GHSA-3jrg-j22w-mpmc (aws-lc) and GHSA-394x-vwmw-crm3 (aws-lc-rs). Both are cited by the two AWS-LC finding rows (wildcard CN and Unicode CN); each advisory counts once, not once per row.PUBLIC GHSA-3jrg-j22w-mpmc · GHSA-394x-vwmw-crm3

Unit: GHSA advisory (unique ID)
Counting rule: Unique GHSA IDs cited for AWS-LC. The same two advisories appear on two finding rows and are counted once each.
Excluded: The 6 credited CVEs (N3) are a different unit and are not added to this count. The rustls/webpki advisories are counted through their CVEs in N3.
Record date: 2026-03-19 (as of both AWS-LC rows)
Count as of: 2026-10-14

N9

The Name Constraints text has been in the standard since RFC 2459 (1999), carried into RFC 3280 (2002) and RFC 5280 (2008).PUBLIC RFC 2459 · RFC 5280

Project: Paperlock
Case: 01 · X.509 Name Constraints
By: 1seal research project
Sheet: 3 of 4 · Method
Findings: 25 · one row each