How to manage a web servers SSL private key protection (password vs. no password)?

Question

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:

1. Protect the key with file system perms.

2. Use a password protected key and enter the key manually in every restart.

3. Use a password protected key and store the key in the filesystem to automate restart.

Our concerns are the following:

1. 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.

2. 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.

3. 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?

Answer 1

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.

Answer 2

If someone has sufficient access to the server to read the key, then they most likely also have enough access to attach a debugger and get the key from memory.

Unless you really like being woke up in the middle of the night to type in passwords go for option 1. When you have many servers, you want to auto restart on failure, and option 2 doesn't allow for that.

Answer 3

One possibility for higher security than 1. but less down-time than 2. is to create private keys with short validity and regularly recycle them. That way you can store them without passphrase but reduce the window of vulnerability.

As you recognised, option 3. doesn't provide any additional security over 1.

Answer 4

Practicality dictates that in almost all situations you are going to end up using option (1). File system perms are the best way to go in most security vs. practical scenarios.

On a *nix system you can restrict the private key to root only, as most good web servers (like apache) will start as root but downgrade their privs to a restricted user once they have the privileged ports they need (80, 443 etc).

As you mentioned option (3) is from a security point of view the same as option (1).