ADDITIONAL SYSTEM INFORMATION :
It looks like any Java VM I tested was affected (versions 8-22 on macOS, Linux, Windows, IBM i, z/OS).


A DESCRIPTION OF THE PROBLEM :
It appears that SNIServerName settings are persisted across individual client socket connections created with the same SSLContext.

The first connection made from the client determines whether/which SNI server names are being sent to the server, regardless of what server names are set later on via the socket-specific SSLParameters

SSLContexts are supposed to be reusable, and great efforts were made to not erroneously reuse settings, as can be seen by the many cloned/duplicated objects in the SSL code, e.g., in SSLParameters and SNIServerName, for example.

This bug can lead to situations where client requests fail unexpectedly due to race conditions, etc.

Note that for the server-side, SNIMatchers appear to not be reused across calls, indicating not only an unintuitive but also an inconsistent behavior.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use code from https://github.com/kohlschuetter/snisslbug
(from source or run java -jar snissl-1.0-SNAPSHOT.jar )

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
**** START DEMO (reuseSSLContext=true) ****

Connecting to server; setServerName=snihostName
Setting SNI Matchers: true
Current server names: null
Setting server names: [type=host_name (0), value=snihostName]
Received SNI server name: type=host_name (0), value=snihostName

Connecting to server; setServerName=anotherSnihostName
Current server names: null
Setting server names: [type=host_name (0), value=anotherSnihostName]
Setting SNI Matchers: true
Received SNI server name: type=host_name (0), value=anotherSnihostName

Connecting to server; setServerName=null
Setting SNI Matchers: true
Current server names: null
Not setting server names
Did not receive SNI server name


**** START DEMO (reuseSSLContext=false) ****

Connecting to server; setServerName=snihostName
Setting SNI Matchers: true
Current server names: null
Setting server names: [type=host_name (0), value=snihostName]
Received SNI server name: type=host_name (0), value=snihostName

Connecting to server; setServerName=anotherSnihostName
Setting SNI Matchers: true
Current server names: null
Setting server names: [type=host_name (0), value=anotherSnihostName]
Received SNI server name: type=host_name (0), value=anotherSnihostName

Connecting to server; setServerName=null
Setting SNI Matchers: true
Current server names: null
Not setting server names
Did not receive SNI server name
ACTUAL -
**** START DEMO (reuseSSLContext=true) ****

Connecting to server; setServerName=snihostName
Setting SNI Matchers: true
Current server names: null
Setting server names: [type=host_name (0), value=snihostName]
Received SNI server name: type=host_name (0), value=snihostName

Connecting to server; setServerName=anotherSnihostName
Current server names: null
Setting server names: [type=host_name (0), value=anotherSnihostName]
Setting SNI Matchers: true
Received SNI server name: type=host_name (0), value=snihostName

Connecting to server; setServerName=null
Setting SNI Matchers: true
Current server names: null
Not setting server names
Received SNI server name: type=host_name (0), value=snihostName


**** START DEMO (reuseSSLContext=false) ****

Connecting to server; setServerName=snihostName
Setting SNI Matchers: true
Current server names: null
Setting server names: [type=host_name (0), value=snihostName]
Received SNI server name: type=host_name (0), value=snihostName

Connecting to server; setServerName=anotherSnihostName
Setting SNI Matchers: true
Current server names: null
Setting server names: [type=host_name (0), value=anotherSnihostName]
Received SNI server name: type=host_name (0), value=anotherSnihostName

Connecting to server; setServerName=null
Setting SNI Matchers: true
Current server names: null
Not setting server names
Did not receive SNI server name

---------- BEGIN SOURCE ----------
https://github.com/kohlschuetter/snisslbug
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The only workaround I've found so far is to not reuse SSLContext for these configurations from the client-side.


FREQUENCY : always