I checked in some refactoring to combine the common code that existed between SSLSocketBuilder and RemotingSSLSocketFactory.
I also added additional configuration capabilities to SSLSocketBuilder - the ones of importance are:
a) being able to turn on or off server authentication on the client-side (that is to say, we can have a client accept/trust any and all servers - whatever cert a server gives the client will be accepted - caveat, the cert has to be X509, but I don't think that's really an issue).
b) being able to set the client-auth mode on the server-side. See SSLServerSocket.set[Need,Want]ClientAuth javadocs. The allows the server to require the client to authenticate itself with a cert (NEED), or to authenticate clients if they provide a cert but allow anonymous client connections (NEED) or just allow all clients regardless of the trustworthiness of any cert they provide (NONE).
With the combination of a) and b) we can now have a communications channel that is encrypted but not authenticated. So, we can use SSL for encryption-only (i.e. we don't care about authentication).
I have integrated this new remoting code into a project I'm working on and it is working. I can turn off server-auth and set client-auth to NONE and see that messages are getting thru to both sides, even when I don't have the proper truststores in place. If I don't have the proper certs in place and I enable one or both, I can see SSL handshake/connection errors.
Tom - as we discussed earlier - we need to look at the test results to find out if its truly the jrunit stuff that's causing some failures.
