Guarding Your Certificate Authorities

Protect your CAs from being lost or destroyed

With the growing emphasis on information security, many companies turn to digital certificates to help increase the level of security on their networks. If your network relies on digital certificates, however, you need to implement some disaster-prevention and recovery techniques to protect your digital certificates and the Certificate Authorities (CAs) that issue them. A brief review of public key infrastructure (PKI) and an introduction to digital certificates and their CAs will get you started. Then, let's examine some methods designed to help you better guard your certificates, your CAs, and the certificate databases that contain your CAs.

A Brief Anatomy of Public Key Encryption
You use digital certificates in conjunction with a public key infrastructure (PKI). The idea behind a PKI is that you use two keys—a public key and a private key—to protect data. The public key, which encrypts data and verifies a digital signature, you make widely available. After the public key has encrypted data, only the corresponding private key can decrypt that data. Therefore, you must closely guard private keys, usually storing them either on the computer of the user who owns them or within the user’s roaming profile.

To illustrate how a PKI works, suppose that user A must send an encrypted message to user B. User A downloads user B’s public key—either directly from user B or from a public-key database. User A then uses user B’s public key to encrypt the message. After user B’s public key has encrypted the data, only user B’s private key (which, under most circumstances, no one except user B should have) can decrypt the message. (For information about configuring a PKI in Windows 2000, see Shawn Porter, "Security Considerations for Migrating from NT to Win2K, Part 3," July 2001, InstantDoc ID 21300.)

PKI encryption works well but has a significant drawback. When user A must send an encrypted message to user B, another user—C—can pretend to be user B and send his or her public key to user A. After user C sends his or her public key, only user C can decrypt the message. Therefore, secure PKI use requires strong positive public-key identification, which digital certificates can provide.

Understanding Digital Certificates and CAs
A digital certificate is basically an electronic signature. A certificate’s primary purposes are to bind a public key to an identity and prove that the binding is authentic.

Digital certificates are small binary files that a CA usually issues to users. (Certificates on a root CA are an exception. They’re self-signed because in Win2K—which takes a hierarchical approach to CAs—no higher CA exists to issue them.) The binary files contain information such as the certificate’s issuer, the certificate’s holder, and the certificate’s public key. The information in the file is formatted to conform to the X.509v3 standard.

Administrators can configure the network to use the built-in Win2K CA or any of several third-party CAs, such as VeriSign and Baltimore Technologies’ CyberTrust, formerly GTE CyberTrust. (To find a list of CAs you can trust, go to the Microsoft Internet Explorer—IE—Tools menu, select Internet Options, select the Content tab, click Certificates, and select the Trusted Root Certification Authorities.) Regardless of certificates’ origins, all machines involved must trust the CA. (Trust in the issuing CA creates trust in a certificate’s identity.)

In certain ways, a digital certificate resembles a driver’s license. If a police officer pulls you over, unless the same officer has pulled you over before, he or she probably has no idea who you are. The officer first asks you for your driver’s license, which acts as evidence that you are who you say you are and that your state has granted you the right to drive.

Why does the officer basically trust your driver’s license? First, in most states, driver’s licenses tend to be difficult to reproduce. (An experienced police officer can usually spot a fake license.) Second, the officer knows that he or she can generally trust the issuing agency, the Department of Motor Vehicles (DMV). Before the DMV issues a license to someone, the department must exert due diligence to verify the applicant’s credentials, thereby confirming an applicant’s identity. Because the officer trusts the DMV, he or she trusts the license.

Suppose that user A needs to prove his or her identity to user B. To do so, user A attaches a digital signature to an email message and sends the message to user B. Because user B knows that the digital signature is difficult to tamper with and is based on a certificate that a trusted CA issued, user B can be relatively certain that user A is who he or she claims to be.

Protecting Your CAs
As you’ve seen, the CA plays an important role in your network’s overall security. Therefore, you must protect the CA from tampering and physical damage. Before I explain various protection methods, however, keep in mind that if you issue your own digital certificates through Win2K Certificate Services, you might have more than one CA to protect. Remember that although an Enterprise root CA is the most critical CA in Win2K's hierarchy, you should also give Enterprise subordinate CAs, Standalone root CAs, and Standalone subordinate CAs adequate attention. Because all these CAs can issue certificates, they must also be guarded. (For detailed information about Win2K Certificate Services, see John Howie, "Securing Win2K with Certificate Services," September 2001, InstantDoc ID 22113.)

Protection for root-level CAs. Root-level CAs offer a unique security challenge. Two main concerns make tampering with root-level CAs a significant threat to security. First, root-level CAs don’t obtain their certificates from a higher authority; their certificates are self-signed. Second, all lower-level CAs trust the root-level CA. Therefore, if someone were to exploit a root CA, the security breach would compromise lower-level CAs as well.

To guard your network against a root-level CA security breach, I recommend that you use your root-level CA to assign certificates only to subordinate CAs, never to users. If you reserve the root-level CA for this purpose, you’ll use this CA infrequently and can safely take it offline until you need to add a subordinate CA. Note that no one can bring a subordinate CA online unless he or she has access to the root CA. Therefore, using the root CA only to assign subordinate CAs and otherwise keeping it offline greatly reduces your risk of a security breach.

