Preinstallation

[Previous] [Next]

Before you can successfully and securely install the CA, you must understand some concepts and be able to answer some questions that you'll be asked during the installation and setup process.

Understanding Certificate Authority Roles

In general, a CA can function in four separate roles. These roles determine what the CA's certificates are used for, which in turn determines what your users and computers will be able to do.

Enterprise Root CA

A root CA sits at the top of a certificate chain, as described in the section "Public-Key Infrastructures" in Chapter 17. An enterprise root CA, then, serves as the root CA for an entire enterprise—it occupies the topmost position in the certificate trust chain for all certificates issued by any component of the organization. The enterprise root CA can issue certificates for subordinate CAs, users, and computers, but as a practical matter, it will normally issue only subordinate CA certificates. Those subordinates are then responsible for issuing certificates to users and computers in the organization. Splitting certificate issuance that way allows you to delegate authority to issue certificates to the lowest possible level in your organization, while still maintaining robust control over the content, format, and use of those certificates.The enterprise root CA self-signs its certificate, asserting that it is the root by that signature. This allows it to issue certificates for individual users, computers, and subordinate CAs. Once the enterprise root CA is installed, it functions as an enterprise CA (as discussed earlier in the chapter).

Enterprise Subordinate CA

The enterprise subordinate CA requires a CA certificate issued by a root CA, so it forms a link in the certificate hierarchy. It acts as an enterprise CA, so it requires Active Directory access; it can issue certificates to subordinate CAs or directly to end users and computers.

Stand-Alone Root CA

The stand-alone root CA behaves as a stand-alone server—it doesn't have to participate in Active Directory, but it can. This independence is an advantage. You can easily disconnect a stand-alone CA from your network so that it remains secure from network-borne attack attempts. Many organizations use stand-alone root CAs for issuing their most valuable certificates, including subordinate CA certificates, because of the extra security gained by keeping the CA computer network free.

Stand-Alone Subordinate CA

Like its root counterpart, a stand-alone subordinate CA can use Active Directory but isn't required to. It issues certificates only to end users (typically people, since without Active Directory there's no reason to issue certificates to computers).

REAL WORLD  Protecting the Jewels

---

Since CAs can issue certificates, and since certificates form the backbone of the Windows 2000 access control and security features, you need to take special measures to protect your CAs from compromise or loss. It's tempting to think of a CA as just another server, but remember that it's more valuable than the average server. At a minimum, Microsoft recommends that you complete the following tasks to secure your CAs:

• Protect them against physical damage or tampering. Lock your CAs in a secure area with good physical access control and fire suppression. Keep tight control over who has access to the machines, and make sure you take advantage of whatever security features your server vendor has included.
• Protect them against data loss. You need to diligently back up your CAs, since losing the CA's private key will prevent you from recovering user certificates and will force you to reissue every certificate the CA has issued in the past.
• Protect your server against hardware failures and viruses. If you lose access to the CA's database you won't be able to recover certificates.
• Protect your CAs' private keys. It's easy to store the CA keys in an encrypted file; in fact, Microsoft makes this the default. However, the big stand-alone CA providers like Thawte, GTE CyberTrust, and Verisign all use special-purpose hardware devices to store the keys. These devices, which range from PC cards to the titanium-encased SafeKeyper, let you store your keys in a tamperproof hardware enclosure that makes the keys available only to authorized applications.

To get the most bang for your security dollar, you need to apply these three measures appropriately to each CA, along with the Windows 2000 access control and auditing features. Depending on how your certificate hierarchy is organized, you might need to do more to protect a higher-value asset (like your enterprise root CA) than a lower-value one, but that doesn't mean you should ignore subordinate CAs.

Preparing for Installation

You need to perform several tasks before you can install Certificate Services. As part of the installation process, your CA will either issue and sign its own root CA certificate or request a certificate from another CA; to avoid having to repeat this process, it's best to have all the needed information available before you start the installation.

First determine what kind of CA you want. If you want to use an enterprise CA, you'll need to have Active Directory installed; you can install stand-alone CAs with or without Active Directory. Also consider whether you'll want to use advanced options. Certificate Services uses a set of programming interfaces that Microsoft calls CryptoAPI. Each set of cryptographic routines on a Windows 2000 system has to be packaged as a CryptoAPI CSP. By installing and removing CSPs, you can customize the set of cryptographic algorithms that your servers use. In fact, that's just what Microsoft's High Encryption Pack for Windows 2000 does—it installs CSPs with stronger algorithms than the default versions included on the Windows 2000 CD. Normally, a Certificate Services installation will use whatever CSPs it finds on your server. However, you can instruct it to use, or not use, specific CSPs if you want to.