As suggested in the forum thread, a fix would be to enable, in the driver's configuration, to specify whether to use separate trust stores for nodes and clients that connect to the server. So, we will add a boolean property to specify this, plus additional properties to specify the nodes and clients trust stores sources, along with their corresponding password sources. When the boolean property is set to false (the default), then the server will perform as in earlier versions (same trust store for nodes and clients).

After some more research, I came to the conclusion that we'll have to modify the connection flow with regards to how the SSL handshake is done. Currently what we have is like this:

1. Acceptor server accepts an incoming connection
2. if accepted from an SSL port, initiate SSL handshake
3. read the connection type identifyer
4. dispatch the channel to the server determined by the identifier

Instead, what we need is more like this:

1. Acceptor server accepts an incoming connection
2. read the connection type identifyer
3. dispatch the channel to the server determined by the identifier
4. corresponding server initiates SSL handshake, using SSL parameters (including the trust store) for the type of channel: client or non-client

What this means is we need to identify the channel before the SSL handshake takes place. It also means that remote peers (nodes, clients and other servers) will have to send the connection identifier before the SSL handshake.

Fixed. Changes committed to SVN:

• trunk revision 2882
• branch b3.3 revision 2883

The issue was updated with the following change(s):

• This issue has been closed
• The status has been updated, from Confirmed to Closed.
• This issue's progression has been updated to 100 percent completed.
• The resolution has been updated, from Not determined to RESOLVED.
• Information about the user working on this issue has been changed, from lolo4j to Not being worked on.