Jarret Gibson
Jarret Gibson

Reputation: 35

Instaling updated SSL Certificates breaks Java web integration?

We have a .Net WCF service hosted on a Windows 2013 server. The SSL certificate for the service which is exposed via HTTPS was nearing expiration. An updated certificate was generated and applied to the server.

All of our .Net client applications continued to function as normal, but our Java-based applications began malfunctioning. I am told that the server administrators must manually go onto those boxes and update the Java keystores with the newly updated certificate.

This blows me away, if true. All web browsers, .Net applications, etc... handled the SSL certificate change with no issue. How do you prevent issues like this with a Java keystore in the future when the certificate is eventually updated again? Is there any way to have the keystore be more "dynamic" in this regard?

Upvotes: 1

Views: 494

Answers (2)

Mick Mnemonic
Mick Mnemonic

Reputation: 7956

The likely reason why Java clients are not handling the new server certificate well is simply that the Java version of these clients is out-of-date.

Each installation of Java Runtime Environment (JRE) comes with a trust store file called cacerts (at <java-home>/lib/security/cacerts), which includes all the Certificate Authority (CA) and intermediate certificates that SSL/TLS clients running in the JVM will automatically trust. If your new server certificate was authored/signed by a CA certicate that is not in the cacerts file of the client's JRE, then the client cannot trust the server and setting up the SSL/TLS connection will fail.

I'm assuming .NET clients use the trusted certificates of the underlying Windows OS directly; if automatic Windows updates are enabled, new CA certificates will become available to the client with little effort. The same goes for web browsers: they are frequently kept up-to-date via automatic updates. However, in many environments, new JRE versions -- especially in Java application server installations -- need to be manually installed, which means that the latest and greatest CA certificates may not be immediately available without a little extra effort.

It is also possible that your server is using a certificate that has been authored by a CA that's not included in the cacerts file of even the latest JRE version. In this case, there is no other option than to have a sysadmin manually import the certificate.

Upvotes: 1

dunni
dunni

Reputation: 44535

You have to make sure, that the root certificate which is used to sign your certificate is already trusted in the Java default keystore. This may not be the case for all certificate providers. You can list all root certificates with the command

keytool -list -keystore /path/to/your/keystore

Then compare that list with your certificate chain.

Upvotes: 0

Related Questions