The Certification Authority Snap-In | Microsoft Windows 2000 Server Administrators Companion

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:

Revoked Certificates Lists all the certificates that have currently been revoked. Right-clicking this folder, pointing to All Tasks, and choosing Publish allows you to publish a new CRL (although you'll get a warning message if your existing CRL is still valid).
Issued Certificates Lists the certificates that this CA has issued. You can right-click individual certificates and use the Revoke command.
Pending Requests Shows the requests that are stuck at the CA waiting for you to approve or disapprove them. Remember, for enterprise CAs, this list is always empty; for stand-alone CAs, it might contain zero or more requests at any given time.
Failed Requests Lists requests that failed or were rejected, including the common name, e-mail address, and submission date of the failed request.
Policy Settings Lists the certificate templates that are available on this server. You can add templates to the list by right-clicking the Policy Settings folder, pointing to New, and choosing Certificate To Issue, or you can remove templates by right-clicking the target item and choosing Delete. You can view the specifics of individual templates by double-clicking them, but there's no way to modify the contents of a template item.

Managing the Certification Authority Service

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.

Starting and Stopping the CA

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 the CA

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:

The Private Key And CA Certificate check box forces the wizard to back up the private key and associated certificate that the CA uses. If you choose this option, the wizard asks you for a password that it uses to encrypt the private key and certificate data.
The Configuration Information check box is normally enabled for stand-alone CA servers; for servers that are using Active Directory, the configuration information is kept there instead. If you're using a stand-alone CA without Active Directory and want its configuration recorded, select this box.
The Issued Certificate Log And Pending Certificate Request Queue check box causes the wizard to copy the log file showing which certificates have been issued and the queue of pending requests. Failure to back this up could lead to a loss of queued requests if you have to do a restore, so you should leave it selected.
The Perform Incremental Backup check box allows you to avoid the overhead of backing up the entire log and queue each time. When it's checked, the wizard backs up only the entries that have been changed since the last backup. However, you must perform at least one full backup (with this check box cleared) before you perform your first incremental backup.
Use the Backup Location controls to specify which directory you want the backup material stored in. The backup folder is supposed to be empty; the wizard warns you if it isn't. You have to put each backup in a different location; for example, if you do one full and two incremental backups each week, you'll need three separate folders to store the backed-up files.

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.

Restoring the CA

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.

Renewing the CA Certificate

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.

Configuring the CA's Properties

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

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
%1	Full DNS name of the CA server
%2	NetBIOS name of the CA server
%3	Name of the CA
%4	Renewal extension period (for example, how long a certificate's expiration date is extended at renewal) for the CA
%5	Location of the domain root in Active Directory
%6	Location of the configuration container in Active Directory
%7	The 32-character "clean" version of the CA name, with punctuation stripped out and a hash of the name
%8	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

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:

Select the Allow Certificates To Be Published In The Active Directory check box to allow the exit module to load certificates into Active Directory, when present.
Select the Allow Certificates To Be Published To The File System check box to allow publication to the shared folder you defined at CA setup time.

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

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

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:

The Administrators group has the allow flag turned on for the Manage, Enroll, and Read Configuration permissions. Even though the Manage permission enables the other permissions, you can turn it off if you want to allow administrators to enroll users without managing the CA.
The Authenticated Users group has Enroll and Read Configuration permission.
The Domain Admins group has Manage, Enroll, and Read Configuration permissions.
The Enterprise Admins group has Manage, Enroll, and Read Configuration permissions.

Table 20-4. CA-related permissions

Permission	Allows
Approve Certificate	Approves or rejects a certificate request that has a pending status.
Enroll	Requests new certificates for users or computers.
Manage	Makes administrative and configuration changes to the CA. Granting or denying this permission does the same for all the other ones, too.
Modify Owner	Changes ownership of the CA objects.
Modify Permissions	Changes ACLs and access control entries (ACEs) on the CA.
Read Configuration	Reads configuration data from the local disk or Active Directory; this implies Read Control permission, too.
Read Control	Reads control information for the CA.
Read Database	Reads certificate information from the CA database.
Revoke Certificate	Revokes a user, computer, or CA certificate.
Write Configuration	Saves configuration changes to Active Directory or the local disk.

Working with Certificate Templates

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.

Setting Security Permissions and Delegate Access

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.

Enabling Automatic Enrollment

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:

Open the GPO you want to edit by using the Group Policy snap-in. (See Chapter 9 if you need a refresher on GPOs.)
Expand the GPO's Computer Configuration node, and then expand the Windows Settings, Security Settings, and Public Key Policies nodes.
Right-click the Automatic Certificate Request Settings folder, point to New, and then choose Automatic Certificate Request. The Automatic Certificate Request Setup Wizard appears. Click Next.
The second screen of the wizard appears (Figure 20-10). Choose the template that matches the type of certificate you want issued to newly enrolled computers, and then click Next.
The third screen of the wizard lists available CAs in the domain; choose the one you want to issue automatically generated certificates, and then click Next.
Double-check the information in the completion page of the wizard, and then click Finish to create a new automatic request.

Figure 20-10. The Certificate Template screen of the Automatic Certificate Request Setup Wizard.

Managing Revocation and Trust

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.

Publishing CRLs

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.

Changing CRL Distribution Points

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.

Controlling Which Trusted Certificates Are Distributed

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:

To import a new certificate and begin trusting it, right-click the Trusted Root Certification Authorities item, point to All Tasks, and choose Import. Tell the Import Wizard where the certificate you want to import lives; it loads the certificate into the list of trusted roots and displays it.
To remove a root certificate from the list, right-click it and choose the Delete command. You'll see a confirmation dialog box that warns you of the consequences of removing the certificate.
To edit the list of approved uses for a root certificate, right-click the root certificate name and choose Properties. A dialog box like the one shown in Figure 20-12 appears. Use the options in the Certificate Purposes group to specify what you trust this certificate to do. When the Enable Only The Following Purposes check box is selected, you can enable or disable specific purposes by selecting or clearing them in the list.

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.

Managing Certificate Trust Lists for a Group Policy Object

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:

In the Certificate Trust List Purpose screen of the wizard (Figure 2013), specify the prefix used to name the CTL, how long you want the CTL to remain valid, and for what purposes you trust CAs on the CTL. Click Next.

Figure 20-13. The Certificate Trust List Purpose screen of the Certificate Trust List Wizard.
In the Certificates In The CTL screen of the wizard, add CA certificates to the CTL (Figure 20-14). You can add CA certificates from the certificate store or from a file using the corresponding buttons. Click Next.

Figure 20-14. The Certificates In The CTL screen of the Certificate Trust List Wizard.
Designate a certificate to use for the CTL signature. The certificate you select here is used to sign the CTL, so be sure to choose a certificate that you have good control over. (That way, no one can steal it and spoof your CTL.)
Once you've chosen a signer for the CTL, you can choose to add a secure timestamp, which guarantees the date and time recorded in the CTL. However, you must have access to a secure timestamp service.
Provide a name and description for the CTL; these items are displayed in the MMC whenever the CTL is shown in a list.
Click Finish and the CTL is created. Once it is available, you can remove it or edit it (using the wizard interface) by right-clicking it and using the appropriate commands.

Managing Stand-Alone CAs

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.

Setting the Default Action for New Requests

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.

Changing Certificate Request Status

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.