Last month, I showed you how to integrate directory and certificate services using Netscape’s Directory Server and Certificate Server so that users and systems can securely interact with one another (see "Integrating Directory and Certificate Services," March 1999). This month, I’ll show you how to use Microsoft Exchange Server’s Key Management Server (KMS) to integrate Exchange Server’s Lightweight Directory Access Protocol (LDAP) service with Microsoft Certificate Server 1.0. You can operate Certificate Server independently, but Exchange Server’s KMS and Certificate Server work best when you use them together.
Microsoft’s certificate and directory solution differs from Netscape’s solution in several ways. For example, you can install Netscape’s Messaging Server and Directory Server separately, but Exchange Server provides built-in LDAP support. Unlike Netscape’s solution, Exchange Server’s KMS includes a public key system for use with Exchange clients. This feature lets you use X.509 certificates without needing a certificate server, as long as Exchange Server controls the encrypted or digitally signed mail.
Microsoft integrated KMS with Exchange Server’s LDAP support, but only Exchange clients can use KMS. Certificate Server provides support for both client and server certificates and accepts standard Public Key Cryptography Standard (PKCS) #10 certificate requests that KMS doesn’t support. A hierarchical Certificate Server system can also support Web-based clients that KMS doesn’t support. Finally, Certificate Server provides standards-based support for features such as Certificate Revocation Lists (CRLs).
This article assumes you’re running Exchange Server and that you haven’t installed KMS or Certificate Server. After you install KMS on a system running Exchange Server and install Certificate Server on a system running Internet Information Server (IIS), you can install the Exchange Policy module to tie the two servers together to let your Exchange clients find one another and securely exchange information.
Architectural Overview
Microsoft’s Certificate Server links to KMS through the Exchange Policy module, as Figure 1 shows. Certificate Server supports only one such link and can’t issue Web-based certificates in this configuration because of the way that Microsoft developed the software. Instead, Exchange clients request and use certificates through KMS. IIS provides the link to Certificate Server’s Web-based client interface, which lets you remotely manage Certificate Server.
Organizations that must support Exchange Server and Web-based clients must use Certificate Server’s two-level hierarchy, as Figure 2 shows. Future versions of Certificate Server will support many levels (i.e., more than two). In the hierarchy in Figure 2, the root Certificate Authority (CA) issues CA signing certificates to low-level, non-root certificate servers that can also be CAs. The non-root certificate servers can support either Exchange Server or Web-based clients. In this model, the root CA can support any number of non-root CAs. Non-root CAs simply store certificates that the root CA issues. You need to run the root CA only to issue CA certificates and to create the root’s CRL. (For information about certificates and CAs, see my sidebar, "Digital Certificates 101," to March’s article.)
Whereas certificate servers connect to one another using a passive link (i.e., involving the user), a certificate server connects to Exchange Server and Web-based clients using an active link (i.e., the application performs the communication without user involvement). The active link between Certificate Server and Exchange Server lets Certificate Server process certificates that users request through KMS. One KMS server can support multiple Exchange Server systems. This functionality extends the Certificate Server hierarchy. Exchange clients receive certificates that Certificate Server signs through the KMS link. In turn, KMS provides key recovery services and handles digital certificates. The key recovery services let an administrator obtain a copy of a user’s public and private keys from a database that KMS maintains. In general, you want to isolate the servers running the root CA and KMS from users for security reasons.
Installing and Configuring KMS
You can install KMS when you install Exchange Server, or you can add it later by running the Exchange Server setup program again and adding KMS to the list of installed features. The KMS setup wizard steps through the installation process. One of these steps generates the KMS configuration key (i.e., password) that you need to provide whenever you start the KMS service. You can copy this password to a primary and backup disk or you can write it down and enter it whenever you start the KMS service in Windows NT.
The KMS password is different from the password you use to control the CA security settings in the Exchange Server Configuration Container. The default password for the Exchange Server CA is password, so you will want to change this password as soon as possible.
After the KMS installation wizard finishes, you must manually start the KMS service using the Services applet in Control Panel. You can set KMS to start automatically, but you must type in the password or install the password disk in the server every time you boot the machine; otherwise, the system will prompt you for the password before starting the KMS service.
Exchange Server’s address book contains certificates that Certificate Server issues (or KMS issues in the absence of Certificate Server) to Exchange Server users. Systems running Exchange Server can exchange address book information, including certificates, using Exchange Server’s replication support. Exchange Server can also distribute certificate information through its LDAP interface. If Exchange Server searches for a user in the software’s address book using an LDAP request and doesn’t find a listing for the user, Exchange Server checks any LDAP servers that the LDAP referral list includes, as Screen 1 shows. Exchange Server installs LDAP by default. You can enable LDAP from the General tab in the service’s properties dialog box. After you finish installing KMS, you can install Certificate Server.
Installing and Configuring Certificate Server
Certificate Server comes as part of the NT 4.0 Option Pack. The Option Pack also includes updates to IIS, such as the Personalization System, that you will want to install. To install Certificate Server, select it from the list of options that the Option Pack setup program presents. The Certificate Server setup wizard will start during the setup process and help you configure Certificate Server.
The Certificate Server setup wizard consists of several steps. One of the first steps helps you set up the Certificate Server shared folder and working directories, as Screen 2 shows. Certificate Server keeps public CA certificates in the shared folder. Certificate Server uses the working directories to house the Microsoft Access database that the software uses to maintain the certificate database.
Certificate Server’s Web component lets an administrator or user install CA certificates in a Web browser by viewing a Web page and selecting the appropriate entries, as Screen 3 shows. Selecting a certificate from this Web page downloads the certificate file (which has a .crt extension) so you can view the file using Microsoft Internet Explorer (IE). When you open the certificate file, you see a dialog box, as Screen 4 shows, that lets you include the certificate in a list of trusted CAs. You specify the available certificate usages, such as secure email in this dialog box. You can also clear the Enable Certificate check box in this dialog box to disable a certificate. After you install a CA certificate in your Web browser, you can use the browser to create a secure link with any server that has a server certificate that a trusted CA signed.
The next step of the wizard lets you select the type of Cryptographic Services Provider (CSP) that Certificate Server uses, as Screen 5 shows. Microsoft’s CSP comes with the NT 4.0 Option Pack, but in theory you can use third-party CSPs. The Hash list box in Screen 5 defines the type of key that Certificate Server uses. MD5 is the default Hash type. The client that uses a certificate must support the certificate’s hash type. The Microsoft Certificate Server Setup dialog box also lets you use existing keys, such as those you obtain through IE or the Microsoft IIS Distributed COM (DCOM) server. Don’t use existing keys when creating a new CA.
Next, you need to decide whether your Certificate Server machine will be a standalone server or part of a hierarchy. A standalone server is always a root CA. A server that is part of a hierarchy is either a root or a non-root CA, depending on where the server is in the hierarchy. Remember that Certificate Server currently limits you to two hierarchy levels. If you select the non-root CA option, the next step of the wizard generates a CA request file. The computer you’re installing Certificate Server on sends this file to the root CA so that the root CA can return a signed CA certificate to your machine. Your non-root CA uses this certificate to sign certificates that the root CA distributes.
If you ever decide to change a root CA to a non-root CA (e.g., from a nonhierarchical architecture to a hierarchical architecture), you must reinstall Certificate Server by running through the setup process again. Certificates that Certificate Server signs before you make this change will not match those that it signs after the change.
One of the last steps in configuring Certificate Server is setting the Certificate Server identification information, as Screen 6 shows. Each certificate that the server signs contains this information, so entering this information correctly is important.
After you install Certificate Server, you must manually start the software as an NT service. After you start the service for the first time, you can schedule it to start automatically using the Services applet in Control Panel.
The Certificate Server setup wizard installs command-line utilities, including CertHier and CertUtil. You can use CertHier to configure a non-root certificate server in the CA hierarchy, but you must configure the server as a non-root certificate server for CertHier to run. You use CertUtil to verify and revoke keys, change settings, and provide a certificate server status check. You can also use CertUtil to generate the CRL. The setup wizard also installs a Web-based management interface that uses IIS Active Server Pages (ASP). The CertUtil features are available through the Web-based ASP interface.
At this point in the process, KMS and Certificate Server are running, but they aren’t working together. Fortunately, you can easily link the two servers.
Linking KMS and Certificate Server
Linking KMS to Certificate Server requires installing the Exchange Policy module. You can obtain this module from the Exchange Server 5.5 Service Pack 1 (SP1) CD-ROM’s \Eng\Support\KMS\Expolicy\operating system directory or you can download this module from Microsoft’s Web site.
You will also want to obtain a hotfix for Certificate Server from Microsoft’s FTP site at ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/certserv. This hotfix adds backup and restore facilities to Certificate Server and implements changes such as forcing all serial numbers to be positive. You need to stop the Certificate Server service using the Services applet in Control Panel before you install the hotfix. Don’t restart Certificate Server until after you install the Exchange Policy module.
To install the Exchange Policy module, copy expolicy.dll to NT 4.0’s system32 directory. You must register the Exchange Policy module using the regsvr32 program with the following syntax:
regsvr32 C:\winnt\system32\expolicy.dll
You can restart the Certificate Server service. The Certificate Server hotfix will look for the Exchange Policy module, which will link Certificate Server to KMS.
After you link the two programs, Certificate Server will use its CA signing key to sign certificates that you create using KMS. These signed certificates will be available from the directory that you can access through the Exchange Server LDAP Server. Connecting Certificate Server with KMS lets Exchange users share certificates with other Exchange users. You use Exchange Administrator to manage KMS. This interface supports bulk requests identical to Certificate Server’s bulk request processing.
One advantage of using KMS’s certificate enrollment is that Exchange Server can notify users about their new certificate mail. KMS generates a special one-time key, or token, for each certificate and sends a message with the certificate to the user. The administrator must provide the key to the user who can then respond to the message using the key. You can best distribute these tokens with Microsoft Outlook, but most Exchange clients can send the email messages. Unfortunately, this approach is not as secure as having the administrator deliver the key in person or using a secure channel, because someone might intercept the initial mail message.
After you enable Exchange Server security, you can create new user accounts with those user’s certificates. You can choose to forward certificates or generate matching tokens when you create each account.
You can use KMS to generate mail-related certificates, and Certificate Server to generate certificates for servers. Combining KMS and Certificate Server requires minimal maintenance other than authorizing new certificates.
Microsoft’s Certificate Server, KMS, and LDAP services work well for secure mail exchange. However, be aware that this approach is less integrated than Netscape’s solution for handling server certificates because Microsoft requires that you use a second mechanism, the Certificate Server ASP interface. Looking ahead, you can expect much better integration and setup in subsequent releases of NT and Certificate Server. For information about these advances, see the sidebar, "Future Integration".
