Paperlock · case 01 · X.509 Name Constraints

Same certificate.
Different answers.

Library-by-library status for CERT/CC VU#573195, VU#948176 and VU#410595.

The fence is in the certificate. Whether it holds depends on who reads it.

TLS libraries do not always enforce X.509 Name Constraints the same way. CERT/CC coordinated the disclosure. Some fixes have been released; other reports are merged upstream, in triage, disputed or declined. Teams that run private PKI or delegated CAs should check their deployment.

3 CERT/CC notes^N1several fixes released^N3exploitation not reported in the notes^M9

Explore findings and fixes Check your deployment One finding, step by step For press

6 CVEs credited · fixes released or merged by GnuTLS, pyca/cryptography, rustls/webpki, wolfSSL, AWS-LC, Go, OpenSSL and BoringSSL maintainers · coordinated by CERT/CC

Illustration. The same certificate, checked by four validators. “Accepted” does not mean “correct”. The corner of the certificate reads “enforced by: ?”: the certificate states the limit, and each validator decides whether to enforce it.

A certificate can limit which names a subordinate authority may certify. Those limits still have to be enforced by software.^F1

Paperlock examines whether certificate validators enforce the limits a certificate places on delegated trust. The findings distinguish implementation defects, disputed interpretations, and the fixes available for each case.^M1

Who should check their setup: teams that issue or rely on name-constrained CAs (private PKI, delegated or cross-signed CAs, mTLS between services) — especially where different components verify the same certificates with different libraries.^{M5 M8}

CERT/CC published three notes on 13 and 14 October 2026.^{N1 F5}

Research by Oleh Konko (1seal) · disclosure coordinated by CERT/CC

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

One finding, step by step

# link to One finding, step by stepeveryone

A fixed, public case first. The rest of the table follows the same pattern.

pyca/cryptography CVE-2026-34073 · fixed in 46.0.6

Expected protectionThe requested peer name should also be checked against the CA’s name constraints.
TestCan a name the constraints exclude still be accepted as the requested peer name?
ObservedIt could: the names listed in the certificate were checked, the requested peer name was not.
Vendor outcomeFixed in pyca/cryptography 46.0.6 (CVE-2026-34073, GHSA-m959-cc7f-wv43).
Operator actionUpdate to 46.0.6 or later where your services verify certificates with pyca/cryptography.

These steps are a reading path, not a claim that every report was accepted or every product updated. Other findings follow the same path in the table.

For this case, the vendor describes a gap between RFC 5280 and RFC 9525 and adopted a conservative check of the requested peer name. Vendor advisory GHSA-m959-cc7f-wv43

“A check ran” is not the same as “the right condition was checked”.

See the row in the table →^§3 · Reproduce this case →

When this matters

According to CERT/CC, all three must hold at once:

An attacker can obtain a trusted signature over certificate fields they choose.
An affected validation path is reachable in your software.
Your application uses the accepted name to decide access.

^M4

Source: the Impact sections of CERT/CC VU#573195, VU#948176 and VU#410595.

Certificatelimits the names a subordinate CA may certifystated
Libraryvalidates the chain and enforces the limitobserved here — the findings are in this step
Applicationuses the accepted name for accessdepends on your deployment — not tested here

Accepting a chain is not the same as granting access.

What operators can do

# link to What operators can dooperators

Apply available fixes and test the exact validator, version and configuration your deployment uses, including certificates that must be rejected.

When designing an issuance policy, prefer narrowly defined permitted namespaces over relying solely on a list of exclusions. This is not a guarantee that permittedSubtrees is correctly enforced, and it does not mean validators should ignore excludedSubtrees.

Enforce the same namespace restrictions in the CA's issuance process. Issuance controls are an additional safeguard, not a substitute for relying-party validation or protection against a compromised subordinate CA.

These measures reduce risk; they do not resolve every implementation difference or ambiguity in the standard.

See per-finding status and available fixes →

Background: permitted and excluded subtrees

The cryptlib manual recommends permitted rather than excluded subtrees specifically for DN constraints affected by string-encoding ambiguities. The X.509 Style Guide gives similar guidance while warning against relying too heavily on either mechanism. These references do not establish that all permitted-subtree checks are safe.

What changed

# link to What changedeveryone

Concrete results so far, each with its source.

Checks corrected

pyca/cryptography now checks the requested peer name against Name Constraints (46.0.6, CVE-2026-34073).

See the row →

Unsupported constraints rejected

rustls/webpki now rejects chains with URI constraints it does not support — first in 0.103.12, completed for excluded subtrees in 0.103.13. It does not add URI identity checks.

See the row →

Different outcomes kept visible

Released fixes, upstream merges, disputed and declined reports sit side by side with their own sources — no blanket “all fixed”.

See BoringSSL’s five records →

The third card describes how results are shown, not another vendor fix.

Coordinated disclosure

# link to Coordinated disclosureeveryone

CERT/CC VU#573195 — Name-Constraint Inconsistency in RFC 5280 Implementation
CERT/CC VU#948176 — Multiple TLS Libraries can Bypass Delegation Enforcement
CERT/CC VU#410595 — Google BoringSSL Name Constraints Bypass in SAN Validation Logic

Each note covers its own set of findings; the sets overlap and are not added together. Coordination is not endorsement of every conclusion here.

Findings and fixes →One row per finding, grouped by library — status, date, source and what to do.How it was checked →What the research adds, how Name Constraints work and how conclusions are reached.For press →One paragraph you can use, what is and is not accurate, how to count, images.Other research by 1seal →The full public research record: other findings, each with its own evidence and remediation history.

Short answers

# link to Short answerseveryone

Do I need to act right now?It depends on your deployment.

For most people, probably not. Urgency depends on the specific finding and on your deployment.

According to CERT/CC, these findings matter when three things hold at once: an attacker can obtain a trusted signature over certificate fields they choose; an affected validation path is reachable; and the application uses the accepted name for authorization.^M4

To see where you stand, start with What to check.

I’m not an engineer. Does this affect me?Install updates as usual.

The published material does not indicate that people need to change passwords or devices. This mainly concerns organizations that run their own certificate infrastructure.^M4

Editorial reading, not a CERT/CC statement.

Is HTTPS broken?No.

This concerns one specific rule inside certificate checking. Validator disagreement alone is not exploitation.^M4

Are browsers, phones or cloud services affected?Not established.

Using a library does not mean a product reaches the affected path. Product vendors speak for their products.^M7

Is it being exploited?Not reported in the CERT/CC notes.

That is not the same as “none”.^M9

Which library is right?None should be assumed correct everywhere.

Where the standard is clear, some reports describe defects. Where it is silent, disagreement is expected. No single library should be assumed correct for every deployment.^{M1 M3 M6}