Backing up your local Certificate Authority is essential, because it forms the foundation for public-key cryptography 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, chances are you’ve thought of deploying your own local Certificate Authority 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 your CA, 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 this approach is that you need to know what you’re doing. 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 the root CA and issues certificates for all users and systems on the network. A large enterprise might find that this single-CA solution doesn’t scale well enough and instead 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, 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.
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, if you ever need to rebuild your server and restore the System State information from tape, your new server will become 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 a hardware setup that is identical to your old machine. But the critical issue here is that the 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, as the name of a CA can’t be changed after Certificate Services is installed. Because the name of the machine is included within the root CA’s own certificate, 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 Certificate Services 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).
To prepare for the eventuality of recovering a still-functioning but corrupted root CA 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.
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 pending certificate requests waiting to be processed by the machine. This information is sufficient to restore your root CA if it becomes corrupted and Certificate Services stops working. As you’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 6-11.
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. However, 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 (the “Certificate database and certificate database log” option), which contain information about all certificates already issued by your CA and any pending requests from clients. When you choose this option in the Certification Authority Backup Wizard screen (shown in Figure 6-11), 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 made 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 Certificate Services on the machine (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 everything—private key, CA certificate, certificate log, and queue—on Monday, but on Thursday you processed a lot of certificate requests from users and now you need to update the backup. There are two ways you can do this. First, you can simply back up everything again to a new (empty) folder and then discard your old backup—nice and simple.
The other way (the way recommended by Microsoft) is to make an incremental backup of your certificate log and queue. Now, if you try to save your incremental backup in the certback folder, you’ll 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 backup—and then back up to this folder instead of certback.
The result will be the creation of 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’ll 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 6-11, 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), 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).
If your root CA becomes corrupt or 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 is running, it 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. 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 usually a time-consuming process, but if your server is running Windows Server 2003 you might be able to speed it up by using that platform’s new Automated System Recovery feature.
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. Once you’ve deployed a public-key infrastructure (PKI) within your organization and started issuing certificates to users for encrypted messaging and secure communications, 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.
Leaving aside the problem of upgrading the operating system itself (who knows what version of Windows we’ll be running 10 years from now?), here we’ll look at 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.
Next, 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 is 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. 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 to 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, shown in Figure 6-12.
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, as discussed earlier in this hack. 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! In any event, 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.
If you 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), 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!
Mitch Tulloch