Windows 2000 Server and Key Management Server Interoperability

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : June 14, 2001

Operating System

Microsoft Product Support Services White Paper – Version 2.1

Written by David B. Cross, Windows Security; Gene Ferioli, Microsoft Consulting Services; Carsten B. Kinder, Microsoft Consulting Services

Published on March 14, 2000

Abstract

Microsoft® Exchange Server version 5.5 Service Pack 1 with Key Management server (KM server) introduced the capability to use X.509 V3 certificates with Exchange Server advanced security. With the robust public key infrastructure that is built into the Microsoft® Windows® 2000 Server operating system, you can combine KM server with a number of different certification authority configurations to achieve 128-bit advanced security with the Microsoft Outlook e-mail client. This white paper describes a variety of scenarios that integrate Windows 2000 Server certification authorities with Exchange Server 5.5 advanced security.

On This Page

Introduction
Certification Authority Setup
Scenarios
Installing Trusted Root Certification Authorities
KM Server Configuration
Troubleshooting
KM Server Forklift Upgrade Process
Exchange 2000 Server
Additional References

Introduction

Public key technology enables organizations to extend their businesses to the Internet, where strong distributed authentication and secure communication are critical to business-to-business and business-to-consumer interaction. The standards-based public key infrastructure (PKI) is interoperable with other PKI products in the Microsoft® Windows® 2000 Server operating system. Customers can deploy an integrated PKI as part of their server and desktop deployment, and manage that integrated PKI the same way that they manage other Windows 2000 Server security features.

Scope

This white paper describes Windows 2000 Server PKI interoperability with the Key Management server (KM server) component of Microsoft Exchange Server version 5.5, and Windows 2000 Server interoperability with other root certification authority (CA) providers. This white paper does not address Microsoft® Windows NT® Server version 4.0 setup or its interoperability with Exchange Server 5.5. This white paper also does not address third-party PKI products or solutions other than the use of a third-party CA as the root of a server hierarchy.

Operating System Requirements

For Exchange Server 5.5 KM server to use a Windows 2000 Server CA, both the KM server and the CA must be running the Windows 2000 Server operating system; if Exchange Server is deployed on Windows NT Server 4.0, Exchange Server cannot communicate with a Windows 2000 Server CA. The Windows 2000 Server CA can be installed on the same computer that KM server is installed on, or on a separate physical server. To facilitate this change in an existing deployment, you can upgrade a computer running a Windows NT Server 4.0 KM server and Microsoft® Certificate Server version 1.0 to Windows 2000 Server, and set up Certificate Services.

If an organization does not want to upgrade the Exchange Server 5.5 KM server to Windows 2000 Server, that organization can only use a Windows NT Server 4.0 Certificate Server. The policy module that is installed for Exchange Server 5.5 KM server is an exclusive policy that ensures that the certificates the Certificate Server issues are marked for e-mail [or Secure/Multipurpose Internet Mail Extensions (S/MIME)] use only. After this module is installed on any CA, that authority cannot service other types of certificate requests. Therefore, to support the KM server functions, a Windows 2000 Server CA must be a stand-alone CA; it cannot be used as an enterprise CA.

Windows 2000 Server CA Basics

Windows 2000 Server provides two classes of CAs: an enterprise CA or a stand-alone CA. The CA class is determined by the policy module that you select during installation. In each CA class, there are two types of CAs: a root or a subordinate. The policy modules define the actions that a CA can take when it receives a certificate request. A stand-alone CA has a very simple policy module and does not assume that Windows 2000 Active Directory™ is available. Note that if you change the policy modules, you can change the way the system functions.

CAs are organized into hierarchies that have the fundamental trust point, or root CA, at the top. All of the other CAs in the hierarchy are subordinate CAs, and are trusted only because the root is trusted. There may be more than one root CA for each Windows 2000 Server domain, and thus more than one hierarchy. A stand-alone subordinate CA has the following requirements:

  • It must be associated with a CA that will process the subordinate CAs certificate requests. Again, this could be an external commercial CA.

  • Administrative privileges on the local server.

X.509 V1 and X.509 V3 Certificate Differences

