Wouldn't it be nice if you could give your trusted users transparent access to your secure Web site? Then, users wouldn't have to enter their username and password every time they enter the site. One way users can communicate to a secure portion of your Web site without having to enter a username and password is by using Internet Explorer (IE) on a Windows NT system, after you configure Internet Information Server (IIS) to require challenge/response authentication. But what do you do if your users don't run NT or IE? The answer: Use Microsoft Certificate Server, a component of the NT 4.0 Option Pack. Certificate Server lets you create and use digital certificates to authenticate users, and lets users access their NT user accounts without having to provide credentials each time they log on.
Digital certificates are crucial to Web security. A digital certificate is an electronic document that computer systems use to identify and authenticate users who are browsing the Web, using email, and transferring files. One way to obtain digital certificates is through a Certificate Authority (CA), a third-party provider that issues digital certificates to individuals or systems based on verification of a user's identity. Certificate Server lets you act as a CA for your enterprise, empowering you to protect employee confidentiality, reduce cost of ownership, and improve quality of service. (For background information about CAs and digital certificates, see Tao Zhou, "You Can Be a Web Certification Authority," October 1997.)
Unfortunately, finding useful documentation for configuring Certificate Server is difficult. You can find odd snippets of information on TechNet and the Microsoft Web site, but this sketchy data isn't enough to get you going in a reasonable amount of time. In this article, I'll take you through the step-by-step Certificate Server setup and configuration process I discovered. I'll show you how to install Certificate Server, start the Certificate Authority service, and issue client certificates.
Getting Started
To begin, you need to have installed IIS 4.0, the Microsoft Management Console (MMC), and Certificate Server 1.0, all of which Microsoft includes on the Microsoft Windows NT 4.0 Option Pack CD-ROM. Microsoft has posted on its Web site (http://www.microsoft.com) a hotfix for Certificate Server 1.0 to fix a problem that stops users without client certificates from accessing an area with both Certificate and Anonymous access enabled. As I have worked with Certificate Server, I've found that you don't need to install this hotfix because you can work around the problem when you configure permissions, a process I'll explain later. (However, I have stumbled across a few other bugs for which no hotfixes exist.)
Install Certificate Server from the Option Pack CD-ROM. If you've already installed Certificate Server and haven't been able to get it to work, I'll let you in on a secret. The Certificate Server installation prompts you to enter state details of the CA in the Microsoft Certificate Server Setup window, which Screen 1 shows. If you don't enter the CA name in the State field, the IIS metabase doesn't correctly register the CA. Consequently, Certificate Server doesn't accept client certificates this CA signs. If you experience this problem, you must reinstall Certificate Server. However, when you reinstall, you might receive one of two error messages--a Certificate Server Configuration Wizard error, or a Windows NT Setup error. All I have been able to discover regarding these error messages is that they signal that the csback.gif, csbull.gif, and cslogo.gif files didn't copy from the Certificate Server root directory (usually C:\winnt\system32\certsrv) into the CertEnroll subdirectory. If you receive either error message, copy the files over manually.
Start the Certificate Authority service in NT from Control Panel, Services. If the service doesn't start, the cause might be that the service can't locate the certmdb.mdb Microsoft Access database. For a reason I can't discover, the Certificate Server installation sets up the Open Database Connectivity (ODBC) system Data Source Name to point to the Certificate Server root directory; however, the global.asa file in the CertAdm subdirectory points to the C:\winnt\system32 directory. The Certificate Server installation places the certmdb.mdb file in the C:\winnt\system32 directory. Therefore, modify the CertSrv system Data Source Name (from Control Panel, ODBC) to point to the certmdb.mdb file, as Screen 2 shows. Your CA service will now be up and running.
Setting Up Your CA
Your Certificate Server installation will prompt you to create a Secure Sockets Layer (SSL) key for your server. The SSL server key lets a Web server and client browser negotiate secure encrypted sessions. Without the SSL key, certificate-based client authentication can't operate on IIS 4.0. You can generate and sign the SSL server key request in one step on your server by selecting Automatically send the request to an online authority in the Create New Key dialog box, as Screen 3 shows. If you choose to create a key request file, you can use Certificate Server's certreq.exe command-line utility to certify the file. (You can use key request files to request server-key signing from a third-party CA.) When you have a signed key, the Certificate Server installation is complete.
Now you must add the CA you just created to the list of trusted CAs on the server by installing the server key in your browser. To do so, launch IE 4.0 on the server and browse to http://server name/certsrv/certenroll/cacerts.htm. A Web page titled Certificate Authority Certificate List will display, listing the CA key you just created. Click the hyperlink and select Open this file from its current location. You will see a prompt to install a New Site Certificate, which Screen 4 shows. Click View Certificate, verify that the key details are as you entered them, and click OK. You will see another prompt asking you to accept adding the certificate to your root store. Click OK.
Select View, Internet Options, Content, Authorities to verify that IE 4.0 has successfully added the certificate to its list of trusted authorities. You will see the CA you created in IE 4.0's Certificate Authorities list, which Screen 5 shows.
Finally, run the following commands from the IIS installation root directory (usually C:\winnt\system32\inetsrv). The commands update the IIS metabase with the details of the CA you created:
Iisca
Net stop iisadmin /y
Net start w3svc
Issuing Client Certificates
Now you can begin issuing client certificates. Client certificates install directly to the browser. (All recent browsers from Netscape and Microsoft support client certificates; however, I will focus on IE 4.0) From the client, browse to http://server name/certsrv/certenroll/ceenroll.asp. The Certificate Enrollment Form lets you enter the details of the client certificate. Fill out all fields as appropriate and click Submit Request. When you submit this request, you call IE 4.0's Web Server Enrollment Page. Click Download on that page to install the client certificate to the browser. You can verify that the client certificate has installed properly by selecting View, Internet Options, Content, Personal. You will see the client certificate in IE 4.0's Client Authentication window.
After you install the client certificate, you need to let IIS know that the certificate holder is thereby authorized to access the secure area of your Web site. Because IIS bases Web security on NT user accounts, IIS needs a way to map each client certificate to an NT user or group account on the server. IIS uses the Client Certificate Mapping table to achieve this mapping. To create a client certificate mapping, you must import each client certificate individually from text files. Importing client certificates from text files, although a clunky process, appears to be the only supported method to create the required mappings. Thus, a method is necessary to capture client certificates installed in client browsers and store them in a text file. The easiest way to capture and store client certificates is to cut Active Server Pages (ASP) code to write the client certificates to a file. Listing 1 shows ASP code that will write client certificates to a text file.
Create a directory on your Web server to store the ASP file, and modify the path in the code as appropriate to write the certificate information to. The modified path appears in callout A of Listing 1. To enable the ASP file to create the text file (cert.txt in Listing 1), you need to allow the directory write permission in IIS. To set up a prompt that asks the client to submit a certificate, enable both https and Anonymous access to the directory in which you store the ASP file. To enable https and Anonymous access, reference the ASP file as https:// rather than http://. Clients running this ASP file will receive a prompt requesting submission of a client certificate, which will subsequently write to the cert.txt file.
If a client browses the ASP file and no client certificate displays in the Client Authentication window, a problem exists with the CA information in the IIS metabase. To repair the problem, rerun the three commands from the IIS installation root directory (Iisca, NET STOP iisadmin /y, and NET START w3svc). The cert.txt file will now contain the client certificate, which will look similar to Listing 2. Copy callout A of Listing 2 into your favorite text editor, and save to a file.
Now you can create a mapping between this client certificate and an NT user account. Select the directory you want to secure from the IIS 4.0 Directory Security tab, and select the permissions you see in the Secure Communications dialog box that Screen 6, page 129, shows. This permission combination sets up a requirement for a valid certificate for Web access. Click Edit in the Secure Communications dialog box to create the client certificate mapping. (You can create wildcard mappings; however, here I describe only individual mapping.) Ensure that you select the Basic tab in the Account Mappings dialog box, which Screen 7 shows, and click Add to import the certificate text file you created when you copied callout A of Listing 2. You'll see a prompt asking for the certificate text file. Enter the path and filename for this file, and click OK. On the Basic tab of the Account Mappings dialog box, assign the mapping a name, enter the NT account name (e.g., the IUSR_server name) of the user who needs access to the secured area, then enter and confirm the NT user password of the account you want to map the client certificate to. A successful mapping will look similar to the one in Screen 7.
Congratulations—You're a CA
That's it! You have created client certificates for your users, captured those certificates to text files, and subsequently mapped the certificates to NT user accounts. Your users can now access your secured Web area without having to use the traditional username and password mechanism. Your users will be happy about the simplified Web access that client certificates make possible, and you'll sleep better knowing your secure Web areas are truly secure.
