Windows Server Hack [Electronic resources] نسخه متنی

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 ToolsAccessories) 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 TasksBackup 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
certbackperhaps 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
PanelAdd/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!