X.509 V1 certificates include fields for the version number, serial number, signature algorithm ID, issuer name, validity period, user name, and public key information for the user, and also include signatures on each of these fields. X.509 V3 certificates add fields for issuer-unique identifier; subject-unique identifier; and extensions, such as subject and issuer attributes, certification policy information, and key usage restrictions. You can use either version to digitally sign items (to verify the sender's identity and that the contents of the item have not changed) or to encrypt items. However, you can use only X.509 V3 certificates in S/MIME-specific encryption and decryption operations.

KM Server Basics

Exchange Server 5.5 has a Cryptography Service Provider (CSP) that isolates all of the KM server cryptography functions into one dynamic-link library (DLL). Versions of Exchange Server earlier than version 5.5 Service Pack 1 allow only one KM server for each organization. Multiple-site architectures must be configured so that individual sites point to one KM server. Exchange Server 5.5 Service Pack 1 KM server supports certificate trust lists, which allow cross-certification between organizations and up to one KM server for each Exchange Server site. Certificate trust lists contain certificates from other trusted CAs (even those outside the Exchange Server architecture), are signed by the root CA for the Exchange Server organization, and are stored in the Exchange Server directory. Certificate trust lists allow inter-organization and intra-organization webs of trust, which clients can use to validate certificates that are attached to or associated with received items. Administrators can easily revoke trust for certificates in the certificate trust lists, if necessary.

With the release of Exchange Server 5.5 Service Pack 1, computers running Microsoft Certificate Server can also become CAs for Exchange Server 5.5 Service Pack 1 KM servers. An organization can install multiple KM servers— up to one KM server for each Exchange Server site. However, if you choose to have multiple KM servers in your organization, be aware that user histories (old encryption keys) may be lost. If a site is modified to point to a new KM server, user key histories are lost. To minimize such loss, create new KM servers only when you create new Exchange Server sites. For Exchange Server 5.5 KM server to run properly on Windows 2000 Server, Exchange Server 5.5 Service Pack 3 must be installed.

Key Recovery

Exchange Server 5.5 KM server provides key recovery for users who lose keys or forget passwords. KM server can recover an encryption key pair so that an end user can access previously encrypted items. To prevent administrators from impersonating users, digital signatures are treated differently and are never stored or recovered. In Exchange Server 5.5, when the client generates a new key pair, the new public key is placed in the directory, in addition to the previous public key. (Certificate fields in the Exchange Server directory are multivalued.) If the client requests a certificate directly from a Microsoft CA, and not in conjunction with the Exchange Server 5.5 KM server, key escrow or key recovery capability is not provided.

Supported Clients

Exchange Server 5.5 KM server supports X.509 V3 certificates for Microsoft® Outlook® 98 and Microsoft Outlook 2000; these are the only clients that currently support S/MIME. Although Microsoft Outlook Express version 5.0 does support S/MIME capabilities, it is a POP/SMTP client only, and does not operate with the Exchange 5.5 KM server system.

Third-Party Root CAs

Most third-party CAs operate properly with a Windows 2000 Server subordinate CA. This white paper does not provide detailed information about third-party configuration, but to ensure compatibility, make sure that the following conditions are true:

  • The root CA conforms to Request for Comments (RFC) 2459.

  • The subject and issuer names on the root CA are identical.

  • The root CA signs subordinate CA requests with an expiration date that is later than two years after the date the subordinate CA requests are signed.

  • The root CA publishes a Certification Revocation List (CRL) distribution point in its certificates, in accordance with RFC 2459.

Certification Authority Setup

Certification Authority Setup

Exchange Server 5.5 requires a Windows 2000 Server certification authority (CA) for S/MIME 128-bit encryption. The following are general steps to install Windows 2000 Server Certificate Services for either a stand-alone root CA or a subordinate CA in a hierarchy.

Before you start:

  • Make sure that your account is in the Domain Administrators group. This group is in the Users folder. You must be an administrator to install the CA.

  • To install the Certificate Services Web enrollment pages, you need to ensure that Microsoft Internet Information Services (IIS) are already installed. Ensure that the computer running Microsoft Certificate Services does not have a name that contains more than 15 characters. Exchange Server 5.5 KM server does not support CAs that have names that contain more than 15 characters. To avoid future issues, do not use extended ASCII characters either.

To set up the CA:

  1. Click the Start button, point to Settings, and then click Control Panel.

  2. Double-click Add/Remove Programs. When an Add/Remove Programs dialog box similar to the following is displayed, click Configure Windows.

    Cc751428.win201(en-us,TechNet.10).gif

  3. Click Components.

    Cc751428.win202(en-us,TechNet.10).gif

  4. When a dialog box similar to the following is displayed, click Next.

    Cc751428.win203(en-us,TechNet.10).gif

  5. Click to select the Certificate Services check box, and then click Next.

    Cc751428.win204(en-us,TechNet.10).gif

    Note: If you want to use the Web components of the Certificate Services, click to select the Internet Information Services (IIS) check box. When a warning message is displayed, click OK. The Certificate Services Web components allow you to:

    • Connect to the Web page to enroll for a certificate.

    • Download a CA certificate from the Web page.

    • Save the certificate request to a file so that it can be processed by an external CA.

    When the Certification Authority Type dialog box is displayed, click one of the following CA types, as applicable:

    • Stand-alone root CA. You need a stand-alone root CA if you do not already have a stand-alone CA, or if you need a second root to use for another purpose.

    • Stand-alone subordinate CA. You need a stand-alone subordinate CA if this CA will be a member of an existing CA hierarchy. The parent CA in the hierarchy can be a stand-alone CA, a Windows 2000 Server enterprise CA, or an external commercial CA.

    Caution: An enterprise root or subordinate CA cannot be used with Exchange Server 5.5 KM server. However, Enterprise CAs will be supported by Microsoft Exchange 2000 Server KM server.

  6. Click to select the Advanced options check box to change the default cryptographic settings, and then click Next.

    Cc751428.win205(en-us,TechNet.10).gif

  7. Because you selected the Advanced Options check box, the Public and Private Key Pair dialog box is displayed, in which you can change the cryptographic settings, such as the cryptographic service provider (CSP), the hashing algorithm, and other advanced options.

    Cc751428.win206(en-us,TechNet.10).gif

    To support KM server, in the CSP list, click Microsoft Base Cryptographic Provider v1.0, and in the Hash algorithm list, click SHA-1. Make sure that the Use existing keys check box is cleared, and that in the Key length list, Default is selected.

  8. The CA Identifying Information dialog box is displayed. Type the identifying information that is appropriate for your site and organization. Note that the CA name (or common name) is critical, because it is used to identify the CA object created in the directory.

    You can only set the validity duration for a root CA. In the Valid for box, type a reasonable value to set the root CA validity duration. If you have subordinate Windows 2000 Server CA servers, make sure that the value is at least 3 (years). The KM server requires a certificate that is valid for at least two years; therefore, a subordinate CA or root must be able to issue certificates at least as long as the KM server can issue certificates.

    Root certificates that are valid for a short duration require additional management, because you must reissue root certificates to all of the client computers. The choice of a duration value is a trade-off between security and administrative overhead. Remember that each time a root certificate expires, an administrator must update all of the trust relationships and "roll" the CA to a new certificate. For information about how to modify the expiration date, please see the "Changing the Certificate Expiration Date" section of this white paper.

    After you type the identifying information, click Next.

    Cc751428.win207(en-us,TechNet.10).gif

    Note: The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.

  9. The Data Storage Location dialog box is displayed, in which you can define the location of the certificate database, the location of configuration information, and the location of the Certificate Revocation List (CRL). Click to select the Store configuration information in a shared folder check box to specify the location of the folder where configuration information for the CA is stored. In the Shared folder box, type a Universal Naming Convention (UNC) path for this folder, and make sure that all of your CAs point to the same folder. The CA Web client and KM server use this folder to determine CA configuration.

    If you are installing a CA in the same location as a previously installed CA, the Preserve existing certificate database check box is selected by default. Click Next.

    Important: Do not select the Preserve existing certificate database check box if you want to perform a new installation of the CA.

    Cc751428.win208(en-us,TechNet.10).gif

  10. If Microsoft Internet Information Service (IIS) is running, the following message is displayed. Click OK to stop IIS.

    Cc751428.win209(en-us,TechNet.10).gif

    You must stop IIS to install the Web components. If IIS is not installed, this dialog box is not displayed.

  11. If you are installing a subordinate CA, the CA Certificate Request dialog box is displayed. To locate an online CA, click Send the request directly to a CA already on the network, and then click Browse, or if you are making a request for a commercial CA or a CA that is not accessible on the network (such as an offline root CA), click Save the request to a file. If you create a file, you need to take the file to an external or root CA to be processed. The CA provides you with a certificate. To enable your CA, use Microsoft Management Console (MMC) to install this certificate. For more information about this procedure, see the "Installing a Subordinate CA Certificate from a Request File" section of this white paper.

    Cc751428.win210(en-us,TechNet.10).gif

  12. The Installing Components dialog box is displayed. Wait until the installation finishes.

    Cc751428.win211(en-us,TechNet.10).gif

  13. If you are creating a certificate request to a file, the following message is displayed. Click OK.

    Cc751428.win212(en-us,TechNet.10).gif

  14. Click Finish.

    Cc751428.win213(en-us,TechNet.10).gif

    After you finish the installation, take the certificate request file that you created to the root or signing CA and have the request processed. Either a Microsoft Windows 2000 Server root CA or a third-party root CA can sign the request.

    After you have your new certificate, use the Certificate Services MMC to install the certificate and enable your CA. For more information about this procedure, see the "Installing a Subordinate CA Certificate from a Request File" section of this white paper.

Note: The root CA administrator needs to return both the signed request certificate and its own root CA certificate. If you do not already have the root CA certificate in the subordinate CA root store, you are prompted for it when you install the signed certificate request.

To Verify Certificate Services Installation

Perform one of the following steps to verify that the Certificate Services installation was successful:

  • At a command prompt, type net start, and then make sure the Certificate Services are running. This is the simplest way to verify Certificate Services installation.

  • For an enterprise CA, click the Start button, point to Programs, click Administrative Tools, click Certificate Manager to start Certificate Manager, and then request a certificate.

  • For a stand-alone CA, request a new certificate by using Microsoft Internet Explorer version 5.0 to connect to the following URL:

    https://local_host/certsrv

    where local_host is the name of the server.

Installing a Subordinate CA Certificate from a Request File

Use the procedure outlined in this section only when a subordinate CA has been installed by using a certificate request file.

Before you perform the following steps, make sure that you take the certificate request file that you generated to your root CA for processing. Your root CA administrator provides you with a certificate for this file. If you submit this file to a Microsoft Certificate Service, you may want to refer to the Windows 2000 Server help files for detailed steps on this process.

Note: The following steps use the Certification Authority MMC.

  1. Start the Certification Authority MMC.

  2. Right-click the CA that you want to install with a signed certificate from a root CA.

  3. Click Install CA Certificate.

  4. Follow the steps in the wizard and select the file that contains the certificate that your root CA signed and provided.

  5. Finish the setup.

Changing the Certificate Expiration Date

Certificates issued to the KM server for S/MIME users must be valid for at least two years. If the certificates have an expiration date that is less than two years from the date the certificate is issued, they do not function properly. To change the certificate expiration date, modify the registry values in the following registry location on the Windows 2000 Server CA that issues certificates to the KM server:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \CertSvc \Configuration your_CA_name

Where your_CA_name is the name of the Windows 2000 Server CA. The default settings are:

ValidityPeriod REG_SZ = Years

ValidityPeriodUnits REG_DWORD = 1

Change the ValidityPeriodUnits value to 2 or more on the CA that the legacy policy module is installed on, stop and restart the computer running Certificate Server, and then try to enable X.509 V3 certificates again on the KM server. This procedure is also documented in Microsoft Knowledge Base article 242276.

Installing the Legacy Policy Module

The Expolicyw2k.dll File

You must register the Exchange Server policy module (the Expolicyw2k.dll file) with the Certificate Server to configure Exchange Server advanced security to use a Certificate Server. This process is also documented in Knowledge Base article 192044.

Important: After you register this policy module and restart the Certificate Services, that Certificate Server will only be able to issue and verify certificates for Exchange Server. If you need a Certificate Server that can issue and verify certificates other than Exchange Server certificates, you need to install another Certificate Server to perform that function.

Note: You will not need the legacy policy module for Exchange 2000 Server KM server, because Exchange 2000 Server KM server will enable a single Certificate Server to serve multiple PKI services.

The Exchange Server policy module (Expolicy.dll) that is included with Exchange Server 5.5 does not support configurable (CDP) (Certificate Revocation List [CRL] Distribution Point) extensions in the KM server issued S/MIME certificates. For an updated Exchange Server KM server policy module for Windows 2000 Certificate Server that supports configurable CDP extensions, please contact Microsoft Product Support Services (PSS) and refer to Knowledge Base article 264862.

  1. The Expolicy.dll file is located on the Exchange Server 5.5 Service Pack 3 installation disk in the following folder:

    Server\Support\Kms\Expolicy\CPU_type

    Where CPU_type is the type of processor that the computer uses. To register this file:

    1. Copy the file to the following location on the CA:

      %systemroot%\System32

      For example, C:\Winnt\System32.

    2. At an MS-DOS command prompt on the Certificate Server, change to the %systemroot% folder, and then type the following:

      regsvr32 expolicy.dll

    Note: You cannot register the policy module from CD-ROM or a mapped drive. Use only the Expolicy.dll file that is located on the Exchange Server 5.5 Service Pack 3 installation disk. The Expolicy.dll file that is located on the Exchange Server 5.5 Service Pack 1 installation disk is not the most recent version. For a newer version of the Exchange KM policy module that supports CDP extensions, please refer to Knowledge Base article 264862.

  2. Select the legacy policy module on the Windows 2000 Server CA. On the Windows 2000 Server CA, in Control Panel, double-click Administrative Tools, and then start the Certification Authority snap-in. Right-click the server to open its properties, and then click the Policy Module tab. When the following page is displayed, click Select.

    Cc751428.win214(en-us,TechNet.10).gif

  3. When the Set Active Policy Module dialog box is displayed, click Legacy Policy Module, and then click OK.

    Note: If the newer policy module that is described in Knowledge Base article 264862 is installed, click Exchange 5.5 Windows 2000 policy module instead of Legacy Policy Module. If you click Exchange 5.5 Windows 2000 policy module, the administrator can configure CDP extensions for issued certificates, in a similar manner to the Enterprise and Stand-alone policy module.

    Cc751428.win215(en-us,TechNet.10).gif

  4. Click either OK or Apply. The Certificate Services automatically restart and begin to use the legacy policy module.

    If you are installing Certificate Services on a remote server, you must install Certificate Services Web Enrollment Support on the Exchange Server 5.5 KM server. For more information, see the "KM Server Installation" section of this white paper.

    Cc751428.win216(en-us,TechNet.10).gif

Scenarios

The Key Management server (KM server) that is included with Exchange Server 5.5 requires a Microsoft certification authority (CA) to issue X.509 V3 certificates. However, third-party root CAs can sign a Microsoft subordinate CA and exist in a public key infrastructure (PKI) hierarchy. This section describes some common scenarios and the key installation steps for each scenario.

Warning: After a KM server is attached to a Microsoft Certificate Server, it cannot be attached to a new or different CA. If it is attached to a new or different CA, the root of trust is invalidated, and all mail encrypted with certificates issued from this root will be inaccessible.

Note: The new policy module for Exchange Server 5.5 and Windows 2000 is Expolicyw2k.dll, which can only be used with a Windows 2000 CA.

Windows 2000 Server CA and KM Server on the Same Server with a Root Windows 2000 Server CA

  1. Ensure that the Expolicyw2k.dll file is registered on the server.

  2. Ensure that the Windows 2000 Server CA issues certificates that are valid for longer than two years.

Windows 2000 Server CA and KM Server on the Same Server with a Subordinate Windows 2000 Server CA

  1. Ensure that the Expolicyw2k.dll file is registered on the server.

  2. Install the root CA certificate in the local machine store on the server.

  3. Ensure that the subordinate Windows 2000 Server CA issues certificates that are valid for longer than two years.

  4. Ensure that the root Windows 2000 Server CA issues certificates that have an expiration date that is later than the expiration date for the subordinate CA.

Windows 2000 Server CA and KM Server on the Same Server with a Subordinate Windows 2000 Server CA Using a Third-Party Root CA

  1. Ensure that the Expolicyw2k.dll file is registered on the server.

  2. Install the root CA certificate in the local machine store on the server.

  3. Ensure that the root CA issuer and subject names are identical.

  4. Ensure that the subordinate Windows 2000 Server CA issues certificates that are valid for longer than two years.

  5. Ensure that the root CA issues certificates that have an expiration date that is later than the expiration date for the Windows 2000 Server subordinate CA.

Windows 2000 Server CA and KM Server on Separate Servers with a Root Windows 2000 Server CA in the Same Domain

  1. Ensure that the Expolicyw2k.dll file is registered on the Windows 2000 Server CA.

  2. Install Certificate Services Web Enrollment Support on the KM server.

  3. Verify that the Configuration Directory registry key is set properly. Refer to the "KM Server Cannot Find the Windows 2000 Server CA" section of this white paper.

  4. Ensure that the root Windows 2000 Server CA issues certificates that have an expiration date that is later than two years from the date the certificate is issued.

Windows 2000 Server CA and KM Server on Separate Servers with a Root Windows 2000 Server CA in a Different Domain

  1. Ensure that the involved domains are trusted in both directions.

  2. Ensure that the Expolicyw2k.dll file is registered on the Windows 2000 Server CA.

  3. Install Certificate Services Web Enrollment Support on the KM server.

  4. Install the fix that is described in Knowledge Base article 262288 on the KM server.

  5. Verify that the Configuration Directory registry key is set properly. Refer to the "KM Server Cannot Find the Windows 2000 Server CA" section of this white paper.

  6. Ensure that the root Windows 2000 Server CA issues certificates that have an expiration date that is later than two years from the date the certificate is issued.

  7. Add the KM server administrator accounts with "manage" permissions to the CA security settings.

Windows 2000 Server CA and KM Server on Separate Servers with a Subordinate Windows 2000 Server CA in the Same Domain

  1. Ensure that the Expolicyw2k.dll file is registered on the Windows 2000 Server CA.

  2. Install the root CA certificate in the local machine store on the KM server.

  3. Install Certificate Services Web Enrollment Support on the KM server.

  4. Verify that the Configuration Directory registry key is set properly. Refer to the "KM Server Cannot Find the Windows 2000 Server CA" section of this white paper.

  5. Ensure that the subordinate Windows 2000 Server CA issues certificates that are valid for longer than two years.

  6. Ensure that the root Windows 2000 Server CA issues certificates that have an expiration date that is later than the expiration date for the subordinate CA.

Windows 2000 Server CA and KM Server on Separate Servers with a Subordinate Windows 2000 Server CA in a Different Domain

  1. Ensure that the Expolicyw2k.dll file is registered on the Windows 2000 Server CA.

  2. Install the root CA certificate in the local machine store on the KM server.

  3. Install Certificate Services Web Enrollment Support on the KM server.

  4. Install the fix that is described in Knowledge Base article 262288 on the KM server

  5. Verify that the Configuration Directory registry key is set properly. Refer to the "KM Server Cannot Find the Windows 2000 Server CA" section of this white paper.

  6. Ensure that the subordinate Windows 2000 Server CA issues certificates that are valid for longer than two years.

  7. Ensure that the root Windows 2000 Server CA issues certificates that have an expiration date that is later than the expiration date for the subordinate CA.

  8. Add the KM server administrator accounts with "manage" permissions to the CA security settings.

Windows 2000 Server CA and KM Server on Separate Servers with a Subordinate Windows 2000 Server CA Using a Third-Party Root CA

  1. Ensure that the Expolicyw2k.dll file is registered on the Windows 2000 Server CA.

  2. Install the root CA certificate in the local machine store on the KM server.

  3. Install Certificate Services Web Enrollment Support on the KM server.

  4. Ensure that the subordinate Windows 2000 Server CA issues certificates that are valid for longer than two years.

  5. Ensure that the root CA issue certificates that have an expiration date that is later than the expiration date for the Windows 2000 Server subordinate CA.

Upgrading Windows NT 4.0 Certificate Server to Windows 2000 Server

You can easily upgrade a computer running Windows NT 4.0 Certificate Server (installed with the Windows NT 4.0 Option Pack) to Windows 2000 Server, if it is not in a hierarchy and is installed on an existing Exchange Server 5.5 KM server. If the computer running Windows NT 4.0 Certificate Server already issues certificates to Exchange Server KM server, the Certificate Server database is converted during the upgrade, and no further actions are required.

Important: Install Certificate Services Web Enrollment Support on the computer running Windows NT Server 4.0 before you upgrade to Windows 2000 Server.

Installing Trusted Root Certification Authorities

This section provides detailed steps to install trusted root certification authorities (CAs) to the local information store of a computer running Windows 2000 Server and Exchange Server 5.5 Key Management server (KM server). KM server requires that the root certificate of a third-party or foreign CA be included as a trusted root certification authority in the information store of the computer that KM server is installed on.

Note: All client computers must also have the root CA certificate installed in the information store or browser to use X.509 V3 certificates in a public key infrastructure (PKI) hierarchy. You can perform the following steps to deploy a root certificate to a client computer, or you can use Group Policy to deploy trusted root certification authorities to Windows 2000 Server computers in a Windows 2000 Server domain.

Installing a Root Certificate

  1. On the local computer on which KM server is installed, open the Certificates snap-in:

    1. Click the Start button, click Run, and then type mmc.exe to start Microsoft Management Console (MMC).

    2. Click Console, click Add/Remove Snap-in, and then click Add.

    3. When the Add Standalone Snap-in dialog box is displayed, click Certificates, click Add, and then click Close.

  2. Cc751428.win217(en-us,TechNet.10).gif

  3. The snap-in prompts you to provide a user account, service account, or computer account. Click Computer account, and then click Next.

    Cc751428.win218(en-us,TechNet.10).gif

  4. When the Select Computer dialog box is displayed, assuming that you are running the wizard on the local computer, click Local computer, and then click Finish.

    Cc751428.win219(en-us,TechNet.10).gif

  5. The snap-in dialog box is displayed again. Click Close, and then click OK. The snap-in is ready to import a root certificate.

  6. In the following window, in the left pane, click to expand the Certificates (Local Computer) folder, click to expand the Trusted Root Certification Authorities folder, right-click the Certificates folder, and then click All Tasks…Import to start the Certificate Import Wizard.

    Cc751428.win220(en-us,TechNet.10).gif

  7. When the Certificate Import Wizard dialog box is displayed, click Next.

    Cc751428.win221(en-us,TechNet.10).gif

  8. When the File to Import dialog box is displayed, click Browse to browse for the file name of the file that you want to import. The file type should be PKCS #12 (*.pfx) or PKCS #7 (*.p7b). Click Next.

    Cc751428.win222(en-us,TechNet.10).gif

  9. The file is imported and the following dialog box is displayed. To finish the Certificate Import Wizard, click Finish.

    Cc751428.win223(en-us,TechNet.10).gif

    A message is displayed that says, "The import was successful." Click OK.

KM Server Configuration

Exchange Server 5.5 Service Pack 3 must be installed, and Key Management server (KM server) must be installed and functional, to perform the procedures in this white paper. Perform the following steps in this section of this white paper to configure KM server to issue X.509 V3 certificates.

Installing Certificate Services Web Enrollment Support on KM Server

To install KM server, you must install the Windows 2000 Server Certification Authority (CA) Web Enrollment Support before you enable X.509 V3 certificates to be issued.

Note: You only need to install the Certificate Services Web Enrollment Support on the KM server if Certificate Server is not installed on the same computer that KM server is installed on.

To install Web Enrollment Support on the KM server:

  1. Click the Start button, point to Settings, and then click Control Panel.

  2. Double-click Add/Remove Programs. When an Add/Remove Programs dialog box similar to the following is displayed, click Configure Windows.

    Cc751428.win224(en-us,TechNet.10).gif

  3. When the Add or Remove Windows Components dialog box is displayed, click Components.

    Cc751428.win225(en-us,TechNet.10).gif

  4. When a dialog box similar to the following is displayed, click Next.

    Cc751428.win226(en-us,TechNet.10).gif

  5. When the Windows NT Components dialog box is displayed, click to select the Certificate Services check box, and then click Details.

    Note: If you want to use the Web components of the Certificate Services, you must also click to select the Internet Information Services (IIS) check box.

    Cc751428.win227(en-us,TechNet.10).gif

  6. Click to select the Certificate Services Web Enrollment Support check box. This allows your KM server to communicate with the certificate server. Click OK.

    Cc751428.win228(en-us,TechNet.10).gif

  7. When the Certificate Services Client Configuration dialog box is displayed, in the Computer name box, type the name of the remote Certificate Server, and then press the ENTER key. A list of available CAs is displayed. Click Next.

    Cc751428.win229(en-us,TechNet.10).gif

  8. When a dialog box that asks if you want to stop the Internet Information Services is displayed, click OK.

  9. After Internet Information Services stop and restart, the following dialog box is displayed. Click Finish.

    Cc751428.win230(en-us,TechNet.10).gif

Enabling X.509 V3 Certificates on the KM Server

After you install Certificate Services Web Enrollment Support on an Exchange Server 5.5 KM server, perform the following steps to enable X.509 V3 certificates in KM server:

Note: If the Exchange Server KM server resides in a Windows NT Server 4.0 domain, you must install a fix to enable communications with a Windows 2000 CA. Please refer to Knowledge Base article 262288 for additional information.

  1. Start the Microsoft Exchange Administrator program, and under the site that the KM server is in, click the Configuration container, and then double-click CA.

    Cc751428.win231(en-us,TechNet.10).gif

  2. KM server prompts you to provide the KM server password, which is "password" (without the quotation marks), if the password has not been changed after installation. When the following CA properties dialog box is displayed, click the Enrollment tab.

    Cc751428.win232(en-us,TechNet.10).gif

  3. On the Enrollment tab, click either Issue both V1 and V3 certificates or Issue X.509 V3 certificates only, as applicable.

    Warning: If your Exchange Server organization uses legacy clients (Outlook 97 or earlier), do not select Issue X.509 V3 certificates only. After you select Issue X. 509 V3 certificates only, those clients are not able to use Exchange Server advanced security, which includes decrypting previously encrypted e-mail.

    Cc751428.win233(en-us,TechNet.10).gif

  4. If you click Issue X.509 V3 certificates only, the following warning message is displayed. To continue, click OK.

    Cc751428.win234(en-us,TechNet.10).gif

  5. The Key Management Server Configuration dialog box lists all of the available Certificate Servers in the enterprise. Click the correct server, and then click OK.

    Cc751428.win235(en-us,TechNet.10).gif

    KM server is now ready to issue X.509 V3 certificates.

    Cc751428.win236(en-us,TechNet.10).gif

Troubleshooting

If you want to use 128-bit Secure/Multipurpose Internet Mail Extensions (S/MIME) security with Exchange Server 5.5 Key Management server (KM server), you must perform a number of key steps properly. This section provides troubleshooting steps that you can perform if you experience problems.

Installing KM Server and Windows 2000 CA in a Windows NT Server 4.0 Resource Domain

To operate the KM server and the Windows 2000 CA in an existing Windows NT Server 4.0 domain, you need to apply a fix to the KM server to enable Windows NT Server 4.0 domain support. Please see Knowledge Base article 262288 for information on how to obtain this fix and apply it to the KM server.

Note: Windows 2000 mixed mode domains do not require this fix.

KM Server Cannot Find the Windows 2000 Server CA

A common problem that you may experience if you enable X.509 V3 certificates with Exchange Server 5.5 KM server is a KM server that does not detect the Windows 2000 Server certification authority (CA). (For more information, see the "Enabling X.509 V3 Certificates on the KM Server" section of this white paper.) This problem may be caused by one of the following conditions:

  • Certificate Services Web Enrollment Support is not installed on the KM server.

  • The Expolicy.dll or Expolicyw2k.dll file is not registered on the Windows 2000 Server CA.

  • The Windows 2000 Server CA was incorrectly installed as an enterprise CA.

  • The Windows 2000 Server CA was installed by using an account that does not have directory service write access or Domain Administrator privileges.

Note: If the Windows 2000 Server CA was installed with a shared configuration folder on a separate server (for more information, see the "Certification Authority Setup" section of this white paper), KM server must maintain a mapped drive connection to that location.

Windows 2000 KM Server in Windows NT Server 4.0 Domain Does Not Find Web Client

When you install the CA and KM server in a Windows NT Server 4.0 domain, the Certificate Services Web Enrollment Support client must be able to find the shared CA folder on the CA. If you receive an error message (ID number c1031dab) that states that a certificate services Web client is not installed when the KM server enables a V3 certificate, ensure that the following registry key is present on the KM server:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \CertSvc \Configuration

The default settings are:

ConfigurationDirectory REG_SZ = \\CA_name\shared_folder

Where CA_name is the name of the Windows 2000 Server CA and shared_folder is the name of the CA configuration folder.

Restart the KM Server service after you edit this registry key.

Hierarchy Is Invalid Error Message

The following error message may be displayed:

The hierarchy of the MS Certificate Servers for your KM server is invalid. ID# c1031daf.

This error message may be caused by one of the following issues:

  • The certificate has an invalid expiration date. The certificates that are issued by the CA to the KM server for S/MIME users are only valid for one year. The certificates issued to the KM server for S/MIME users must be valid for at least two years. For more information about how to correct the expiration date, see the "Changing the Certificate Expiration Date" section of this white paper.

  • KM server links certificates by name only. For every certificate in the hierarchy, the subject-issuer pairs must match. This problem occurs almost exclusively when KM server issues a CA hierarchy with a third-party root CA. If the subject and issuer names are not identical on the root certificate, this error message is displayed when KM server attempts to validate the certificate chain.

Removing Advanced Security from a Mailbox Results in Error Message "The Operation Could Not Be Completed" c1031d92

This error message occurs if the KM server administrator account that is used to remove the advanced security from a mailbox has no "manage" permissions on the related CA server. Add the list of KM server administrators to the CA's Security tab, and grant the KM server administrators manage permissions.

KM Server Reports c1031d9f

This error message occurs if the CA server is running in a domain that is different from the domain of the KM server and the fix that is described in Knowledge Base article 262288 is not applied on the Windows 2000 server where Exchange Server 5.5 KM server is running. To resolve this problem, install the fix that is described in 262288.

The KM Server Certificate Is Immediately Revoked by the CA

The CA may immediately revoke the KM server certificate; this is not an error it is a normal procedure that the KM server performs in conjunction with the issuing CA to ensure that the KM server can build and validate the certificate chain. Client e-mail certificates are issued properly, even if the CA immediately revokes the KM server certificate.

KM Server Forklift Upgrade Process

If you want a Windows 2000 Server Certificate Server to issue X.509 V3 certificates to a computer running Windows 2000 Server and Exchange Server 5.5 Service Pack 3 KM server, you may need to upgrade from an existing Windows NT Server 4.0 environment. One method to migrate the Exchange Server 5.5 KM server database from Windows NT Server 4.0 to Windows 2000 Server is to perform a "forklift upgrade." To perform a forklift upgrade, you copy the KM server database and log files from the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM server, to a computer running Windows 2000 Server and Exchange Server 5.5 Service Pack 3 KM server. The computer running Windows 2000 Server and Exchange Server 5.5 Service Pack 3 KM server must have the same host name as the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM server. To perform a forklift upgrade:

  1. Set up Windows 2000 Server on the target computer. Make sure that you set up the computer running Windows 2000 Server by using the same host and machine name as the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM server. The server should be disconnected from the network at this point.

  2. Stop the Exchange Server services, such as the Information Store and the MTA, on the computer that is running Windows NT Server 4.0 and Exchange Server.

  3. Disconnect the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM server from the network.

    Copy the KM server database and log files from the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM server to a shared network drive. For example, the following files are considered KM server database and log files:

    • KM server database and log files

    • Information store database and log files

    • Directory database and log files

  4. Delete the Windows NT Server 4.0 KM server machine account from the domain.

  5. Connect the computer running Windows 2000 Server to the subnet in which it will reside.

  6. Set up Exchange Server 5.5 with KM server on the computer running Windows 2000 Server that you set up in step 1.

  7. Add the computer running Windows 2000 Server and Exchange Server 5.5 KM server to the same Exchange Server site that the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM sever was a member of.

  8. Set up Exchange Server 5.5 Service Pack 3 on the computer running Windows 2000 Server and Exchange Server 5.5 KM server.

  9. Shut down all of the Exchange Server services on the computer running Windows 2000 Server and Exchange Server 5.5 KM server.

    Note: Make sure that you record the KM server startup password before you shut down the Exchange Server services, because you need to use the same password on the computer that is running Windows 2000 Server.

  10. Remove the KM server database and log files from the computer running Windows 2000 Server and Exchange Server 5.5 KM server.

  11. Copy the KM server database and log files (originally from the computer running Windows NT Server 4.0 and Exchange Server 5.5 KM server) from the shared network drive that you copied them to in step 3, to the computer running Windows 2000 Server and Exchange Server 5.5 KM server.

  12. Start all of the Exchange Server services on the computer running Windows 2000 Server and Exchange Server 5.5 KM server.

After you complete these steps, the Exchange Server 5.5 KM server database is migrated from the computer running Windows NT Server 4.0 to the computer running Windows 2000 Server and Exchange Server 5.5 Service Pack 3 KM server.

Exchange 2000 Server

At the time that this white paper was written, Microsoft Exchange 2000 Server had not been released. This section contains information about the planned new features of Key Management server (KM server) in Exchange 2000 Server.

KM Server Key Export and Import

Exchange 2000 Server incorporates a key export and import feature that enhances the organizational flexibility of sites that use advanced security, by allowing them to migrate users' key history to a new location. After the key history is migrated to the new location, those users can access their old keys, and therefore can read e-mail that was encrypted in the old location.

KM server archives and stores keys so that they can be recovered at a later time. This allows users to recover valuable encrypted e-mail even if they lose their keys. KM server keeps these key histories in a database and maps them to a specific mailbox by Distinguished Name (DN). Currently, if a user moves to a new organization or site, this key history is lost. To remedy this situation, the user must decrypt all of his or her e-mail with the Sectool tool (included with the Microsoft Exchange Server Resource Kit), re-enroll after the move to the new organization or site, and then re-encrypt the e-mail with a new key. In Exchange 2000 Server, You can bulk export keys to a file that can be imported by another KM server. After you import the file, the user can access the old keys and decrypt the old e-mail. This feature vastly improves organizational flexibility for companies that have implemented advanced security.

Backing Up KM Server and Certificate Server

The KM server database in Exchange Server 5.5 is not included in the Exchange Server panel in Windows NT Backup. To back up the KM server database, an administrator has to stop the service and perform the backup manually. In Exchange 2000 Server, the KM server database has been added to the Exchange Server panel of Windows NT Backup to allow automatic backup without service interruption. The ESE97 application programming interface (API) and Jet database engine provide the ability to back up online databases.

Important: Back up the Certificate Server and KM server at the same time, because both the Certificate Server and KM server maintain the revocation status of the certificates. When a certificate is revoked, it is marked as revoked in the KM server and the Certificate Server. For example, if a KM server backup is performed before a revocation, a Certificate Server backup is performed after the revocation. Both are then restored, and the certificate is marked revoked in the KM server, but not in the Certificate Server. New Certification Revocation Lists (CRLs) published by the Certificate Server would not contain the certificate, and there would be no way to revoke them again in KM server.

Multipurpose Certificate Servers

The removal of the policy module (the Expolicy.dll file) from Exchange 2000 Server allows a Certificate Server to issue certificates to KM server users, as well as other certificates for other purposes, by using the enterprise version of Certificate Server templates. The templates define the extensions that appear in the certificate. KM server users need two templates, which are included with Windows 2000 Server. Public key infrastructure (PKI) hierarchies are also fully supported with Windows 2000 Server.

Starting the Key Management Service

There are two procedures you must perform to start the Key Management Service. Perform the first procedure after you install Windows 2000 Server but before you install Exchange 2000 Server, and perform the second procedure after you install Exchange 2000 Server and the Key Management Service.

After you install Windows 2000 Server but before you install Exchange 2000 Server, install Certificate Services. When you install Exchange 2000 Server, be sure that you select Microsoft Exchange Key Management Services in the Component Selection window of the Installation Wizard.

After you install Exchange 2000 Server, you must perform the following steps to start the Key Management Service:

  1. Start the Active Directory Sites and Services snap-in, click View, and then click Show Services Node.

  2. Click Services, point to Public Key Services, and then click Certificate Templates.

  3. In the MachineEnrollmentAgent template, click Properties.

  4. Click the Security tab, add the Authenticated Users group, and then assign it Read permissions.

  5. Add Enroll permission to the Exchange KMServers group.

  6. In the ExchangeUser template, click Properties.

  7. Click the Security tab, add the Exchange KMServers group, and then assign it Enroll permissions.

  8. In the ExchangeUserSignature template, click Properties.

  9. Click the Security tab, add the Exchange KMServers group, and then assign it Enroll permissions.

Note: Do not install more than one KM server for each administrative group. Although Exchange 2000 Server allows you to install multiple KM servers in a single administrative group, Microsoft recommends that you install only one KM server for each administrative group.

Additional References

Knowledge Base Articles

192044 XADM: Setting Up X509v3 Certificates on Exchange 5.5 SP1 KMS with Local Certificate Server

242466 XADM: Error Message: The Key Management Server Is Unable to Operate

247814 XADM: Key Management Server Cannot Grant V3 Certificates to Users with Long Distinguished Names

218802 XADM: Can't Enroll Using X.509 V3 Certificates

216653 XADM: Certificate Server is Exclusive to Exchange Advanced Security

197965 XGEN: FAQs on High and Low Encryption in Exchange Server

216922 Certificate Server Does Not Create Backups of Installed Keys

264862 XADM: No Certificate Revocation List Distribution Points Extension in X.509 V3 Certificate

262288 Exchange 5.5 KMS Does Not Work with Windows 2000 Certificate Server in a Windows NT 4.0 Domain

242276 XADM: KM Server with Subordinate CA Displays Error Message: The Hierarchy of the MS Certificate Servers for Your KM Server Is Invalid c1031daf

Resources

The latest security information from Microsoft is available at the following Web site:

https://www.microsoft.com/security

Information for software developers is available through the Microsoft Developer Network (MSDN™) at the following Web site:

https://msdn.microsoft.com

Secure/Multipurpose Internet Mail Extensions (S/MIME) Internet standards are available at the following Web site:

https://www.imc.org/ietf-smime

Documents

U.S. Government

The National Institute of Standards and Technologies (NIST), in conjunction with the Department of Defense (DOD) and the National Security Agency (NSA), has published information on U.S. Government federal public key infrastructure (PKI) efforts. Published documents are available at the following Web site:

https://csrc.nist.gov/pki

For More Information

The latest information about the Windows 2000 Server operating system is available at the following Web site:

https://www.microsoft.com/windows2000/default.asp