Another oddity is that the SSLSocketBuilderMBean provides a setTrustStoreURL but doesn't allow me to set my trust store's password, algorithm or type. RemotingSSLSocketFactory does allow me to set those things.
Here's another thing that I'm having a hard time understanding.
In the test for ...transport.socket.ssl.custom.InvokerServerTest, it is passing a config to the Connector() constructor that defines the trust store.
I haven't seen this mentioned in the docs.
So, the Connector has a Builder associated with it (and that building has a TrustStoreURL in it) but now I have to set additional truststore config to the Connector config map (??). I'm not sure why that is.
Wouldn't it be more appropriate to store the truststore settings in the Builder itself (where the keystore settings already live and where the truststore URL lives). The Connector can then go to the builder to get that information rather than having to specify this configuration separately in another config.
This is the test code I'm looking at:
Map config = new HashMap(); // config.put(RemotingSSLSocketFactory.REMOTING_KEY_STORE_TYPE, "JKS"); // String keyStoreFilePath = this.getClass().getResource("../.keystore").getFile(); // config.put(RemotingSSLSocketFactory.REMOTING_KEY_STORE_FILE_PATH, keyStoreFilePath); // config.put(RemotingSSLSocketFactory.REMOTING_KEY_STORE_PASSWORD, "unit-tests-server"); // config.put(RemotingSSLSocketFactory.REMOTING_USE_CLIENT_MODE, "false"); config.put(RemotingSSLSocketFactory.REMOTING_TRUST_STORE_TYPE, "JKS"); String trustStoreFilePath = this.getClass().getResource("../.truststore").getFile(); config.put(RemotingSSLSocketFactory.REMOTING_TRUST_STORE_FILE_PATH, trustStoreFilePath); config.put(RemotingSSLSocketFactory.REMOTING_TRUST_STORE_PASSWORD, "unit-tests-client"); Connector connector = new Connector(config);
Notice that the keystore settings are commented out. I looks like this was done since the Builder now contains the keystore information. I think it should be possible to move the truststore config over to the builder as well, unless I'm missing the reason why it is separate.
Originally, the idea was that the SSLSocketBuilder would be only used on the server side (for ssl server socket creation) and thus only needed keystore info. The RemotingSSLSocketFactory was intended only for use on the client side (thus only needed truststore info).
Recently, it has become clear that this separation of the two is not always possible (or needed). So SSLSocketBuilder will be changed to support client (ssl socket) and server (ssl server socket) operations and will then make so the RemotingSSLSocketFactory is not needed (think John has just finished this work, but am trying to catch up on my backlog of e-mails and forum postings).