3 Replies Latest reply: Mar 29, 2011 1:55 PM by 848969 RSS

    Public client, TLS protocol, keystores and SSLContext

    848969
      Hi,

      Hope this isn't a duplicate post, I didn't find a relevant one answering my questions... (as im not natively speaking english, I may have miss some keyword when searching)

      I'm developping a Client/Server Java application using JSSE to manage TLS connection.

      The client will be publicly available and it's connection with the server must be secured by a x509v3 certificate.
      It's actually using a self-generated x509v1 certificate but what I read lead me to the conclusion that when we'll buy a x509v3 certificate, this will work exactly the same way.

      To first test SSL (im using the SSLEngine class), I generated keystores and truststores for both client and server, with the same certificate.

      Here is how I generated what I needed :

      keytool -genkeypair -alias mytest -keyalg RSA -validity 360 -keystore /home/pitt/keystore
      keytool -export -alias mytest -keystore /home/pitt/keystore -rfc -file selfsigned.cer
      keytool -import -alias mytest -file selfsigned.cer -keystore /home/pitt/truststore

      Now that we are preparing a first public release, I have to clarify the certificate exchanges.

      So here are my questions :

      *** Is it possible to have no certificate provided with the client distribution and have a secured connection with the server ?

      To try this I modified my code :

      First on my server's SSLEngine, that uses the truststore and keystore generated above :

      engine.setNeedClientAuth(false);

      On the client I tried to use the default keystore :

      TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX");
      KeyStore ks = null;
      factory.init(ks);
      ctx = SSLContext.getInstance("TLS");
      ctx.init(null, factory.getTrustManagers(), null);

      Result : my server raises "Received fatal alert: certificate_unknown". I deduced that the client must provide a certificate that is trusted by the server.
      Am I right ?
      If I'm wrong, how can I implement this without embending any certificate/store in the client ? Or should I just provide the server certificate to the client, if so how ?..

      *** If the client must provide a certificate to establish connection, isn't it dangerous to have the same certificate in all Clients instances ?

      *** If it's what I have to do, how can I achieve this ?
      Even after many searches, I'm a little confused with the certificates/keystores/truststores. So should I provide a keystore to the client ? What should it contain ? What should I add to the server keystore/truststore...?

      Sorry, this isn't very clear for me, it is about implementation and cryptographic logic, hope someone will be nice enough to enlight my poor brain :)

      Thanks in advance !
        • 1. Re: Public client, TLS protocol, keystores and SSLContext
          848969
          News :

          I tried to achieve the connection without client authentification and it worked, I just had to give the client application a truststore containing the server's certificate, and it worked.
          Actually it was sort of logical...

          I have just two remaining questions :

          Do you think I'll have to provide this truststore even with a bought certificate (signed by verisign for example) ?

          And is this asymetricly crypted communication really secured ?

          Thanks !
          • 2. Re: Public client, TLS protocol, keystores and SSLContext
            EJP
            *** Is it possible to have no certificate provided with the client distribution and have a secured connection with the server ?
            Yes, as long as the server's certificate is signed by a CA or you distribute a truststore containing it with the client.
            Result : my server raises "Received fatal alert: certificate_unknown". I deduced that the client must provide a certificate that is trusted by the server.
            No, the server must provide a certificate trusted by the client. The reverse case is an option which you have disabled.
            how can I implement this without embending any certificate/store in the client?
            Get the server certificate signed by a CA.
            *** If the client must provide a certificate to establish connection, isn't it dangerous to have the same certificate in all Clients instances?
            Not only dangerous but pointless. The client certificate is supposed to uniquely identify a specific client. If it doesn't do that there is no point to providing it whatsoever.
            So should I provide a keystore to the client?
            Never. If client authentication is required the clients should provide their own keystores. You can't do it for them. But you don't need it at all in this case.
            What should I add to the server keystore/truststore...?
            If you are doing client authentication the server has to trust the client's certificate, either because it is signed by a CA or because it has been imported into the server's truststore. Not required in this case.
            Sorry, this isn't very clear for me
            It is actually very simple.

            1. For A to trust B, B must have a unique certificate in its keystore that is trusted by A's truststore, either because it was signed by a CA or because it has been imported into the truststore.
            2. In SSL, the client must trust the server, i.e. the client requires server authentication.
            3. In SSL it is possible for the server to want or need client authentication.
            4. It is also possible to reverse the roles of client and server in the handshake.
            • 3. Re: Public client, TLS protocol, keystores and SSLContext
              848969
              Thank you for your help, it was helpfull to validate what I incertainly deduced !