Protection for all CAs. Let’s consider some general techniques that you should apply to all CAs on your network. First, you need to protect your CAs from tampering. You might think that guarding against tampering is superfluous, given that digital certificates are based on public-key information, which anyone can access. However, although a user’s private keys typically reside elsewhere, the CA contains its own private key. You must protect the CA’s private key against theft to prevent anyone from impersonating the CA.

The best way to guard your CAs from tampering and other damage is to implement strong physical security. If intruders or malicious users gain physical access to a server, they can easily use a utility such as Winternals Software’s ERD Commander 2002, intended for repairs in a console-mode Win2K or Windows NT environment, to completely bypass any security that you might have assigned to the server. Therefore, you need to implement physical security for your CAs. Take advantage of measures such as door locks, case locks, and fire-suppression systems.

To harden your CAs, perform thorough security audits regularly—particularly before and after making any major changes to your CAs. As you conduct such audits, watch for anything that could potentially affect your CAs’ integrity. For example, you should check to make sure that no unauthorized person has been granted permissions to change a root-level CA linked to a subordinate CA. (If you’ve implemented auditing, this information will appear in the Security log.)

You can also help secure your CAs if you remember that the more code you have on a system, the more likely it is that someone will exploit that code. Make sure that no one installs applications on your CA servers, and disable any unused services—especially any Microsoft IIS services—that you don’t use. Also, configure your security policies to specifically deny access to your CAs to everyone who doesn’t require it.

Backing Up Your Certificate Databases
By far the most important way to protect your CAs is to guard your certificate databases against failure. Safeguarding these databases is particularly important because if something were to happen to your server’s certificate databases, you’d have to create a new CA database and reissue existing certificates.

Your first step in guarding your CA against failure is to back up the CA database regularly. (At a minimum, backups should be performed daily.) The certificates are stored in a Jet database format similar to the format that Microsoft Exchange Server uses. Although you can use several methods to back up your certificate databases, I recommend that you use the Certification Authority Backup Wizard, which Figure 1 shows. In addition to backing up the CA database, the wizard backs up the private key associated with the CA.

To back up the certificate databases, open the Microsoft Management Console (MMC) Certification Authority snap-in and navigate through the console tree to the server that you want to back up. Next, right-click the server and select All Tasks, Backup CA from the resulting context menus. On the wizard’s introductory screen, click Next to move to the Items to Back Up dialog box. As Figure 1 shows, selecting the Private key and CA certificate check box backs up the private key and its corresponding certificate. I also recommend that you select the Issued certificate log and pending certificate request queue check box. This choice ensures that you’ll have an up-to-date copy of the log for reference and that you won’t lose track of certificate requests that haven’t yet been approved.

The Certification Authority Backup Wizard lets you back up the CA and the CA configuration information. In Figure 1, note the shaded Configuration information check box. You would select this check box to back up the configuration information for a standalone CA. Because Enterprise CAs store configuration information in Active Directory (AD), you don’t need to back them up separately.

The Certification Authority Backup Wizard doesn’t interface with your tape drive but directs you to save this highly sensitive data to a location that you consider secure. As Figure 1 shows, the wizard requires that you enter the pathname of an empty directory to which it can back up the files. In addition to selecting a secure location on the server in which to create the destination folder, you should use a completely separate tape from the one you use for your usual backups.

The next step in the process is to enter a password. The wizard explains that for message encryption and decryption, both a public key and a private key are required. You must enter a password that will be used to guard access to the private key.

After you supply a password and click Next, the wizard displays a summary screen. Click Finish to complete the backup. Upon completion, your backup folder will contain two elements: a subfolder containing a copy of the database and a file named .P12. This file contains all the private-key information on which the CA depends.

As you can imagine, after the CA database has been backed up, your backup media contain sensitive data. Be sure to take the necessary precautions to protect your backup media because someone who steals your CA’s private key can impersonate your CA and issue bogus certificates that your clients will trust.

Restoring Your CA
As you might have noticed, you use the same menu to select the option to restore a CA that you used to select the option to back up the CA. The restore operation uses the Certificate Authority Restore Wizard, which lets you restore any combination of data from the data that you’ve backed up. The wizard will direct you to stop Certificate Services before you perform the restore.

Remembering the Basics
As you work to secure your CAs, don’t forget to cover the basics. For example, make sure that your certificate servers have antivirus software installed, that the virus-definition files are up-to-date, and that the antivirus services are actually running. You should also check the antivirus software’s schedule for downloading virus signatures; I recommend downloading updated signatures at least twice per day.

Because you don’t want something as common as a hard-disk failure to cause you to lose the certificate databases, I strongly recommend that you use redundant hardware. If redundant servers are beyond your budget, at the least, use a RAID array with parity or a disk-mirroring solution for the partition that contains your certificate databases.

You also must apply all the latest service packs and hotfixes to your certificate server. These patches are designed to correct known bugs and security holes.

Safeguarding Your CAs
As you’ve seen, digital certificates, their issuing CAs, the CAs’ private keys, and certificate databases play a vital role in your organization’s security. Guarding your CAs against tampering and failure is one way to avoid compromising your organization’s security and functionality.