We recently bought a wildcard SSL cert for our domain. We converted all of the certs to a Java keystore, but now we are asking ourselves where we should store these for later use.

Do people use source control like BitBucket for these types of files or just generate every time it's needed, or something else?

We're wondering if there's a standard solution or any "best practices" around storing these certificates for future use.

  • Back them up encrypted to your traditional backup solution. Don't store the private keys unencrypted with any external provider. I usually include the issue and expire dates in my cert and key filename for differentiation. Dec 1, 2014 at 21:46

5 Answers 5


There are multiple solutions:

One avenue is a specific key vault either a hardware based appliance, a hardware security module or a software based equivalent.

Another is to simply revoke the old key and generate a new one private/public key-pair when the situation arises. That somewhat shifts the problem from maintaining key security to securing the username/password of the account with the certificate provider and their procedures for re-issue. The advantage there is that most organisations already have a privileged account management solution e.g. 1 2

There are multiple ways of off-line storage, from printing a hard-copy of the private and public key-pair including the password (but that will be a female dog to restore) to simply storing them on digital media rated for long time storage.

Really bad places are GitHub, your team WiKi or a network share (and you get the idea).

Update 2015/4/29: Keywhiz seems an interesting approach as well.

  • I'm curious, what do you mean by "software based equivalent" for the HSM ?
    – user186340
    Dec 2, 2014 at 5:26
  • Some of hardware appliance vendors nowadays sell their appliances also in the form of virtual appliance , a VM. There is also stuff like Oracle key vault and The open source SoftHSM to name some.
    – HBruijn
    Dec 2, 2014 at 6:13
  • So basically that allows to turn a standard computer into an HSM...
    – user186340
    Dec 2, 2014 at 7:19
  • 1
    "but that will be a female dog to restore" -> This one made my day! Jokes aside, you should encrypt it before saving. Dec 2, 2014 at 10:15
  • By definition you'll be exposing your public key to everyone. There is no reason to encrypt that. But that's no reason to be sloppy with it either. Security is primarily for the private key, which typically should indeed be encrypted/password protected. You should aim to have as few copies as possible of that.
    – HBruijn
    Dec 2, 2014 at 10:28

No, SSL certificates dont go in source control, at least not the private key part.

Treat them like you would a password. Ours actually get stored the exact same way our passwords do - in KeePass. It allows you to attach files, and is encrypted.


If you put the private key in source control, anyone who has access to it will be able to impersonate your server. If your webserver is not using PFS (perfect forward secrecy) then its also possible to decrypt any captured SSL traffic with commonly available open source tools like Wireshark.

You can protect the key by DES or AES encrypting it with a passphrase using OpenSSL. OpenSSL is available for Linux, OSX and Windows.

OpenSSL can also remove the passphrase when a passphrase is inconvenient (eg. on a webserver that starts automatically but doesn't support automatic entry of passphrases).

Adding a passphrase using AES encryption (more secure than DES):-

openssl rsa -aes256 -in private.key -out encrypted.private.key

Removing a passphrase (you will be prompted for the passphrase):-

openssl rsa -in encrypted.private.key -out decrypted.private.key
  • 1
    If you are doing things properly then even exposure of the private key shouldn't lead to compromise of past traffic, although it certainly would make MITM'ing in order to compromise future traffic much easier.
    – user
    Dec 2, 2014 at 12:43
  • Hi @Michael, In theory, but sadly I've been able to decrypt a lot of Apache and IIS captures so I can only assume PFS is off by default. Even a lot of IPSEC VPN's have it turned off.
    – Tricky
    Dec 2, 2014 at 19:54
  • PFS isn't so much off by default as it is not supported by many cipher suites. Try the SSL Labs server test some time; it indicates which cipher suites support FS. Of course, disabling all non-FS cipher suites are likely to leave many clients out in the cold because they don't support the FS cipher suites. Giving FS suites preferential treatment should work, however (but I strongly advice against manually ordering cipher suites unless you know what you are doing and their relative strengths and weaknesses).
    – user
    Dec 4, 2014 at 7:36
  • Thanks for the recommend on SSL Labs @Michael. Unfortunately my servers are not internet facing but I had a play around with enabled ciphers and as you suggest PFS seems to be supported by only some ciphers. PFS does indeed prevent me decoding packet traces. I'll update my answer accordingly.
    – Tricky
    Dec 5, 2014 at 15:33

I would recommend to look into an offline HSM (such as a hardware encryption token or a CAC) to store the private key and certificate. This not only protects the private key from accidental compromise, it also provides some basic cryptographic offload.

If you have more cryptographic assets to manage, I would recommend looking into an Enterprise Key & Certificate Management software, which can automate renewals, track lifecycle, automate provisionming to endpoints, etc. Most of these store the asset encrypted-at-rest as a CLOB in a database.

  • Why the downvotes? Not complaining; curious as to what is wrong with this answer.
    – Matt
    Aug 4, 2015 at 16:31
  • Not sure why it got down voted. HSM's are specifically designed for secure key storage and high speed encryption. I can only guess its related to the expense or the more complex management. All major banks use HSM's for key operations in stuff like Chip&Pin transactions.
    – Tricky
    Nov 11, 2015 at 12:48

Another option, after reading about KeyWhiz, was HashiCorp's Vault. Its not just a password manager, but a Secrets store, I believe somewhat similar to KeyWhiz. Its written in GO, and the client works as the server as well, and hooks into a bunch of backends, and authentication methods. Vault is also open-source, with the Enterprise option as well.

Since SSL Keys and Certificates are just text files, you could base64 encode them, and save it as a string in Vault, or even just the text in Vault as well. There isn't a WebUI, or GUI, its all command line, or script driven, and has a very good, stable web API to boot.

  1. https://www.vaultproject.io/
  2. https://github.com/hashicorp/vault

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .