Hack 93 Back Up and Restore a Certificate Authority

Backing up your local Certificate Authority is essential, because it forms the foundation for public key cryptography (PKI) for your organization .

If you're thinking of using IPSec in an enterprise environment to encrypt virtual private network (VPN) communications for your remote users, or if you're considering securing email communications in your enterprise by encrypting messages and signing them digitally, then chances are you've thought of deploying your own local Certificate Authority (CA) by using the Certificate Services component of Windows 2000 and Windows Server 2003. The advantage of doing this using Certificate Services, instead of letting a public third-party organization issue and manage it, is that it costs nothing; you can issue, manage, renew, and revoke digital certificates for users throughout your enterprise for free. However, the hidden cost of doing this is that you need to know what you're doing. In particular, what if something goes wrong with the server that functions as your root CA? Proper backups are the key, but knowing how to restore in different situations is even more important.

At the heart of your certificate system is the root CA, which authorizes and validates all digital certificates issued by your enterprise. A small or mid- sized company will typically have only one CA, which functions as root CA and issues certificates for all users and systems on your network. A large enterprise might find this single-CA solution doesn't scale well enough and as a result might choose to deploy a hierarchy of CAs, with a single root CA at the top and one or more subordinate CAs underneath. In a CA hierarchy, the job of the root CA is simpler: to issue certificates for subordinate CAs, which then issue other certificates directly to users. In either case, the key to holding the whole situation together is your root CA. If it goes missing or becomes corrupt, then all the certificates issued by the hierarchy become invalid, because they can't be validated back to the root. So, protecting your root CA is protecting the heart of your network's whole system of encrypted communication and certificate-based authentication system.

Backing Up a CA

The simplest way to back up your root CA is the most straightforward: simply use the Backup utility (System Tools Accessories) and select the option to back up the System State of the machine. This will back up everything on the machine that is critical for restoring it, in case a disaster occurs and your root CA server is toast . Then, when you rebuild your server and restore the System State information from tape, your new server will now be the root CA for your enterprise and all the certificates that were previously issued by your old machine will still be valid.

