In "Using Win2K Certificate Services to Configure a Standalone CA, Part 1," January 2002, InstantDoc ID 23373, I showed you how to install and configure Certificate Services on a Windows 2000 machine to create a Certificate Authority (CA) and generate certificates that your extranet users can use to access your Web site. Now, let's take a close look at the second half of that proposition: issuing and mapping certificates.
Before you start issuing certificates, you need to make some important decisions: Who will be able to request and issue certificates? Because you're setting up the CA to issue certificates to extranet users, you have a couple of options for creating, distributing, and managing those certificates. You can give extranet users the access they need to request their own certificates, or you can assign someone the task of creating and distributing certificates.
Let's walk through the first scenario for both you and the user. After you know this basic scenario, you can create any tpe of solution. Your primary concern is to determine how your extranet users will access the Certificate Services site to request certificates. By default, the Everyone group has access to Certificate Services for requesting and reading certificates. All you need to do is send Everyone group members an email message that contains a link to your server:
Assuming your users access the server over the intranet or Internet, this URL's localhost variable would be either your server's name or a Data Source Name (DSN) name that points to the Certificate Services site. (You can also use an IP address to get to the server.)
Because the Everyone group has permission to request certificates, a group member visiting the URL will see the Welcome page that Figure 1 shows. To request a certificate, the user selects the Request a certificate radio button, then clicks Next. After selecting the certificate type—a Web Browser certificate, in this example—and clicking Next, the user enters demographic information and clicks Submit to send the request to Certificate Services. The browser shows a status message indicating that the server is processing the request. The server then instructs the user to return to the site after a designated number of days to check for the certificate. After the user receives notification that the server has received the request, he or she can close the browser.
What happens next depends on how you've configured Certificate Services. By default, for a standalone CA such as the one in our example, Certificate Services sets each requested certificate to a pending status. This scenario is probably best because when you receive a certificate request, you have time to choose whether to approve the certificate. You can use the certificate-request information to examine a user's demographic information and, for example, verify the user's credentials. Alternatively, you can choose to automatically issue all requested certificates—probably not wise, because then any user who stumbles across your site could retrieve a certificate.
After you approve a certificate request, you can use the Microsoft Management Console (MMC) Certification Authority snap-in to issue the certificate. Start the snap-in and open the Pending Requests folder. The snap-in lists new certificate requests, as Figure 2 shows. To issue the certificate, right-click the request, select All Tasks, then click Issue. Doing so adds the certificate to the Issued Certificates folder. To deny a request, select All Tasks, then click Deny.
To determine whether his or her requested certificate has been approved or denied, the user can select Check on a pending certificate on the Welcome page, then click Next. The certificate request will appear in a drop-down list. The user selects the certificate in question, then clicks Next. If you've approved the request, the user will see an Issued status. The user now needs only to click Install this certificate to install the certificate in Microsoft Internet Explorer (IE). Depending on the Internet connection speed, the installation process should proceed quickly.
Now that your new CA has issued certificates to your extranet users, how do you permit them to use their certificates to access your Web site? You need to set up Microsoft Internet Information Services (IIS) 5.0 to recognize certificates that your CA issues and map the certificates to a specified user account on your servers or in Active Directory (AD). Then, you can use that account to control access to the extranet site.
Consider the implications of this scenario. All your extranet users will have controlled access to your site, but you'll need only one Win2K user account for all users. If you perform such administrative actions as changing permissions or killing access to the site for the entire group, you need to make changes to that one account only. You have no user groups or accounts to manage. Of course, the downside of using just one account is that you can't track individual user actions or set user-specific security.
How do you map CA-issued certificates to a user account? Open the Internet Services Manager (ISM), access the Properties sheet for the Web site (i.e., the default Web site, another site, or a virtual directory), and select Directory Security. Next, in the Secure Communications section, click Edit. Select the Enable client certificate mapping check box. In the resulting Account Mappings dialog box, go to the Many-to-1 tab.
You're now ready to set up a rule that maps certificates that your CA issues to a valid user account. Before you start this process, choose the user account you want to use for the extranet. (I recommend that you set up this account before you start the mapping process.)
On the Many-to-1 tab, click Add, and the Rule Wizard will start walking you through the process of creating your rule. On the wizard's first page, enter a name for the rule. Give the rule a meaningful name (e.g., 32XEXTRANET) that suggests the rule's purpose. After you enter a name, click Next.
On the Rules page, set up a rule that matches your CA. To set up the rule, click New. In the resulting dialog box, select the certificate field that you want to match, then enter the matching text (e.g., name, city). From the Certificate Field drop-down list, select Issuer. Doing so sets the rule to match the field, specifying the issuer whose name is on the certificate.
Next, to determine which field to select in the Sub Field box (which appears automatically), examine the certificate. For example, if you have a system running IE 5.0 or later and have installed a certificate from your CA in the browser, you can check the certificate fields in IE. Open IE and select Internet Options from the Tools menu. On the Contents tab, click Certificates. Double-click the certificate you want to view to open it. Click Details, then click Issuer. The certificate's field names and their values appear in the bottom window. You can also select the text of the value you want to match and copy it to your clipboard. Then, you can go back to the Rule Wizard, select the field you want to match, and paste the clipboard contents into the Rule Wizard's Criteria field. Copying and pasting the value ensures that all capitalization and text are accurate.
Click OK to complete the rule, then click Next. Leave the default access setting at Accept this Certificate for Logon Authentication, then click Browse and select the user account to which you want to map the rule. Click Finish.
Users can now successfully access your site with a certificate that the CA issued. To control access settings for all these users, you can change the settings on the user account to which they map.
To control who can manage, request, and retrieve certificates, you can set security in Certificate Services. Open the Certification Authority snap-in, then right-click the CA's name and select Properties. On the Security tab, you'll see a display similar to the one that Figure 3, page 15, shows. You can add or remove users by clicking Add or Remove and selecting the appropriate permissions at the bottom of the dialog box.
You have another CA task to perform. Because a certificate backs each CA, and because each certificate has an expiration date, you must periodically renew that certificate. To renew a CA's certificate, open the Certification Authority snap-in and select the CA's name. Right-click the CA, select All Tasks, then click Renew CA Certificate. Click Yes to generate a new public and private key pair for the CA's certificate.
A final tip: If you plan to integrate Certificate Services with Microsoft Exchange Server, make sure the Certificate Services machine's server name contains fewer than 15 characters. (Exchange Server 5.5 doesn't support Certificate Services on servers with a server name longer than 15 characters.) Also, be sure to keep the CA server properly backed up.
Powerful but Problematic
Certificates are a useful but limited security technique. Keep in mind that users might find certificates clumsy and that the way they use certificates might leave your systems exposed. For example, if a user uses two or three systems, the user must have the certificate on each system to access your site. What if one or more of these systems are public browsers at trade shows or other public venues such as an Internet café? The user probably won't be able to install the certificates on all the systems that he or she uses. Even if the user can install all the necessary certificates, you risk having the user leave a certificate installed in a public browser that allows access to your site.
Remember that although certificates are powerful, they're not a panacea. Certificates are comparable to passwords: You assign a password to a user, and the user memorizes it—unless he or she writes it down. Like a written password, a user's certificate can be compromised if someone else has access to the system or any media that contain the installed certificate.
Certificates are a part of life today, and they're likely to become more prevalent over time. Certificate Services is a great tool for managing the request, creation, and issuance of certificates in most intranet and extranet scenarios. As with any type of security, of course, you must be aware of the caveats involved in using certificates—but you can work around many of the issues.