3 Replies Latest reply on May 28, 2006 4:12 PM by tom.elrod

    ssl key alias and key password configurable only on one side

    mazz

      This question may be due to my ignorance of all things SSL but at the risk of sounding ignorant (which is OK, 'cause I just admitted as much :-)

      I noticed that on the server-side, you can define a "Key Password" (SSLSocketBuilderMBean.setKeyPassword) but there is no way to specify a key password for the Client configuration (i.e. I don't see a RemotingSSLSocketFactory.setKeyPassword).

      Its the opposite for the key alias - I *can* set this in the client but not in the server. In RemotingSSLSocketFactory, I see a setKeyAlias but I do not see a way to set the alias in SSLSocketBuilderMBean (there is no setKeyAlias in that class).

      Am I missing something? Will I never want or need to set a key password on the client and will I never want or need to set the alias on the server?

        • 1. Re: ssl key alias and key password configurable only on one
          mazz

          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.

          • 2. Re: ssl key alias and key password configurable only on one
            mazz

            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.

            • 3. Re: ssl key alias and key password configurable only on one

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