Repository navigation
[fix] match BCJSSE credential key in TLS handshakes (#383) - #394
Merged
Merged
Conversation
BCJSSE requests cipher authentication names in TLS 1.2 and named EC
groups or concrete EdDSA algorithms in TLS 1.3
exact matching against stored key types drops valid EC and EdDSA
credentials during the handshake - match those requests against the
certificate key and full EC group
+ translate EdDSA credential keys for SunJSSE
SunJSSE only offers an EdDSA credential when both the private key and
the certificate's public key report "EdDSA", BC keys report
Ed25519/Ed448 so the credential got silently skipped ("No available
authentication scheme")
this affected Ed25519 certs with a plain SSLContext.new (SunJSSE is used
without an explicit TLS version) on both server and client side
translate keys to SunEC at setup only when needed (SunJSSE + EdDSA keys
not already reporting "EdDSA"), keeping the certificate bytes as is
kares
force-pushed
the
minimal-383-patch_squashed
branch
from
October 27, 2026 13:02
d45c9c1 to
a361e0a
Compare
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.
Since 0.19, an explicit TLS version (
SSLContext.new(:TLSv1_2),ssl_version=uses BCJSSE.Our key manager picked a credential by comparing the requested key type to the credential's plain type (
RSA,EC,EdDSA).However, BCJSSE is using with different names:
ECDHE_ECDSA/ECDHE_RSA/DHE_RSA/DHE_DSSin TLS 1.2, andEC/<named group>,Ed25519,Ed448in TLS 1.3. EC client certificates were also never sent over TLS 1.3.Related gap found along the way: Ed25519 never worked with SunJSSE provider, which is what a plain
SSLContext.new(no version) uses. SunJSSE only offers an EdDSA credential when both the private key and the certificate's public key report"EdDSA". JOSSL's BC based keys report"Ed25519"- SunJSSE silently skipped the credential ("No available authentication scheme").Resolution
For
EC/<group>, also check the certificate's curve, so a P-384 cert isn't offered for a P-256 request.SunECkeys, only when the context uses.The certificate bytes stay the same; only the key objects change.
Below Java 16 SunJSSE can't do EdDSA in TLS: the credential is left as is, and a warning is logged.
PKeyEdDSAaccepts JDK's EdDSA keys and re-reads them as BC keys.Previously
peer_cert.public_keyraisedNotImplementedErrorfor an Ed25519 cert parsed by SunJSSE.fixes #383 (supersedes #384)