wolfsshd: bind FPKI certificate UPN realm to AuthorizedUPNDomains#1079
Open
yosuke-wolfssl wants to merge 1 commit into
Open
wolfsshd: bind FPKI certificate UPN realm to AuthorizedUPNDomains#1079yosuke-wolfssl wants to merge 1 commit into
yosuke-wolfssl wants to merge 1 commit into
Conversation
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #1079
Scan targets checked: wolfssh-bugs, wolfssh-src
No new issues found in the changed files. ✅
yosuke-wolfssl
force-pushed
the
fix/f_5580
branch
from
July 1, 2026 01:37
ebf17a8 to
0006f11
Compare
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #1079
Scan targets checked: wolfssh-bugs, wolfssh-src
No new issues found in the changed files. ✅
aidangarske
reviewed
Jul 9, 2026
aidangarske
left a comment
Member
There was a problem hiding this comment.
🐺 Skoll Code Review
Overall recommendation: COMMENT
Findings: 5 total — 5 posted, 0 skipped
Posted findings
- [Low] AuthorizedUPNDomains opt-in default keeps realm-unchecked (fail-open) UPN matching and warns on every cert auth attempt —
apps/wolfsshd/auth.c:1619-1632 - [Medium] Existing positive x509 UPN test now depends on fixture cert realm being exactly 'example' —
apps/wolfsshd/test/create_sshd_config.sh:32 - [Low] Unquoted variable expansions in new test script reduce robustness —
apps/wolfsshd/test/sshd_x509_upn_fail.sh:6 - [Info] Multi-line function header comment on MatchUPNToUser —
apps/wolfsshd/auth.c:1390-1392 - [Info] WSTRNCASECMP degrades to case-sensitive strncmp on MICROCHIP targets —
apps/wolfsshd/auth.c:1441
Review generated by Skoll.
yosuke-wolfssl
force-pushed
the
fix/f_5580
branch
from
July 9, 2026 06:53
0006f11 to
a8365e2
Compare
Contributor
Author
|
Hello @aidangarske , |
aidangarske
approved these changes
Jul 14, 2026
aidangarske
left a comment
Member
There was a problem hiding this comment.
Looks good i would like @ejohnstown to look over this though.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
wolfsshd: bind FPKI certificate UPN realm to AuthorizedUPNDomains
Summary
When
WOLFSSL_FPKIis enabled,wolfsshdvalidated a client certificate's UPNSAN by comparing only the local part (the text before
@) to the requested SSHusername and discarding the realm/domain. A client holding a valid certificate
from a trusted CA for
alice@other-domain.examplecould thereforeauthenticate as local user
alice. This is most dangerous on the CA-only path(no
AuthorizedKeysFileset), where the CA-verified chain plus the local-partmatch are the only gates.
This PR adds an opt-in allowlist of permitted UPN realms,
AuthorizedUPNDomains.When set, a certificate's UPN realm must exactly match one of the configured
domains (case-insensitive) in addition to the existing local-part match. When
unset, behavior is unchanged for backward compatibility and a warning is logged
so operators know the domain is not being checked.
Addressed by f_5580.
Problem
RequestAuthentication(apps/wolfsshd/auth.c) scanned the UPN SAN up to@and matched only the local part:
The realm after
@was explicitly ignored, so any trusted-CA certificate whoselocal part equalled the target username was accepted regardless of its domain.
Solution
AuthorizedUPNDomains— a whitespace/comma separatedlist of permitted UPN realms. Plumbed like the other
WOLFSSHD_CONFIGstringoptions (struct field, option table, copy/free, getter) and scoped to
Matchblocks via the existing config copy.
MatchUPNToUser()that performs the local-part match and, whenan allowlist is configured, requires the certificate's realm to be present and
to match a listed domain exactly (case-insensitive). It is length-bounded
(
nameSz) because certificatealtNamebuffers are not guaranteed to beNUL-terminated.
ForceCommand/AuthorizedUPNDomainsstorage was de-duplicatedinto a shared
SetListString()helper instead of a per-option handler.Example configuration:
Behavior:
AuthorizedUPNDomainsalice@anythingcorp.examplealice@corp.examplecorp.examplealice@other.examplecorp.examplealice(no realm)Backward compatibility
Unset is the default and preserves the prior local-part-only behavior, so
existing FPKI deployments are unaffected until they opt in. A
WS_LOG_WARNisemitted on each authentication attempt in which a certificate UPN matches while
the option is unset, making the unchecked-domain gap visible in logs.
The warning is deliberately per-attempt rather than one-time-per-process: a
one-time flag would require shared mutable state, which is racy in threaded
builds (Windows), and the log volume is bounded by the rate of successful
certificate logins on a deployment that has chosen not to opt in.
Security guidance
AuthorizedUPNDomainsis opt-in, so the default remains fail-open with respectto the certificate realm. FPKI deployments that rely on the CA-only path (no
AuthorizedKeysFile) should always setAuthorizedUPNDomains, since theCA-verified chain and the local-part match are otherwise the only gates on
identity. The per-attempt warning exists to make an un-opted-in deployment
visible in the logs.
Files changed
apps/wolfsshd/configuration.c,apps/wolfsshd/configuration.h— new option,getter, and shared
SetListString()helper.apps/wolfsshd/auth.c,apps/wolfsshd/auth.h—MatchUPNToUser()and itsuse in
RequestAuthentication; helper exported underWOLFSSHD_UNIT_TESTvia
WOLFSSHD_STATIC.apps/wolfsshd/wolfsshd.c—wolfsshd -?advertises aBuild features: FPKI certificate UPN domain checkingline so test scripts can detect the featuredeterministically.
apps/wolfsshd/test/test_configuration.c— unit tests for option parsing,Match-block copy, andMatchUPNToUser(match/mismatch, missing/empty realm,multi/comma/tab/CR-LF separators, case-insensitivity, and length-bounded
buffers).
apps/wolfsshd/test/create_sshd_config.sh,apps/wolfsshd/test/sshd_x509_upn_fail.sh,apps/wolfsshd/test/run_all_sshd_tests.sh— end-to-end negative test: a certwith realm
exampleis rejected by a daemon configured withAuthorizedUPNDomains other.example.Testing
apps/wolfsshd/test/test_configuration): all pass. Newtest_MatchUPNToUsercovers the separator set, case-insensitivity, and thelength-bounded (non-NUL-terminated) buffer path. Negative controls confirm the
vectors fail when enforcement is removed or when the helper reads past
nameSz.sshd_x509_upn_fail.shgates on FPKI by grepping thedaemon's help output, then asserts the daemon-side rejection reason
(
incorrect user cert sent) from the log with a before/after match count, soneither a non-FPKI build, a stale log line, nor an unrelated client failure
can produce a false pass. Skips cleanly (exit 77) when FPKI is not compiled in.
sshd_config_test_x509now also setsAuthorizedUPNDomains example, matching the fixture certificate's UPN realm(
keys/renewcerts.cnf:otherName = msUPN;UTF8:fred@example). This gives theallowlist-accept path end-to-end coverage, which it otherwise lacked.