We are in the phase of implementing SSL certificates for UI access to our components (we have an internal Root CA to whom we send the CSR generated in openSSL) and we're wondering where would be the bast place to store the private keys?

We have a KeePass where we store the credentials for the systems in question but but it's already quit big. We were thinking about creating a second KeePass just for the private keys? What would be your recommendation ?

  • Private key for what? For the CA? For the SSL server? Commented Aug 23, 2017 at 12:53
  • For Web UI access for our Systems (IDS, SSL appliance etc.), right now we use self signed.
    – cyzczy
    Commented Aug 23, 2017 at 13:00
  • That doesn't answer the question. Let me try asking a different way. Are you asking about storing the private key for the CA (which will need to be decrypted only when you need to generate new certificates)? Or the private key for the web components (which will need to be decrypted every time someone's web browser connects to the server)? The answer is very different if you only need to access the key once a month vs needing to access the key several times per second. Commented Aug 23, 2017 at 13:02
  • I think my question is pretty clear. If I say we want to implement SSL certificates for the Web GUI for our components like IDS and I'm asking where to store the private keys I think it's obvious that I'm not talking about private key for the CA. If it's not clear then I hope it is now.
    – cyzczy
    Commented Aug 23, 2017 at 13:10
  • Umm, ok. What technology are you using for the Web GUI? A webserver like IIS or Apache? An application server like Tomcat? Commented Aug 23, 2017 at 13:13

1 Answer 1


Storing SSL private keys on production server

As I understand your question, you have a web server serving a GUI over HTTPS (IIS, Apache, Tomcat, something) and you want to know how to securely store the private keys on disk for this server.

Typically, people put a lot of effort into protecting their CA private keys, but much less effort into protecting the web server private keys (because the web server needs access to them at all times).

Metaphor: this is similar to asking "best kind of garage for my sports car?". The short answer is: it doesn't really matter if your car will spend 99% of its time on the highway.

I think this question covers what you're asking:

How should I store SSL keys on the server?

Basically, if you're ok with needing to manually start the web server every time, then the list I have below for CA keys applies, but if you want the server to restart automatically, then your options are either

  1. Store the key on the server in plaintext (applying whatever file permissions you can).

  2. If you're on Windows, use CAPI / DPAPI to add additional protections to the file beyond what you can do without OS help.

  3. Buy an HSM to store the keys for your servers (expensive and you may compatibility / complex setup issues depending on which web server you're using).

Original Answer about storing CA keys

[I assume you mean storage of the CA private key, not of the SSL server keys. I'll update my answer if you clarify]

I'm glad you're putting thought into how to store the CA private key. The goal of protecting a CA private key is to ensure that it can't be copied. How much effort you want to put into protecting it depends on what it's worth, in dollars, if it's stolen.

I'm 95% sure that openssl already encrypts your private key with a password (technically: uses a password to derive an AES key, then encrypts the CA private key with AES). So arguably, putting this inside KeePass isn't gaining you much.

Here are three scenarios with increasing security:

  1. Protect the CA private key with software encryption such as openssl's built-in password encryption, or KeePass.

    Pros: Cheap, easy.

    Cons: A hacker who breaks into your server can copy the entrypted file and brute-force the password. Then they have your private key.

  2. Store the CA private key on an encrypted USB stick, such as an IronKey. Make sure you always delete the key file from the CA machine after each use.

    Pros: When the key is not actively being used, there is nothing on the CA machine for an attacker to steal. There is only one copy of the private key on a physical USB stick. Hard to steal without somebody noticing.

    Cons: Malware planted on the CA machine can steal the private key the next time you use it.

  3. Air gap the CA. Run your openssl CA on a machine that has never been connected to the network. Transfer CSR's and signed certificates in and out via IronKey USB sticks.

    Pros: Much harder (but not impossible) for an attacker to get malware onto the CA machine and extract the private key

    Cons: Complex and inconvenient.

  4. Use an HSM. This is the Cadillac solution: store the CA's private keys in a networked HSM, when the CA needs to sign something it sends the request to the HSM.

    Pros: Highest security because the private keys never leave the HSM; if the CA machine never touches them then they can't be stolen.

    Cons: Complex, expensive, may require dev time and expertise to configure.

  • 1
    Regarding option #1, brute forcing encryption is not real threat as it would be very difficult to do (provided encryption is done correctly). I would rather say that real threat is a hacker using same mechanism you use to decrypt the key - you probably have decryption key somewhere on your machine or in memory, and if hacker has access to your machine, then he has access to that decryption key.
    – Kirill G.
    Commented Nov 9, 2018 at 9:31

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