Perusing Microsoft's Web documentation about its Certificate Services can lead to much confusion about how you should configure this powerful product. When you consider Certificate Services' capability to integrate with other applications and services —such as Active Directory (AD), Microsoft Exchange Server, Web applications, and Windows applications— you can see why people are confused.
Let's look at using Certificate Services to solve one problem: Suppose you want to use 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. You also want to use client certificates rather than set up a separate account for each user. This scenario takes advantage of only a fraction of Certificate Services' power, but it can demonstrate the core features of generating and managing certificates.
One of the most interesting aspects of Microsoft Internet Information Services (IIS) 5.0related security and Web applications is the use of certificates that map to user accounts. When you're using any type of certificate to identify a user, you must either purchase certificates from a public CA or create a CA and issue your own certificates. The latter method is useful in several situations:
- You need to issue certificates to employees for internal use only.
- Your extranet is accessible by a group of users who aren't employees and don't have accounts in your domain.
- Certificates are necessary for some other use in your applications.
- You need to issue certificates for test purposes.
A CA that you set up can issue certificates, but an external CA doesn't back up those certificates. As a result, certificates that you issue would be of little value for certifying a user to an entity outside your organization. However, you only want to use the certificates internally, so you and your systems can trust the CA (because your organization is the CA).
Before you install Certificate Services, you need to answer a couple of questions. First, do you want Certificate Services to integrate with AD? In our scenario, the answer is no: You need to generate certificates only for external use. External extranet users—not AD users—will be using the certificates, so AD doesn't really matter. Therefore, you can install Certificate Services either on a server that's part of the AD domain or on a server that isn't.
Second, will the server on which you're installing Certificate Services be the root CA? The root CA becomes the basis for all your certificates. As a best practice, a root CA should never issue end-user certificates. Ideally, you should set up a dedicated root CA that only issues root certificates. This approach isolates the root CA from all other certificates and traffic. Because you need to use the certificates to identify users only to your own organization, your Certificate Services server can be the root CA.
You can use Certificate Services to set up a CA in a few minutes. You'll need your Win2K Server CD-ROM or access to the installation files on your hard disk or network. You'll also need the Win2K Service Pack 2 (SP2) or SP1 CD-ROM or the network location. To set up the CA, you must install IIS 5.0 on the server. Finally, plan your CA server's name carefully: You won't be able to rename the CA server after installation.
Installing Certificate Services
You can now begin the installation process. All Win2K Server products include Certificate Services, which is essentially an upgrade of the Windows NT 4.0 Option Pack's Certificate Server. Certificate Services is no longer an add-on but rather a component of the Win2K Server installation. To install Certificate Services, you can simply select the Certificate Services check box during installation.
If you've already installed Win2K Server, follow these steps:
- Open the Control Panel Add/ Remove Programs applet and select Add/Remove Windows Components from the icon list.
- Select the Certificate Services check box.
- Win2K will warn you that you won't be able to rename the computer or remove it from a domain. Click Yes to continue.
- The Windows Components Wizard appears. Click Next.
- In the Certification Authority Type dialog box, select the Stand-alone root CA option, as Figure 1 shows. If you need to set options for controlling public/private key pairs, select the Advanced options check box. (You probably don't need to configure Advanced options for your extranet users unless they use certificates for a secondary purpose that requires generating public/private key pairs.) Click Next.
- Complete the steps necessary to identify your CA. Be sure to use a descriptive name for your CA's identification information: Don't simply enter CA or CA1. Whenever someone uses or references the CA name (e.g., to request a certificate through a browser), a descriptive name will clearly identify the CA server. For our purposes, I named the CA 32XRootServer, as Figure 2 shows. Click Next.
- To use the default folders as the CA database locations, click Next. In some cases, changing the CA database locations can be useful. For example, if you have several CAs, you can put their folders on a network disk and point all the CAs to the same certificate store at the network location.
- If IIS is running on the server, click OK to stop IIS. After the installation is complete, the system will restart IIS.
The system might prompt you to insert the Win2K SP2 or SP1 CD-ROM or enter the path to the requested service pack's setup files. As the installation proceeds, the setup process will pause while the system configures IIS and Certificate Services. When the setup is complete, click Finish.
To verify that Certificate Services is running, go to Start, Programs, Administrative Tools, Certification Authority and open the Microsoft Management Console (MMC) Certification Authority snap-in. If a Stop button (i.e., a black square icon) appears on the snap-in's toolbar, as it does on the snap-in that Figure 3 shows, Certificate Services is enabled. You can also check Certificate Services' status by entering the following Ping command at a command prompt:
If the server is running, you'll see a message that resembles the following: Connecting to bigboat2001\32XRootServer ... Server "32XRoot-Server" is alive. (As you can see, even pinging a CA returns the CA name—yet another reason for naming each CA carefully.)
You're Ready to Go
Several new folders now reside under the Default Web Site directory, the \system32 folder, and the hard disk's root (e.g., C:\):
- The CertServ folder contains the .asp files that the system uses to access Certificate Services. This folder also contains a copy of the CertControl folder.
- The CertEnroll folder contains the certificate revocation list (CRL) and the server's certificate. Copies of this folder reside in both the \iis and \system32 folders.
- The CertControl folder contains Certificate Services control files.
- The CertLog folder in the \system32 folder contains the Certificate Services database. If necessary, you can move this database after installation. For more information about moving the database, see the Microsoft article "How to Move the Certificate Server Database and Log Files" (http://support.microsoft.com/ support/kb/articles/q283/1/93.asp).
- The CAConfig folder also contains the server's certificate and a text file that identifies the CA. The system creates this folder below the hard disk root and shares this folder (for remote access over the LAN) as CertConfig.
Now that Certificate Services is running, you're ready to issue certificates. In Part 2 of this series, I'll show you how to set up your CA to issue certificates to your extranet users.