Throughout the internet, HTTPS is used to encrypt traffic between a web server and its clients and thus provide a secure way of communicating with a server. Unfortunately, the best encryption is (somewhat) worthless, if you can’t be 100 percent sure that you are communicating with the right server. If Alice wants to send her credit card number to Bob, all encryption is worthless, if Mallory can trick her into thinking that he is Bob. SSL certificates to the rescue. If Alice trusts Carol and Carol has issued a SSL certificate to Bob, Alice can be sure that Bob is actually Bob and not someone else. SSL certificates are usually protected by private keys. You need the private key to use the SSL certificate. These private keys are usually encrypted with a pass-phrase. If Mallory manages to compromise Bobs server and steal the private key file, he can not (mis-)use it, because it is encrypted. That’s the theory.
However, Bobs web server needs to read the private key file to utilize the SSL certificate. If it is encrypted, Bob has to either store the pass-phrase somewhere or enter it by hand every time he starts the web server. If Bob uses Apache, he will get a so-called pass-phrase dialog. By default it looks like this (on the command line):
https-www:/etc/apache2-itk/# /etc/init.d/apache2-itk start
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server secure.example.org:443 (RSA)
Enter pass phrase:
OK: Pass Phrase Dialog successful.
While entering the pass-phrase of an SSL certificate by hand is a very secure approach, it has its share of problems:
- Upon reboot of Bobs server, the web server will not start automatically. It will hang, because it waits for the pass-phrase to be entered. Likewise, if the web server is restarted automatically for some reason (e.g. by monitoring software) the web server will hang on start-up, because it waits for the pass-phrase to be entered.
- For security reasons, it is unwise to use the same pass-phrase for all private keys. Also, Bob shouldn’t use overly simple pass-phrases, that are easy to remember. If Bob needs tenths (or even hundreds) of private keys he can’t possibly remember every single pass-phrase.
- It takes some time until Bob has looked up the corresponding pass-phrase in his mind or in his secure pass-phrase store. Even if he manages to immediately know every pass-phrase in use at his web server, it takes some time until he has entered the pass-phrase.
For the sacrifice of some security, you can mitigate these issues. If you really don’t care much for security, you can either not use a pass-phrase in the first place or – if you somehow entered a pass-phrase by accident – remove the pass-phrase from the key file. To remove the pass-phrase from an RSA private key use:
openssl rsa -in secure.example.org-2009.key -out secure.example.org-2009.key.unprotected
If you want a somewhat more secure approach (depending on the implementation), you can check out the
SSLPassPhraseDialog directive of the Apache
mod_ssl module. Using this directive, you can tell Apache to ask an external script for the pass-phrase of your certificates:
Apache will supply two arguments to the script. The first argument is of the form
secure.example.org:443 and the second argument is either
DSA. The script would print the corresponding pass-phrase to
stdout. Of course, you still need to store the pass-phrases somewhere. How much security you sacrifice using this construct depends on the implementation of your external script. But it might be a slight bit more secure than just using no pass-phrase for the private key files at all.
Shameless plug: If this post was useful to you, please consider buying yourself something from one of my Amazon stores: US store, UK store, FR store, DE store, CA store. If you're not into Amazon, why not donate something to GNOME, Mozilla or Wikipedia? Thank you!