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 ?
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
Store the key on the server in plaintext (applying whatever file permissions you can).
If you're on Windows, use CAPI / DPAPI to add additional protections to the file beyond what you can do without OS help.
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).
[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:
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.
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.
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.
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.
