Skip to content

strip all trailing dots in name-constraint host canonicalization - #2436

Closed
rootvector2 wants to merge 1 commit into
bcgit:mainfrom
rootvector2:name-constraint-strip-all-trailing-dots
Closed

strip all trailing dots in name-constraint host canonicalization#2436
rootvector2 wants to merge 1 commit into
bcgit:mainfrom
rootvector2:name-constraint-strip-all-trailing-dots

Conversation

@rootvector2

Copy link
Copy Markdown
Contributor

PKIXNameConstraintValidator.stripTrailingDot removed only one RFC 1034 root-label dot, so a dNSName, rfc822Name host or uniformResourceIdentifier host carrying two or more trailing dots kept a phantom empty label after the strip and missed the exact-match check. a SAN such as example.com.. is a legal IA5String the certificate parser never validates for DNS well-formedness, so it reaches the validator unchanged and escapes an excluded example.com subtree (RFC 5280 sec. 4.2.1.10). the same helper is shared by the email and URI host paths, so ceo@bank.com.. and https://competitor.example../ escape the same way. found while extending the single-dot testTrailingDotBypass case that already guards this class.

stripTrailingDot now strips every trailing dot, keeping the lower bound of 1 that preserves a bare .. one change closes the dNSName, rfc822Name and URI paths at once; single-dot handling and sibling-domain non-matching are unchanged. PKIXNameConstraintsTest.testTrailingDotBypass gains double- and triple-dot cases for each path, and fails without this change.

AI tooling was used to help prepare this change.

@dghgit dghgit self-assigned this Sep 13, 2026
@dghgit

dghgit commented Sep 13, 2026

Copy link
Copy Markdown
Contributor

Thanks for the patch, merged with revisions. The defect reproduced as described, though only the apex-exact form escapes — withinDomain already strips a second dot by accident on the subdomain path. We went with refusing a host that carries an empty label rather than canonicalising it away: canonicalising loosens the permitted direction (example.com.. under a permitted example.com goes from rejected to allowed), and this class already prefers to refuse rather than guess, as the 1.85 rfc822Name fix does for a name with more than one @ — RFC 1034 sec. 3.5 admits no empty label but the root, so example.com.. isn't another spelling of example.com. One of your cases inverts as a result, notexample.com.. now being refused as malformed whichever domain it names; the rest carry over, with the method extended to cover the permitted direction and the inner, leading and bare-dot forms. Now on https://www.bouncycastle.org/betas

@dghgit dghgit closed this Sep 13, 2026
hubot pushed a commit that referenced this pull request Sep 14, 2026
…arrying an empty label is now refused wherever a constraint of that type is in force, rather than canonicalised into a name it is not, the single RFC 1034 root-label dot being the only empty label a name may legally carry, relates to github PR #2436.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants