Really delete this comment?

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).

Really delete this comment?

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:

Acceptor server accepts an incoming connection

if accepted from an SSL port, initiate SSL handshake

read the connection type identifyer

dispatch the channel to the server determined by the identifier

Instead, what we need is more like this:

Acceptor server accepts an incoming connection

read the connection type identifyer

dispatch the channel to the server determined by the identifier

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.