Is using a CA certificate enough to communicate securely with an SSLServerSocket?

TheRealChx101 :

I have a Java SSL server application and I am able to communicate with its client counterpart using a self-signed certificate and key pair. This is done on my development machine.

Now, the time has come to launch the application on a live server and I have obtained my SSL certificate from an authority (LE).

I can export the signed certificate and import it into a Bouncy Castle keystore for my Android client. However, one thing got me thinking. If the certificate expires it means I'd have to update the application each time. I do not want to do this and it feels like too much work.

I was reading this page and they mentioned (Section Keys for SSL, item number 3) that simply having the CA certificate is enough to establish a connection.

[Optionally] Export the public key certificate of your private key and distribute it to the SSL parties that will interact with you. (see section "Export public key certificate from a keystore") If you are using a certificate from a Certificate Authority then it will be enough for others to have only the certificate of the Certificate Authority itself.

I wanted to know how secure this is and what implications are there (if any).

The idea is to avoid recompiling the client application each time the certificate is renewed.

Thanks.

Sanjeev :

From what I gather, only your client is authenticating your server and not the other way around. This is one way authentication since only one of the two parties is authenticating the other. I could be wrong and you might be doing mutual authentication, but we'll get to that. First let's just consider the simpler case.

In order for your client to authenticate your server, the server needs an SSL certificate with a private key which it seems like you have. This certificate was signed by a CA certificate, which was probably signed by a Root certificate. In order for your client to trust your server, it needs a list of CA certificates which the client trusts to sign an ssl certificate. This list of certificates is your trust store. Your trust store should have the root and the CA certificate for the trusted CA.

If your server's SSL certificate expires, you will need to get a new certificate for your server. If your new certificate was signed by the same CA which signed your old certificate, the client will continue to trust your server without any updates. However, if your new certificate was signed by a CA which is unknown to your client (i.e. the CA certificate is not in the trust store), you will need to update the client's trust store with the CA and root certificates of the new certificate.

This describes one way authentication. However if your application requires mutual authentication, in addition to your client authenticating your server, your server will also need to authenticate your client. The process is exactly the same but in reverse. The client will also need an ssl certificate and the server will also need a trust store with the Root/CA certificates which signed the client's certificate. The same rules apply as when the server authenticates the client. So, if the client's ssl certificate expires and the new certificate is not known to the server's trust store, the trust store must be updated with the new CA's certificate.

One way to get around having to manually update your trust store is to automatically get new trust stores with CAs you trust. This is what your browser does. However, you will still need to update your application if a new certificate is needed.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=155270&siteId=1