General

SSL Certificates and Java

Not all developers know how to implement the ssl certificates in a Java environment and the difference between the serverside truststore as the client-sided keystores. Therefore a post is devoted to clearify how this way of security works.

If you wish to implement this I will assume you have configured your Java installation succesfully which means by my understanding:

  • A JDK is installed.
  • The JAVA_HOME environment variable is configured correctly.
  • The JDK you wish to use is configured as default JDK.

First of all the definition of the names:

  • cacerts – Certificate Authority Certifications – TrustStore
  • jks – Java keystore – KeyStore

The truststore is used to check certificates on incoming requests of the application while the keystore(s) are to let others know you can be trusted and bind certificates to outgoing traffic of your application. Do you need to read that sentence a couple of times before it really makes any sense? Don’t worry, i’ll explain it with some context.

A client-sided story: As a webservice you’ll sometimes need to identify yourself by using a certificate. Assuming you’ll already acquired the certificate from the other party the only thing you need is to add this certificate to a keystore as you are the client party which sends requests to the server party.

Example: As an API webservice you’ll need to send out requests to another webservice which probably forces the use of a certificate. When you’re not using a certificate your request is refused.

A server-sided story: When you want to force other parties to use a certificate for using your webservice you’ll need to add the certificate to the cacerts truststore.

Example: As an API webservice for specific valuable data you’ll want to use a certificate for security. This way you’ll force others parties to use this certificate or they’re not able to use your webservice.

You can load them by the changing environment variabels to the start of the JVM. These modifications are made in the configuration of the Java Runtime and/or the Java Virtual Machine used for the webservice, but could also be loaded through the application code! The certificates can be stored in the code repository. But you can ask yourself if that’s secure ;-).

A tool named “keytool” is used to add or remove certificates of the cacerts truststore or create/modify a jks keystore. This executable can be found in the bin folder of your JDK.

Server-sided story: To add a certificate to the cacerts truststore you can use the keytool with the following command:

keytool -import -file “\certificates\certificate.pem”
-keystore “\bin\jre\8.0\lib\security\cacerts”
-storepass “changeit”

Note that when this is applied to a running instance, the instance need to be restarted.

Client-sided story: when you have a jks file appointed as your keystore to use for authenticating yourself. All you need is to add an environment parameter to the JVM: -Djavax.net.ssl.keyStore=clientcertificate.p12 .
This means that the application started within the JVM with this parameter is authenticating itself with the certificates in that specific keystore.

A nice graphical tool for managing/reading the Java Keystores/TrustStores can be found here: https://keystore-explorer.org/ . And it’s available for Windows, MacOS and Linux systems.

Another way to implement certificates and keystores is through the use of a java.policy file. This way you can specify certificates and permissions of the application. When you’re not using the policy file the asterisk wildcard is used, that means that just everything is possible. That however is a different context of adding security to your Java application.

Awareness question: How many java applications do you know which have this policy file configured? When you can count the number of applications on one hand, maybe you can imagine the security risks that are being taken.

P.s. for any feedback about the contents, whether it is a typo or a misunderstanding from my side, please let me know here.

Leave a Reply

Your email address will not be published. Required fields are marked *