What is the best practices for storing certificates in spring boot?

Question

Every single tutorial I see online shows me how to setup HTTPS in spring boot by simply specifying the keystore path and password in the application.conf file, for example 1.4 in this link . I can do this and setup HTTPS fine.

However, this just seems dirty to me. This means that both the keystore and password is stored in source code, which I do not want to do. What I have done so far is that I have created my own custom tomcat configuration like this one and supplied the password from an environment variable. This is a good first step but I still need to keep the keystore in source code. Is this sufficient? or is there anything more I can do?

Answer 1

So I have managed to find a good resource explaining what should be done

Like every other guide, they say things like "dont keep keystores in source code" without providing any recomendations on how to do so. I know I shouldn't keep keystores in git, docker, jars ... but HOW do I seperate them? what tools should I use?

Anyway, here is the important stuff (if anyone can expand with solutions to the brief recommendations then that would be great):

---

Secure your Keystore and Key Passwords (I've done this)

Very often, keystore passwords are stored in open text in various config files.

Eg, here is a typical configuration of a Tomcat connector:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
    keystoreFile="${catalina.home}/conf/keystore.p12"
    keystorePass="mypass" keyPass="mypass"
    keyAlias="main-key"
    maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
    clientAuth="false" sslProtocol="TLS"
    />

This is obviously completely unacceptable from the security standpoint.

Save sensitive secrets elsewhere, ideally use a secret manager, like Hashicorp vault. At the very least, the master password could be stored in an environment variable for a properly protected account. Keep Private Keys Separate

Keep the private keys in a separate keystore file, do not use the same keystore for trust certificates and for the keys. The keystore with the keys must be protected using the filesystem permission. It must also be secured using a complex password. The keystore with the keys must only contain the key/certificate pairs and CAs (if needed), nothing else.

Set Restrictive File Permissions for Keystores (I've done this)

Set permissions for keystore files to read-only. The account used to run the application should be the owner of the file.

chown account_id keystore_file_name
chmod 400 keystore_file_name

Keep only Active Keys/Certs (I've done this)

Make sure that the keystores contain only active keys, certificates and CA chains. Expired certificates, unused CAS must be removed.

This requires implementing a process for cleaning keystores on a periodic basis or as part of every application release.

Do not Package Keystores inside Jar Files/Application Archive Files

Very often developers bundle keystore files with all the other application resources so they end up on the application classpath and then automatically picked up my Maven/Gradle build tools and added to Jar files.

This makes it difficult to update keys/certificates when needed. Keys/certificates can be (and should be) updated on a lifecycle which is different from the application's lifecycle. Therefore, keeping them outside of application archives is a good idea – this allows for updating keystores completely independently from the application itself.

Even when there is a truly continuous delivery process in place and the application code is updated very frequently, it is still worth it to de-couple keystores from applications from the packaging standpoint so that the keystores could be quickly updated in case of a breach.

This also means that the deployment toolchain for keystores should be separate from the regular application deployment toolchain. In other words, keystores should be treated as a completely separate deployment artifact, independent of the application.

Do not Package Keystores inside Docker Containers

Keystores and PEM files should be placed on an external docker volume so they can be updated without modifying the docker image. This allows for updating keystores independently from docker images in case of a security breach or for a regular key/certificate rotation/refresh.

The files on the external volume could simply be replaced on the host and then the docker container (or multiple containers) can be restarted.

If there are multiple docker containers running on the same host, they could all share the same volume with keystores.

Do not Store Keystores in the Application Git Repo

All keys and secrets must be de-coupled from source code and stored separately. Separate Keystores for Different Environments

The production environment must always have its own dedicated keystore file. Use the PKCS12 Format for Keystores

PKCS12 is compatible with other tools, such as openSSL. It is the default for Java 9 and above but it must be explicitly set for previous Java versions.