Is it a bad practice to use Java standard keystore

Question

We had been using java standard keystore ($JAVA_HOME/jre/lib/security/cacerts) as the trusted store for tomcat. And that tomcat server would communicate with some other server. A recent OS(AIX) upgrade apparently over-wrote the file at $JAVA_HOME/jre/lib/security/cacerts and that resulted in lost certificates and lot of issues with application hosted in tomcat.

Looking at this is it a bad practice to relay up on $JAVA_HOME/jre/lib/security/cacerts ? What are the alternate (better|standard) ways to tackle this scenario?

Kauslick

java_home could vary depending on platform, you will want to look out for that. I personally would search for a different hive folder. – Mannino

Answer 1

In terms of what is in the cacerts file, it's not necessarily worse practice than relying on the default CA certificates installed in your OS or your browser, but that doesn't mean it's great.

Sun/Oracle have a little "important note" somewhere in the middle of the JSSE Reference Guide about this:

IMPORTANT NOTE: The JDK ships with a limited number of trusted root certificates in the /lib/security/cacerts file. As documented in keytool, it is your responsibility to maintain (that is, add/remove) the certificates contained in this file if you use this file as a truststore.

Depending on the certificate configuration of the servers you contact, you may need to add additional root certificate(s). Obtain the needed specific root certificate(s) from the appropriate vendor.

In terms of configuration, for specific applications where I've had to install "local" CA certificates, I find it more stable to use a local trust store (for example, specified with javax.net.ssl.trustStore).

Adelric

I believe this "IMPORTANT NOTE:" has now been downgraded to a "Note:" in recent versions of Java. – Edette

Answer 2

It's not a bad practice if you have a build process that will repeat the imports.

Deciduous

Answer 3

Not sure, but assuming your assumptions are correct, caution where you put your keystore. I would strongly suggest it is placed inside Apache folder.

By default in Websphere the keystore works this way, since it brings it's own JVM :)

Communitarian

GlassFish also has it's own keystore and cacerts. – Koon

Answer 4

The AIX upgrade is a patch. Any patch must not delete / overwrite user data. I would suggest that users affected by this kind of data loss ask IBM to fix the patch procedure. In comparison, a patch of the httpd server does not overwrite / delete the configuration even though it is in the program directory.

Yusem

Answer 5

Yes it is a bad practice to do that.

The best practice is to have to limit your trusted certificates as much as needed.
So you should have used you own keystore with only the certificates trusted by your application.

Lehmbruck

That violates the entire purpose of PKI. The idea is that the presence of trusted roots allows a chain of trust to be formed so that you can trust any certificate signed by a trusted CA. You are conflating authentication, which is what PKI and certificates are for, with authorization, which is an application-domain problem. It is fundamentally broken to combine these two separate functions. – Deciduous

@EJP:When you have an endpoint that communicates only with specific entities in a network why would I allow certificates to be trusted that are trusted by any CA configured in my system (whether it is linux, java's ca certs, Windows certificates etc)? – Lehmbruck

@Lehmbruck It looks like this might be preferable for inter-service within your data center maybe. On the internet, certificate chaining seems to be the right way. If you want to add some context to your suggestion, or provide other reference, that would be better. Right now, it looks like this will be misleading for most readers. – Edette