Backing up SSL certificate private key files

Question

What are some recommended practices for backing up SSL certificate private key files? I'm working in an environment where the public web servers are not backed up, because in theory the public systems could be rebuilt from data on the internal systems-- which they mostly can except for the SSL certificate key file which is unique to each public system.

I could copy the web server private keys to the internal systems, but that provides a second place for an attacker to pick up the private key.

I could password encrypt the copy of the private key.... What do people generally do?

Answer 1

You have basically three options:

1. Backup the key with the rest of your server, and makes sure that the backups are handled as confidential data. Some backup solutions can automatically encrypt backups, which can help in solving issues (but take care that encryption does not magically solve problems; it just reduces confidentiality of data to confidentiality of the decryption key).

   In your case you do not make backups of your servers, so this option does not really apply to you.

2. Backup the private key alone. Since private keys don't change often, you don't need to do a weekly backup; indeed, you can do that backup "manually". A private key is sensitive data, so some sort of protection is strongly advised. A customary archive format for private keys is PKCS#12, also known as "PFX" (or ".pfx file"). This format can embed the key and the certificate and some extra certificates (e.g. intermediate CA), and supports password-based encryption.

   You'd better make a strong protection password (say, 20 random letters). You won't type that password often, so you will forget it; therefore, write down a copy of the password on some piece of paper, to be kept in a sealed envelope in a safe. The PFX file itself can be stored just anywhere (well, don't put it on your Facebook account, because it would look a bit careless; but if you have a strong password, then this will provide enough protection).

   Windows supports PFX archives natively. Note that Windows will not allow the creation of a PFX archive if the private key was tagged, upon generation, with the "non exportable" flag. On Linux systems, use openssl (the command-line tool).

3. Don't backup the key at all. If your server burns down and must be created anew, just obtain a new certificate for your CA. SSL certificates are for authentication and encryption of data in transit, so there is no permanent data loss if the private key becomes unavailable. Some CA won't even bill you for issuing new "replacement" certificates (the kind of CA who makes you pay per server name and per year, not per certificate). In any case, the cost of a new certificate will be dwarfed by the cost of new hardware and, even more importantly, by the salary of the sysadmin who will have to reinstall the OS, software and Web site.

   This solution is the simplest of all, and can be cost effective as well. However, it may entail a longer delay before resumption of normal activities, so you will prefer to do that for multi-frontend servers, where a missing frontend is annoying but not crippling for business, and thus recovery can be delayed by a few hours.

If your server uses a Hardware Security Module, the none of the above applies (except the possible "no-backup" strategy); instead, the private key will be backed up with the HSM-specific procedure.