0

I did the following things:

+ generate keystore.jks with keytool
+ exported keystore.cer file with keytool
+ imported keystore.cer file into truststore.jks
+ copied keystore.jks and keystore.cer to the client

Then I call my server with

-Djavax.net.ssl.trustStore=truststore.jks -Djavax.net.ssl.trustStorePassword=*

and my client with 

 -Djavax.net.ssl.keyStore=forclient.jks -Djavax.net.ssl.keyStorePassword=*

The server exposes its interface with the super() call of UnicastRemoteObject

super(PORT,
          new SslRMIClientSocketFactory(),
          new SslRMIServerSocketFactory(null, null, true));

The Registry stuff does not use any SSL. Why is that not working out? It DOES work out if I add the keystore VM arguments in the server run config and the trustore VM arguments in the clien. But I really want to know why?

WorstCase
  • 325
  • 4
  • 13
  • *It does not work* is not a useful error description. – Paŭlo Ebermann Jul 15 '11 at 14:20
  • Ok, the SLL handshake does not work. – WorstCase Jul 15 '11 at 14:42
  • @WorstCase that's not much more useful. Post the exception, the stack trace, and the output when run with -Djavax.net.debug=ssl,handshake. – user207421 Jul 16 '11 at 01:20
  • possible duplicate of [What do I need to get SSL sockets (SslRMIServerSocketFactory/SslRMIClientSocketFactory)?](http://stackoverflow.com/questions/6705067/what-do-i-need-to-get-ssl-sockets-sslrmiserversocketfactory-sslrmiclientsocketfa) – user207421 Jul 16 '11 at 01:26

1 Answers1

5

Please understand the aim of keystore and truststore first. Look at the POST . It says

  • A keystore contains private keys, and the certificates with their corresponding public keys.

  • A truststore contains certificates from other parties that you expect to communicate with, or from Certificate Authorities that you trust to identify other parties.

So the client SHOULD have truststore so that it trusts the server its interacting with uses server's public key to encrypt the data. Server SHOULD have keystore which stores the private keys which is used to decrypt the data encrypted by corresponding private key by client.

I hope now you got why your application works when you switch keystore and trustore in client-server.

Community
  • 1
  • 1
Santosh
  • 17,667
  • 4
  • 54
  • 79
  • For client authentication the other way around is needed, too (with other keys preferably). (I'm not sure if Java supports this, and how to enable it.) – Paŭlo Ebermann Jul 15 '11 at 14:20
  • yes, thats for two way authentication, meaning client authenticates server (which is generally the case) and server authenticating client. – Santosh Jul 15 '11 at 14:21
  • But the thing is I do NOT need server authentication, so why do i need a truststore on the client side? – WorstCase Jul 15 '11 at 14:49
  • 1
    @WorstCase: I think server authentication is not really optional for SSL. – Paŭlo Ebermann Jul 15 '11 at 15:14
  • @Paŭlo Ebermann +1 but more accurately, at least one of the peers must be authenticated for SSL to be secure. You can always turn the handshake around so that the client is the server for handshake purposes, so the (real) client is the peer that is authenticated. Can't do that with those socket factories though. – user207421 Jul 16 '11 at 01:23
  • @Santosh you're half right, but the client's private key isn't used for anything in SSL except signing its certificate: and data is not encrypted with private keys in any case, but with public keys. – user207421 Jul 16 '11 at 08:05