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

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

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

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

Solution 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).