Fix client/server inconsistency in SslCredential support matrix#16990
Merged
normanmaurer merged 1 commit intoJun 25, 2026
Conversation
Contributor
|
Auto-port PR for 5.0: #16996 |
normanmaurer
pushed a commit
that referenced
this pull request
Jun 26, 2026
…rt matrix (#16996) Auto-port of #16990 to 5.0 Cherry-picked commit: 5b49a0a --- Motivation: SslContextBuilder.addCredentials(...) (the OpenSslCredential API from #15919) is honored for the client context and for the OPENSSL_REFCNT server context, but is silently dropped for the default OPENSSL server provider. As a result, a server built with SslProvider.OPENSSL (the default server provider) plus addCredentials(...) never installs those credentials on the SSL_CTX, so they aren't available for cipher-/sigalg-based certificate selection. Modification: - SslContext.newServerContextInternal: pass credentials to OpenSslServerContext in the OPENSSL branch (matching the OPENSSL_REFCNT branch and the client path). - OpenSslServerContext: add a package-private constructor overload that accepts List<OpenSslCredential> credentials and forwards it to the existing credential-aware constructor (mirroring OpenSslClientContext), instead of always delegating null. - OpenSslEngineTest: add testServerSelectsAddedCredentialWithOpenSslProvider — a default-OPENSSL server whose ECDSA certificate is supplied only via addCredentials (base/legacy cert is RSA), driven by an ECDSA-only client, asserting the served leaf is EC. Fails with NO_SHARED_CIPHER before the fix, passes after. Result: addCredentials(...) is now honored for the default OPENSSL server provider, not just OPENSSL_REFCNT. Dual-cert servers select the correct certificate per the negotiated cipher (TLS 1.2) / signature algorithm (TLS 1.3) without requiring OPENSSL_REFCNT, and the new regression test guards the behavior. Co-authored-by: Jared Crawford <jaredcrawford@netflix.com>
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.
Motivation:
SslContextBuilder.addCredentials(...) (the OpenSslCredential API from #15919) is honored for the client context and for the OPENSSL_REFCNT server context, but is silently dropped for the default OPENSSL server provider.
As a result, a server built with SslProvider.OPENSSL (the default server provider) plus addCredentials(...) never installs those credentials on the SSL_CTX, so they aren't available for cipher-/sigalg-based certificate selection.
Modification:
Result:
addCredentials(...) is now honored for the default OPENSSL server provider, not just OPENSSL_REFCNT. Dual-cert servers select the correct certificate per the negotiated cipher (TLS 1.2) / signature algorithm (TLS 1.3) without requiring OPENSSL_REFCNT, and the new regression test guards the behavior.