To be safe, Microsoft generally recommends that you restore your root CA on a machine with hardware that is identical to your old machine. But the critical issue here is that your disk layout must be similar to the layout of the old machine, especially if you stored your certificate database and log files in a nonstandard location (by default, they are located in the %SystemRoot%\system32\CertLog folder, but you can change this location when you install Certificate Services). You also have to make sure your new server has the same name as the old machine, because the name of a CA can't be changed after Certificate Services is installed. The name can no longer be changed, because the name of the machine is included within the root CA's own certificate, so changing its name would cause the whole certification-validation process to fail (for a similar reason, you can't change the domain membership of a CA either).

However, System State backups are useful only for recovering from a complete failure of your server, and other things might go wrong with your root CA, such as corruption of the certificate database or certificate log files, some unknown problem that prevents the Certificate Service from starting and requires you to reinstall this service, or the need to move your root CA to a different machine on your network (something you might not have considered ). The reason for the last issue is that administrators sometimes don't consider the fact that a root CA is designed to last for years or, more likely, for decades. Once you've deployed a public key infrastructure (PKI) within your organization and started issuing certificates to users for encrypted messaging and secure communication, users become dependent on the transparency of the whole process from their own point of view. The last thing you want to do is build a nice, functional PKI system for your network and have to tear it all down someday and build another, all because you have to change which server hosts the role of root CA.

To prepare for the eventuality of recovering a corrupted root CA (which is still a functioning server, however) or moving the root CA role to another server, you need to perform a different kind of backup, one that backs up only what's essential for the machine to function in that role. Fortunately, Microsoft has made this easy by providing a Certification Authority Backup Wizard. Let's see how this wizard works and what it does.

Certification Authority Backup Wizard

The Certification Authority Backup Wizard facilitates backing up key data found on your root CA, including the server's own digital certificate (called a CA certificate ), its private key (used for generating digital signatures and decrypting encrypted information), the database and associated log files containing certificates previously issued by the server, and the queue of certificate requests still pending to be processed by the machine. This information is sufficient to restore your root CA if something is corrupted and the Certificate Service won't work. As we'll soon see, however, there's one additional piece of information you need to restore this data to a different machine.

To start the Certification Authority Backup Wizard, open the Certification Authority console under Administrative Tools. Then, right-click on the node that represents your root CA (or the subordinate CA you want to back up in a distributed enterprise scenario) and select All Tasks Backup CA to start the wizard. The main screen of the wizard offers several choices, as shown in Figure 10-3.

Figure 10-3. Backing up key data for a CA

The first time you back up your CA using this method, be sure to at least select the option to back up the private key and CA certificate for your CA. This will ensure that you can at least restore your CA in the event of an emergency, though if you do only this you will still have to reissue certificates to users. Therefore, in addition to backing up the private key and CA certificate, it's a good idea to also include in your backup the issued certificate log and pending certificate request queue for your server, which contains information about all certificates already issued by your CA and any requests from clients still pending. When you choose this option in the Certification Authority Backup Wizard screen (shown in Figure 10-3), you also have the option to perform an incremental backup of your CA, which makes a backup of only those changes to the certificate database since your last full backup.

This is trickier than it looks, so let's look deeper at the results of the backup process. If you choose only the first option, to back up the private key and CA certificate, and specify a folder such as C:\certback as the target for your backup, the result of the backup will be a file named CA_Name .p12 , where CA_Name is the name you specified for your CA when you installed the Certificate Service on the machine and the *.p12 file extension means the file uses standard PKCS #12 cryptographic syntax. Since you are required to specify a password later in the wizard, this backup file is itself secured by being password-protected. Best practice here is to choose a complex, difficult password to protect your backup, but make sure you don't forget the password; otherwise , you won't be able to restore your root CA later.

If you choose the other option, to back up the issued certificate log and pending certificate request queue, a subfolder named Database will be created in your certback folder. Inside this Database folder, copies of the certificate database files and certificate database log files for your CA will be created. The log files are basically transaction files that record changes made and pending to the database.

Now, let's say you backed up everythingprivate key, CA certificate, certificate log, and queueon Monday, but on Thursday you processed a lot of certificate requests from users and now need to update the backup. There are two ways you could do this. First, you could simply back up everything again to a new (empty) folder and then discard your old backupnice and simple. The other way (the way recommended by Microsoft) is to make an incremental backup of your certificate log and queue, but if you try to save your incremental backup in the certback folder, you get an error saying that you can make backups only to an empty folder. In this case, you might then create a subfolder under certback perhaps a folder such as certback\17Nov03 , which indicates the date you made your incremental backupand then back up to this folder instead of certback . The result will be to create another folder named DataBase , this one located at certback\17Nov03\DataBase . Within this folder, you'll find transaction logs but no database. Then, the following week, you can perform an incremental backup to a new folder named certback\24Nov03 , and so on.

Now, should you ever need to restore your CA from backup, you have to restore the full backup first, followed by all your incremental backups, in order. That's a lot of work. See why you might want to just perform a full backup every time instead?

By the way, if you're wondering about the grayed-out "Configuration information" option in Figure 10-3, that option is used only for backing up a standalone CA (i.e., a CA installed on a standalone server in a workgroup environment). If you're working in an Active Directory environment (which is more likely), then the configuration information for your CA is stored in Active Directory and therefore doesn't need to be backed up separately like this. The nice thing in Windows Server 2003 is that this option is not even visible in the wizard when you're backing up an enterprise CA (i.e., a CA installed on a domain controller or member server in an Active Directory environment).

Restoring a CA to a Working Server

If your root CA becomes corrupt or your Certificate Services fails to start but your server is otherwise working fine, you can use your previously created backup to restore the private key, root CA, certificate database, and transaction logs to their most recent working state. Just start the Certification Authority console in Administrative Tools, right-click on the root CA node, and select Restore CA to open the Certification Authority Restore Wizard, which is basically a mirror image of the Backup Wizard. If Certificate Services are running, they will be stopped temporarily to continue the restore. Select which components you want to restore, browse to locate the *.p12 backup file created earlier, and enter your password to begin the restore process. Once the restore is finished, Certificate Services will restart and you should have a working CA again for your organization.

What if it still doesn't work? In that case, you might have a corrupt metabase. Internet Information Services (IIS) is a supporting component for the CA web enrollment portion of Certificate Services, and if the IIS metabase becomes corrupt, your CA won't be able to process CA enrollment requests. The solution, once you've restored the CA, is to restore the metabase as well [Hack #54]. Once the metabase has been restored, you should be able to load the Certificate Services web pages and process certificate requests again.

If your root CA still doesn't work, your only solution might be to rebuild the machine from scratch and restore System State from tape backup media. This is a time-consuming process, but if your server is running Windows Server 2003, you might be able to speed the process by using the new Automated System Recovery [Hack #98] feature of that platform.

Restoring a CA to a Different Server

While root CAs are intended to last decades for large organizations, the actual hardware platforms they run on become obsolete in time spans much shorter than the projected lifetime of the CA. As a result, you might someday find yourself wanting to move the role of root CA from an old machine to a more powerful new one. Leaving aside the problem of upgrading the operating system itself (who knows what version of Windows we'll be running ten years from now?), let's see now how to move the root CA role from one server to another, a process usually called upgrading your CA .

First, make a full backup of the private key, CA certificate, certificate database, and transaction logs by using the wizard-based method described earlier in this hack. The result of the backup process is a password-protected file named CA_Name.p12 that contains the root CA's own certificate and private key, plus a Database folder that contains the database files and transaction logs. Then, back up the following Registry key on your old root CA:

 HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA_Name 

This key contains critical information about how Certificate Services are configured on your machine, and you will need this key to move your CA role to a different machine. Make sure you also make a note of the location where the certificate database and log files are located on your server. By default, they are both in the %SystemRoot%\system32\CertLog folder, but you might have placed them on a separate drive for increased performance when you installed Certificate Services on your old machine.

Next, you need to prepare your new server to host the role of root CA for your organization. Take the server off the network and rename it with the same name as the old root CA. This step is essential, because the name of the server is included in all certificates issued by the CA. So, in order for previously issued certificates to be validated, the new root CA must have the same name as the old one. While Windows Server 2003 now supports a process that lets you rename your domains and domain controllers, it's obviously simplest if you use a member server for your root CA, because member servers are easier to rename than domain controllers. Copy the CA_Name.p12 file and Database folder from your old machine to a temporary folder somewhere on your new machine, and have the Registry key exported from the old machine ready for import as well.

Now, begin installing Certificate Services on your machine by using Add/Remove Windows Components (Control Panel Add/Remove Programs). When prompted to specify which kind of CA you want to install (enterprise or standalone, root or subordinate), select "Advanced options" (Windows Server 2003 replaces "Advanced options" with "Use custom settings to generate the key pair and CA certificate instead," but everything else is similar) and click Next to display the Public and Private Key Pair screen of the Windows Components Wizard, as shown in Figure 10-4.

Figure 10-4. Importing the backed up information from your old root CA

Click the Import button, browse to locate the CA_Name.p12 backup file on your server, and enter the password you specified when you backed up your old CA. Complete the remaining steps of the wizard, being sure to specify the same path for the certificate database and log files that you were using on your old CA. Then, restore your database and log files from backup discussed in the previous section. Finally, restore the Registry key you backed up on the old CA to your new CA.

Restart Certificate Services, and you should now have a working root CA running on new hardware that will last you five years? Three years? Who knows, the way hardware platforms are advancing these days. Just be sure to test your new root CA thoroughly in all its aspects (e.g., processing certificate requests, validating certificates, and renewing and revoking certificates) before finally decommissioning your old root CA!

Decommissioning the Old CA

If you still want to use your old server for some other purpose on your network (as opposed to discarding it in the big blue bin behind your building), then you still have to do two things. First, you have to remove Certificate Services from it. But before you do this you need to remove the CA certificate and private key themselves , because you don't want them kicking around on some old machine on your network. To remove these cryptographic items, open a command prompt and type certutil -shutdown to stop Certificate Services on the machine. Then, type certutil -key to display a list of all cryptographic keys installed on the machine. Contained within this list should be a key named for the CA itself ( CA_Name ), which you can remove from the server by typing certutil -delkey CA_Name (enclose CA_Name in quotes if it contains spaces). Now you can use Add/Remove Programs in the Control Panel to uninstall Certificate Services, allowing you to use your old machine for some other purpose on your network.

But don't forget this second step: rename your server so it won't conflict with the new root CA on your network!