Ensuring secure transactions among Exchange Server users
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.