We have a discussion in my company's security group about what's the worse of the following options to manage SSL private key.
The web server needs access to the private key for the encryption operation. This file should be protected from unauthorized access. At the same time, the server should start automatically, without human intervention (if it's secure enough).
We are discussing three options:
-
Protect the key with file system perms.
-
Use a password protected key and enter the key manually in every restart.
-
Use a password protected key and store the key in the filesystem to automate restart.
Our concerns are the following:
-
With option 1, restarts are automatic but a compromise could copy the private key and, as is un protected, could be used to decypher the communication or impersonate our servers.
-
Option 2 seems the more secure but it needs human intervention and sysadmins are concerned if it happens off-hours. Also, the password should be shared with several sysadmins and you know a shared secret is no longer a secret.
-
Option 3 has the best of both previous options but if someone has access to the key could also has access to the password :(, so it doesn't seem so secure at all.
How do you manage the security of your servers' private keys? Is there any other (more secure) options?
Best Answer
Option 1 is I think the accepted standard.
However, if you really want the extra security, why don't you have a secure server (not in your DMZ) set up to monitor your webserver, and if apache goes down, it can automatically log in remotely, and restart apache, supplying the passphrase.
So the passphrase is kept on a computer, but not the same one as apache is running on, and not in your DMZ. You gain the added security of using a passphrase, and maintain the ability for an auto-restart.