| Downloads |
|---|
| 21934.zip |
Security is one of the most discussed components of any network or Web site. Web sites and the servers on which they run need security because of the Web servers' widespread access. If the server connects to the Internet, it's even more exposed and potentially vulnerable to unauthorized users. If the Web server hosts an intranet, the server is usually contained within the LAN or WAN environment. Even intranets can be exposed to the Internet, however, because workers more frequently need remote access to applications. In such a case, the intranet is known as an extranet.
You can establish Web site security in many ways—from logon security that authenticates users to a server to security methods such as NTFS that authorize access to certain files or folders. Relying on the Windows 2000 security system to provide authentication and authorization security removes the need for you or your developers to develop your own security system. One way to take advantage of the Win2K security system is by using client certificates to authenticate access to your Web servers. Let's look at what certificates are, how you obtain them, and how you configure them.
What Are Client Certificates?
Client certificates are files that a Certificate Authority (CA) issues to vouch for an individual's identity. A CA is a trusted organization such as VeriSign. To be acceptable, client certificates must be from a CA listed in the certificate trust list (CTL) for the site. (You add site CAs to the CTL by using the CTL Wizard.) You can also list the CA in the CTL for the Active Directory (AD) domain or AD organization, if appropriate.
An alternative to purchasing certificates is to use Win2K Certificate Services to issue your own certificates. Issuing certificates is handy when you use AD because Certificate Services automatically publishes certificates to AD. Issuing your own certificates is also much less costly than purchasing third-party certificates. However, outside organizations might not trust certificates that you issue. Base the decision whether to purchase certificates from a CA or issue them yourself on who will authenticate users with the certificates. For example, if you're doing everything internally, you might use Certificate Services, which lets you control everything.
Client certificates have an advantage over a simple username and password because a CA issues the certificates and the authentication process using certificates doesn't involve the user after the user installs the certificate. The user's only involvement is installing the client certificate. This action relieves the user from remembering a password to log on to a site.
Using certificates also has disadvantages. First, clients must install certificates, so the process leaves room for error. Second, using certificates—Secure Sockets Layer (SSL) in particular—puts a heavy load on a Web server, thus slowing it down for all users. Third, certificates expire and require renewal, so the user or administrator must remember to renew the certificate before it expires. SSL adds a lot of management and performance overhead to a server. You must balance the headaches of SSL against your need for certificates.
Using Client Certificates
To require client certificates for authentication, you must enable SSL for a site. (For a more detailed description of SSL and how it works, see Allen Jones, "SSL Demystified," December 2000.) Enabling SSL installs the SSL certificate. You can determine whether the site uses SSL by opening the Microsoft Management Console (MMC) Internet Information Services snap-in, opening the Properties for the site, then clicking the Directory Security tab, which Figure 1, page 8, shows. If View Certificate and Edit are enabled, the site has a certificate installed. You can check the SSL settings by clicking Edit on the Directory Security tab and selecting the Require secure channel (SSL) check box, which Figure 2, page 8, shows.
You can assign a server certificate (i.e., a certificate assigned to a server instead of a user) to one Web site or to multiple Web sites. (You can't install a certificate on a virtual directory.) To install the server certificate, you can use either the Web Server Certificate Wizard or the CTL Wizard. Follow these steps to start the Web Server Certificate Wizard:
- Open the Internet Information Services snap-in.
- Right-click the Web site in which you want to install the certificate, then select Properties.
- Click the Directory Security tab, then click Server Certificate to start the wizard.
If you don't have a certificate installed, the wizard will step you through building the request. Then, you can send that request to a CA. When you've received the certificate from the CA, run the wizard again and walk through the steps to install the certificate. You can obtain a free test certificate that works with IIS from http://www.thawte.com.
After you've installed your server certificate, you must take two steps before users can use client certificates. First, you must enable the use of client certificates on the Web site. Second, you must map the client certificates to valid user accounts.
To enable certificate authentication, you must configure the Web server to request the certificate from the client's Web browser, then map client certificates to user accounts. Enabling client certificates in a Web site is easy. In the Internet Information Services snap-in, click the Directory Security tab in the Web site's properties, then click Edit under Secure communications to display the Secure Communications dialog box.
Select the Accept client certificates check box under the Client certificates heading, as Figure 2 shows. This selection enables client certificate authentication and gives users with the certificate and other credentials (e.g., username and password) access to the Web site. You can optionally set Require client certificates to force users to have a client certificate for authentication. The Ignore client certificates option simply disables recognition of certificates as a means of authentication.
When a user visits a site set up for client-certificate authentication, IIS asks the browser for the client certificate. IIS examines the information in the certificate and uses the user account associated with the certificate to log the user on. When IIS has verified the user with the user's certificate, the user is authenticated and can use the site.
Mapping Client Certificates to User Accounts
To assign a certificate to a user, you must map certificates to user accounts. IIS offers a mapping feature that you can use both with nondomain accounts and with AD accounts. If your Web server is part of a domain, you can use native Win2K AD mapping.
You can map one certificate to one user account (called one-to-one—1:1—mapping), or you can map multiple certificates to one user account (called many-to-one—M:1—mapping). For example, you can issue certificates to all or certain employees, then use the Internet Information Services snap-in to map those certificates to the employees' user account.
1:1 mapping. Before you can map a certificate to a particular account in 1:1 mapping, you must have a copy of the client's certificate. A copy of a client certificate has a .cer, .crt, .spc, or .key extension. If you obtained the certificates to provide them to users, then you should have the certificate files for each user's certificate. If you're setting up security for people who aren't in your organization, the users might need to send you a copy of their certificates. The Web-exclusive sidebar "How to Export a Certificate" explains how users can send you a copy of their certificates.
Now that you have a client certificate, you can map it to a user account. In the Internet Information Services snap-in, return to the Web site properties and open the Secure Communications dialog box from the Directory Security tab. Select the Enable client certificate mapping check box, then click Edit. On the 1-1 Properties dialog box, which appears when you click Edit, click Add to open the File Selection (Open) dialog box. Navigate to the .cer file you exported from Microsoft Internet Explorer (IE) or to any valid client certificate you want to map an account to. Select the file, then click Open to open the Map to Account dialog box.
Enter a name for the mapping, or select the username, then enter the user's password. This action is the only sticky part of the mapping process because you must know the user's password or ask the user to enter the password.
Use the name of the user you're mapping so that you can identify which certificates are mapped to which accounts. When you've completed the entries, click OK, confirm the password to complete the mapping, then add the new mapping to the Account Mapping dialog box. This dialog box shows the mapping name and the user account to which the certificate is mapped.
M:1 mapping. Instead of mapping each client certificate to a user account, you can map many certificates to one user account. This technique is useful when you have external users who need access to a site and don't have user accounts on the server or domain. For example, you could map all the users from a client named YourCompany to one user account.
To map M:1 relationships, you must set up mapping rules in the Account Mapping dialog box. Click Add to start the Mapping Wizard. On the first page of the wizard, enter a description for the rule, then click Next. Click New to add a rule element to control the mapping. In the Edit Rule Element dialog box, which Figure 3 shows, you configure the characteristics for the rule element. For example, you can map certificates based on the user's email name that the certificate contains. M:1 mapping isn't as secure as 1:1 mapping because you're mapping to information in a certificate and not to the certificate.
You can add multiple rule elements to a rule by repeating for each element the process I just described. When you've finished adding elements, click Next. In the Account Mapping dialog box, select the user account to map to as you did in the 1:1 mapping. You can also reject users who match the rule by selecting Refuse access. When you've completed the settings in this dialog box, click Finish, then confirm the password to complete the mapping.
When setting up your wildcard rules, make the rules as explicit as possible. For example, you can review the detailed properties in the certificates or work with the external organization to discover which subfields are available and how you set them (i.e., what type of values they contain and what they represent). Then, you can make your mappings explicit because you understand the contents of the client certificates.
The rules you define are applied in the order in which they appear in the M:1 Properties page. You can change the order by moving rules up or down in the sequence. You can also disable a mapping by selecting the rule, clicking Edit, then clearing the Enable this wildcard rule check box. You can edit the other properties of a rule by following these steps and clicking the appropriate tab. When you've completed all your mappings, click OK to close the Account Mappings dialog box, then close the other dialog boxes.
If you use both 1:1 and M:1 mappings, the 1:1 mappings take precedence. Therefore, you can be specific in mapping groups and individuals. For example, you might map users from YourCompany with wildcards, but map one or two specific individuals with specific 1:1 mappings.
Hints for Using Certificates
After you've set up the server certificate and mapped the client certificates to user accounts, you can start using certificates for authentication. However, you need to be aware of several facts about client certificate usage. All certificates are valid for a certain period. For example, a client might have a personal certificate from VeriSign that's valid from January 1, 2001, through December 31, 2001. After the certificate expires, the client can't use the certificate to access the site until the certificate is renewed.
Certificates can be revoked for several reasons. For example, if an employee leaves a company or is fired, you should immediately invalidate the employee's user account and revoke the person's certificates. In addition, VeriSign can revoke a client certificate and place the certificate on a Certificate Revocation List (CRL—a list of revoked certificates). You can also revoke certificates that you issue with Certificate Services.
A CRL contains the serial numbers of certificates that have been revoked and the date and time of the revocation. Figure 4 shows the CRL details for a personal certificate that uses the certificate features of IE 5.5. To display the certificate details in IE, follow these steps:
- Open IE, then select Tools, Internet Options.
- Click the Content tab, then click Certificates.
- Select the certificate, then click View. This action brings up a summary of the certificate, including whom it was issued to, the CA who issued it, and the certificate's validity period.
To find the CRL for the CA who issued the certificate, click the Details tab, then select the CRL Distribution Points entry. The CRL path for that certificate appears at the bottom of the dialog box.
For example, to determine whether a client certificate that VeriSign issued is valid, you go to http://crl.verisign.com/class1.crl. Download the CRL to your system, then double-click the file to open it so that you can examine the revoked certificates. IIS also checks the CRL to make sure that a user's certificate isn't on the CRL before IIS validates the certificate. In addition, IIS makes sure the certificate is valid by checking its dates. If IIS finds a certificate that's invalid, IIS displays an error in the browser similar to the error
The page you are trying to view requires the use of a valid client certificate. Your client certificate was revoked, or the revocation status could not be determined. The certificate is used for authenticating you as a valid user of the resource.
This error points out that either the certificate has been revoked or the revocation status can't be determined. In this case, VeriSign issued the certificate, and IIS didn't have access to the VeriSign CRL when the user accessed the Web site through IIS. Therefore, IIS couldn't determine whether the certificate was valid and, as a result, denied access to the site.
In addition, Certificate Services publishes a CRL; with this CRL, IIS can check certificates against the CRL on the intranet without having to access the Internet. If you use Certificate Services, check the product documentation and set the publish (i.e., valid) period of the CRL to a short period that matches your company's security policies.
Using Certificate Information in Other Applications
Many applications can use client certificates. For example, Microsoft Outlook can sign email messages with the same certificate that IE uses.
Developers can use Active Server Pages (ASP) code to access certificate information. The IIS online documentation describes how to access certificate data, but most of the script examples in the documentation aren't correct because of syntax errors. I corrected the errors and built an ASP script with the corrected code. You can download this code as Web Listing 1 from the Code Library on the IIS Administrator Web site (http://www.iisadministrator.com).
Words of Caution
Certificates are useful for authentication in Web applications, but note a few words of caution. Certificates don't encrypt data; rather, they identify someone or something. For example, when it uses SSL, the server certificate doesn't encrypt the SSL channel. Instead, the server certificate identifies the server to the client. When a user visits a site that uses SSL, the browser asks the server to identify itself by means of its certificate. The browser can check the CA and the dates on the certificate to make sure the certificate is valid and thus authorize SSL with the server. After the browser authenticates to the server, the browser and server agree on a key that's used to encrypt the channel.
Another point to consider is certificate performance and maintenance. SSL puts a performance load on the server and slows down the application because all data sent through the SSL channel is encrypted. For that reason, most Web applications that use SSL put the part of the application that uses SSL in a separate virtual root or site and link to it as needed. For example, when you access the check-out features of an e-commerce site, the part of the application that's used for check-out processing is stored in the virtual directory or site that's set up with SSL. Thus, the SSL lock icon appears when you reach that part of the check-out process.
Certificate maintenance is also a concern. For an intranet, you must handle the acquisition and distribution of the certificates. You can automate this process by using Certificate Services to generate the certificates and link them to AD. You can also use native Win2K AD mapping to let AD manage the certificates. No matter which approach you use, however, you must deal with certificate creation or acquisition and updating those certificates when they expire or are revoked.
In addition, certificates can cause security problems because users can let other people access their certificate. If someone has access to a certificate or a computer on which the certificate resides for the account the user is using, that person can access any site to which the certificate grants access. People can also obtain a certificate under false pretenses. Earlier this year, the news media reported that someone obtained two certificates by falsely claiming to work for Microsoft.
Client certificates are a useful way to authenticate users. However, you must consider the management and performance overhead associated with certificates as you determine whether they're right for your organization.
