Once you have the Certification Authority snap-in installed, notice that it includes one subordinate item for each CA on the target server. Each CA, in turn, has five folders shown below it. Each folder displays some sort of list, so you can customize the list columns and fields using the View submenu on the shortcut menu. Right-click the folder, and then use the Choose Columns and Customize commands until you've configured the list the way you want it. The five folders you can view under each CA are as follows:
The Certification Authority service actually runs as a standard Windows 2000 service, so you can manage it in two separate ways. First, you can use the Services item in the Computer Management snap-in to start and stop the service, set recovery options, change the security context it runs in, and so on. (See Chapter 10 for more on using the Services snap-in.) More interestingly, right-clicking the Certification Authority item, or one of the CAs beneath it, gives you access to some useful commands.
First is the Retarget Certification Authority command, which appears when you right-click the Certification Authority item. You use this command to change the CA server that you're managing. By default, the snap-in attaches to the local server unless you specified another one when you installed it. This command lets you pick another CA server in your domain and administer it instead. The remaining commands appear when you right-click an individual CA and choose the All Tasks submenu; they're discussed in the following sections.
You can stop and restart the CA with the Start Service and Stop Service commands. When you stop the CA, it simply stops—you don't get a chance to confirm your command or change your mind. The same is true for starting the service. Note that you have to stop the service before restoring the CA database, although the snap-in offers to do that for you when you try to do a backup.
Backing up and restoring the CA data is critical because if you lose the CA, you'll lose the ability to issue, revoke, or renew certificates for the CA's assigned domain. You can (and should) use the Windows 2000 Backup utility to back up the certificate database; you can also use the Certification Authority Backup Wizard, which is slightly easier to use for the task at hand. All the wizard does is copy the current state of the CA's data to a folder you specify; you can back up or archive those files easily without stopping the CA.
Selecting the Backup CA command starts the wizard, the first screen of which is just an introduction telling you what the wizard does. If the CA service isn't running, you'll be prompted to start it, because it must be active for the wizard to work. The second screen of the wizard, shown in Figure 20-6, is where you specify what you want backed up.
Figure 20-6. The Items To Back Up screen of the Certification Authority Backup Wizard.
This wizard screen provides the following options:
Once you complete the Backup Wizard process, you'll have a set of files in the specified folder. The file <caName>.p12 contains the private key material for the CA, and the Database folder contains the log files. Use your preferred backup tool to make a good copy of these files and you'll be able to restore the CA when you need to.
The Restore CA command runs the Certification Authority Restore Wizard, which in every way is the mirror image of the Backup Wizard. It requires that the CA service be stopped, and it lets you restore the data you backed up using the Backup Wizard. You can selectively restore any combination of the private key and CA certificate, the configuration data, and the issued certificate log and pending request queue. Select the appropriate check boxes, tell the wizard where your backup files are, confirm that you want the data restored, and restart the CA when you're done.
One caveat: if you want to restore a series of incremental backups, you must first restore the corresponding full backup and then repeat the process for each incremental backup—in the right order! This argues in favor of giving your backup folders descriptive names like Certserver backup\2002-0815.
Occasionally, you might need to renew your CA certificate. How often you do this depends on the lifetime you set for your CA certificate when you generate it, as well as on whether the CA's key has been compromised and how big your current CRL is. The Microsoft CA allows you to reissue a CA certificate with the existing key material or to generate a new key pair and use it in the new certificate. The former option is useful when you just want a new certificate (for example, because your current certificate is about to expire), whereas the latter is what you use when you need new key material (as in the case of a compromise).
When you right-click the CA and choose the Renew CA Certificate command, the snap-in first warns you that the CA service must be stopped to generate the renewal. If you choose to proceed, a dialog box explains why you might need a new certificate and asks you whether you want to generate a new key pair. Whichever option you choose, the snap-in does its work quietly, issues the new certificate, and restarts the CA service.
Each CA has a set of properties that you can define, including properties for its policy and exit modules. You change these properties in the CA Properties dialog box, which appears when you right-click a CA object and choose Properties from the shortcut menu.
The General tab of the Properties dialog box shows you the name and description for the CA; it also identifies the CSP and hash algorithm that the CA is using. You're stuck with all of these values—you can't modify them after the CA is created. You can also use the View Certificate button to display a certificate's details.
Remember that you can selectively enable and disable certificate capabilities (like code signing, client authentication, and so on) by opening the individual certificate's Properties dialog box and selecting the purposes for which you want to use the certificate. However, you can't add or remove purposes not specified in the original template used to issue the certificate.
The Policy Module tab shows you which policy module is currently active on your CA. In almost all cases, this is the Enterprise and Stand-Alone Policy module that Microsoft provides with Windows 2000. If you want to use an alternate module, you can click Select in the tab to select another one.
More interesting is the Configure button, which opens the two-tabbed policy module Properties dialog box. The Default Action tab lets you control what happens to incoming requests. For an enterprise CA, the Always Issue The Certificate option is permanently selected; stand-alone CAs can also use the Set The Certificate Request Status To Pending button, which is selected by default.
The X.509 Extensions tab (Figure 20-7) allows you to customize two sets of locations: where CRLs are published and where end users can obtain the CA's certificate. Both of these sets of locations are encoded as X.509 extensions in the certificate—hence, the tab's name. You can enable, disable, add, and remove publication points and access points using the controls in this dialog box. Table 20-3 lists the variables you can use to insert the server name, CA name, and other useful variables into the URLs you use to specify these points. Note that the URLs you provide are encoded into the certificate, but you must still make sure the CRLs and certificates are available at those places.
Figure 20-7. The X.509 Extensions tab of the Properties dialog box.
Table 20-3. Variables used to specify distribution points and authority access points
|Variable Name||Value It Is Replaced With|
Full DNS name of the CA server
NetBIOS name of the CA server
Name of the CA
Renewal extension period (for example, how long a certificate's expiration date is extended at renewal) for the CA
Location of the domain root in Active Directory
Location of the configuration container in Active Directory
The 32-character "clean" version of the CA name, with punctuation stripped out and a hash of the name
CRL suffix; used to identify the CRL after the CA certificate has been renewed
If you change any of the X.509 extension values, you'll have to stop and restart the CA before the changes take effect. This requirement holds true for most changes to the CA.
The Exit Module tab looks and works much like the Policy Module tab—it shows which exit modules your CA is configured to use. Unlike policy modules, which are strictly one to a customer, you can have more than one exit module in use at once; each is executed in sequence. Because Microsoft provides only one exit module, though, this point is moot unless you're using a third-party module. The Configure button in the Exit Module tab opens the exit module's Properties dialog box, which has only one tab: Certificate Publication.
The Microsoft exit module automatically publishes certificates into Active Directory (if present) or to the location that the certificate request specified. By using the Certificate Publication tab of the exit module's Properties dialog box (click Configure in the Exit Module tab to see this dialog box), you can turn publication on and off in two ways:
By default, the CA always publishes CRLs to the %SystemRoot%\System32\Certserv\Certenroll folder; each CRL is given a name starting with the letter c and containing the date it was generated, in YY/MM/DD format. If more than one CRL is generated on the same day, a suffix number is added. For example, c991031.crl is the only CRL published on October 31, 1999, while c9912252.crl is the second CRL published on December 25, 1999. You can take these files and publish them using HTTP, FTP, or other means, including manually or automatically loading them onto smart cards.
The Storage tab, shown in Figure 20-8, shows you where configuration and certificate data are stored. You can't change any of these values once the CA is set up, but having a way to double-check the file locations in case you need them can be useful.
Figure 20-8. The Storage tab of the Properties dialog box.
The Security tab gives you control over which users and groups can do what with your CA. You can apply up to 10 permission settings to the CA, shown in Table 20-4. By default, four groups have access control lists (ACLs) that give them some combination of these permissions:
Table 20-4. CA-related permissions
Approves or rejects a certificate request that has a pending status.
Requests new certificates for users or computers.
Makes administrative and configuration changes to the CA. Granting or denying this permission does the same for all the other ones, too.
Changes ownership of the CA objects.
Changes ACLs and access control entries (ACEs) on the CA.
Reads configuration data from the local disk or Active Directory; this implies Read Control permission, too.
Reads control information for the CA.
Reads certificate information from the CA database.
Revokes a user, computer, or CA certificate.
Saves configuration changes to Active Directory or the local disk.
Certificate templates give you an easy way to stamp out cookie-cutter certificates that you can use for well-defined purposes. Unfortunately, you can't edit the templates yourself, but with 19 different types, you should be able to find something to use for any role to which you need to issue certificates. When someone requests a certificate using your CA's Web enrollment pages (as described in the section Obtaining Smart Cards and Certificates in Chapter 19), he or she can choose any of the templates that are available. You determine which templates users can select by adjusting the security permissions on the templates.
Before you can adjust security permissions on a template, you must install the Active Directory Sites and Services snap-in. Then right-click the Sites node, point to View, and choose Show Services Node. When the Services node appears, expand the Services, Public Key Services, and Certificate Templates nodes.
At that point, you can right-click an individual template from the list in the MMC window, and then choose Properties to see that template's individual properties. When the Properties dialog box appears, switch to the Security tab (Figure 209). Adjust the properties to reflect the access you want individual users or domain groups to have; for example, if you don't want anyone to issue enrollment agent certificates, just deny full control to all users, and that's that.
Figure 20-9. The Security tab of the Properties dialog box.
You can use a Group Policy setting to allow automatic issuance of certificates for computers. This allows you to automatically generate, issue, and store a new certificate for each computer that joins your domain. As long as you have administrative privileges on the Group Policy object (GPO) for your domain, you can make this change by using the Automatic Certificate Request Setup Wizard. Here's what to do:
Figure 20-10. The Certificate Template screen of the Automatic Certificate Request Setup Wizard.
Certificates provide you with a way to securely verify the identity of principles on your network. However, just having a big bag of certificates doesn't help you with security—you must also make decisions about which certificates you trust, and you need a mechanism to "untrust" certificates if they're compromised or if, for some reason, the holder no longer needs (or should no longer have) them.
In the Windows 2000 public-key infrastructure (PKI), you codify decisions about trust by specifying which root CAs go on your CTL. You can specify CTLs for individual users and groups; you can also specify a default CTL as part of a GPO so that new users, computers, and groups inherit a default CTL that you specify. Likewise, you render certificates untrusted either by removing their issuing CA's certificate from the CTL or by revoking the certificate itself, depending on whether or not you issued it. (You can revoke only certificates that your CA issued in the first place.)
Revoking certificates is simple: open the CA snap-in, switch to the Issued Certificates node, right-click the target certificate, point to All Tasks, and choose Revoke Certificate. The command lets you choose a revocation reason. (The default is Unspecified, but you can also mark a certificate revoked for a particular reason, such as key compromise or a change in the user's affiliation.) As soon as you choose a reason, the certificate is revoked. There's no appeal; you can't "unrevoke" a certificate, but clients might not notice that the certificate has been revoked until they get the next CRL update.
When you revoke a certificate, Windows 2000 adds it to the CRL immediately, but the CRL isn't published right then—the server automatically updates the CRL and publishes it at the interval you specify. You can manually publish the CRL at any time by right-clicking the Revoked Certificates item in the CA snap-in, pointing to All Tasks, and choosing Publish. After asking you to confirm that you want to supersede the existing CRL, the snap-in forces the CA to publish the current CRL to the CRL distribution points you previously specified.
Windows 2000 can also publish CRLs on a schedule you set. The Properties dialog box for the Revoked Certificates item in the CA snap-in, as shown in Figure 2011, lets you control the interval at which CRLs are published. By default, CRLs are updated weekly, but you can specify an interval ranging from one hour to 9999 years. You can also turn off scheduled CRL publication completely; you might want to do this if you want to control the circumstances and timing under which new CRLs are issued.
Figure 20-11. The CRL Publishing Parameters tab of the Revoked Certificates Properties dialog box.
The CA honors any certificate publication information it finds in the incoming certificate request. However, it depends on you to specify where CRLs should be published and where the certificates should point for users who want a copy of the CA's certificate. You supply these locations in the X.509 Extensions tab of the Policy Module Properties dialog box (Figure 20-7). By default, CRLs and root certificates are distributed using HTTP, LDAP, and a shared folder, but you can turn off these distribution points and add your own at any time.
You can change the set of trusted root certificates that is distributed as part of a GPO. This enables you to build and deliver a certificate set containing only the CAs you want users in particular groups to be able to trust. Let's say you use a third-party root CA (like VeriSign) with your own enterprise subordinate CA. You could set up one GPO for each department and then tweak the list of CAs for that department so that the legal department, for example, doesn't trust any of your internal CAs.
You can make three basic changes to the root list in a GPO: you can import root certificates and add them to the list, you can remove an existing root certificate from the list, or you can change the root certificate's allowed roles. All of these possibilities require that you open the GPO whose trusted certificate list you want to modify and then expand it so you can see the Trusted Root Certification Authorities item. (You need to expand the Computer Configuration, Windows Settings, Security Settings, and Public Key Policies nodes.) At that point, you can do the following:
Figure 20-12. The General tab of the Certification Authority Properties dialog box.
This list of root certificates is distributed as part of the group policy; that means it will be available to all members of the group. Don't confuse this list with the CTL—more on that in a minute.
The CA list you manage in the Trusted Root Certification Authorities item is nothing more than a bag of CA certificates—there's no implication that your enterprise trusts them (or not). To use certificates issued by other CAs, you have to put them on the CTL; your CA signs the CTL and distributes it to indicate that you've designated the CAs on the CTL as trusted. You can import a CTL that you've generated on another Windows 2000 machine, or you can create a new one. Both actions occur in the Enterprise Trust node under the Public-Key Policies component of a GPO, and both are available as commands when you right-click the Enterprise Trust folder.
To create a new CTL, point to New on the shortcut menu and choose Certificate Trust List to open the Certificate Trust List Wizard. Once the wizard opens, you'll have to complete several steps to successfully create a new CTL:
Figure 20-13. The Certificate Trust List Purpose screen of the Certificate Trust List Wizard.
Figure 20-14. The Certificates In The CTL screen of the Certificate Trust List Wizard.
You already understand the differences between an enterprise CA and a stand-alone CA, but some subtle functional differences exist, too—two management tasks are unnecessary for enterprise CAs but mandatory for stand-alone CAs.
By default, a stand-alone CA is set to mark all incoming certificate requests as pending. This forces the requests into a queue of pending requests (shown in the Pending Requests item under the CA node), where they sit until a human operator either approves or rejects them. You can change this setting by opening the CA Properties dialog box, clicking the Policy Module tab, clicking Configure, and using the two options in the Default Action tab to change the default action from Set As Pending to Always Issue (or vice versa). Once this action takes effect, all incoming requests are treated as you specify, but this change won't affect any pending requests.
Let's say that you have some pending requests in your queue. How can you approve or reject them? The answer lies in the same place as it does for most other "How do I . . . ?" questions involving the MMC: the right mouse button. Right-clicking a request in the Pending Requests list allows you to approve or reject it.