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.
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 are able to do.
A root CA sits at the top of a certificate chain, as described in the section Public-Key Infrastructures in Chapter 18. 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 normally issues 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).
Microsoft recommends taking the root CA offline and storing its signing key in a secure vault once the appropriate subordinate keys are generated. This minimizes the chance that the root CA security will be compromised.
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.
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.
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, because without Active Directory there's no reason to issue certificates to computers).
Real World
Protecting the Jewels
Because CAs can issue certificates, and because certificates form the backbone of 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:
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.
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 uses whatever CSPs it finds on your server. However, you can instruct it to use, or not use, specific CSPs if you want to.