Deploying a Public Key Infrastructure for MS Exchange 5.5
Step-by-Step Guide
Abstract
This paper covers the procedures for successfully deploying a public key infrastructure (PKI) for Microsoft Exchange 5.5, using Certificate Server, in a Microsoft® Windows NT® 4.0 Advanced Server-based network. It also covers the upgrade process to Microsoft Windows® 2000, which is based on experience obtained from a Windows 2000-based pilot project performed for a Fortune 500 customer. Creating a PKI for this customer offered security support for digitally signed and encrypted messages and built a solid infrastructure for future security needs.
On This Page
Introduction
Working closely with an enterprise customer, our team duplicated the customer's hardware and Microsoft Windows NT® 4.0 domain environment in a Redmond lab and added the public key infrastructure (PKI) needed to implement digitally signed and encrypted e-mail messages in Microsoft® Exchange 5.5 (Service Pack 3). We then upgraded the environment to Microsoft Windows® 2000 Server. This process was documented to serve as a reference installation for customers.
The advanced security methods of encrypted and digitally signed messages were made available using Key Management Server in Exchange 5.5. When a message is encrypted, only the assigned recipient of the message can decrypt it, which prevents unauthorized individuals from obtaining the contents of the message. Digitally signed messages, on the other hand, guarantee the identity of the sender. The digital signature on the message cannot be forged.
Key Management Server stores and manages the security database in a network running Microsoft Exchange Server. Key Management Server requires PKI to issue certificates that are used to implement advanced security. Certificate Server in Windows NT® 4.0 was used to implement the PKI.
The following sections examine the customer requirements, describe building the PKI using Key Management Server and Certificate Server technologies, and then provide an overview of the solution deployed.
Then, you will find step-by-step procedures for installing a Certificate Server hierarchy, installing and configuring Key Management Server, enabling a user for advanced security, and, finally, upgrading the PKI to Windows 2000.
Customer Environment and PKI Requirements
The customer we worked with had a number of Windows NT® 4.0-based domains tied to each other with two-way trust relationships. A number of Exchange 5.5 sites were installed in these domains. The Exchange 5.5 sites were tied together for directory replication in a multi-level hub and spoke arrangement. The X.400 connector was used for directory replication. All users on the domains had Exchange 5.5 server accounts and were Microsoft Outlook® 2000-based mail clients. Outlook 98 mail clients can also be used.
The customer wanted to deploy public key infrastructure (PKI) to provide use of secure e-mail with X.509 v3 certificates using Exchange Key Management Server. The goal evolved to building an extensible infrastructure to accommodate future PKI needs and usage, such as non-Exchange S/MIME, Web PKI usage, extranet usage, and so on. Another goal was to design the PKI for an easy upgrade to Windows 2000 PKI.
Building a PKI and Implementing Secure E-Mail
Windows NT 4.0 Certificate Server provides the services to issue certificates for any requesting principal. Certificate Server hierarchies are used to build an extensible and secure PKI.
Exchange Key Management Server uses Windows NT 4.0 Certificate Server to enable users for secure e-mail.
Using Windows NT 4.0 Certificate Server
Certificate Server builds an extensible, secure PKI with rooted certification authority (CA) hierarchies. This consists of a hierarchy of CAs, with each CA issuing certificates to subordinate CAs. The chain terminates when a CA issues a certificate to an end entity.
Certification authority (CA) hierarchies have a root. The root CA certificates are self-signed. The root CA certificates are the most costly to distribute, so a small number of root certificates with a long lifetime offers the best solution. Root CAs are trusted unconditionally, so they need to be most secure. Therefore, root CAs are kept offline since online CAs are vulnerable to attack.
There could be a number of levels of subordinate CAs. The last one in the chain is known as the issuing CA. This issues certificates to end entities.
Issuing CAs are the most frequently used and need to be online. They sign a lot of end entities, thus exposing themselves to cryptographic attack. It is therefore necessary for these CAs to frequently replace their signing keys. The lifetime of the certificates used by these CAs should also be less than the root CA.
Hierarchies allow the root CA to be the most secure because the servers they run on are offline, and the root CA is used to sign only a small number of certificates. They allow the CAs at the bottom of the hierarchy to be online and available to process new certificates from a wide range of clients and frequently publish up-to-date revocation status information. CAs higher up in the hierarchy need to process new certificate requests and publish revocation status information at a lesser interval, and can be taken offline to protect them from cryptographic attack.
Hierarchies also allow an extensible architecture where different branches of subordinate and issuing CAs can take care of different PKI needs. The architecture is very extensible and it is easy to add another branch for a different PKI should the need arise in the future.
Certification authority (CA) hierarchies are frequently built in three tiers, made up of the root CA, the intermediate or policy CA, and the issuing CA.
Because there may be a number of issuing CAs that need to register with the root CA, using a policy CA in the middle tier makes sense for the purpose of making the root CA secure. The policy CA can make the routine subordination decisions. This enhances the security of the root CA.
Also, the certificate revocation lists (CRLs) at the root CA in this model need to be published very infrequently—maybe once in three months—whereas the policy CA needs to publish more frequently—maybe once every week. Finally, the issuing CA may need to publish CRLs every day.
Using Exchange Key Management Server to Secure E-Mail
Advanced security in the Exchange 5.5 environment provides users with encryption of messages as well as the facility to digitally sign e-mail messages.
Key Management Server is used along with an issuing CA to enable users to participate in advanced security using public key technology. An e-mail user enrolls with Key Management Server for advanced security. The Key Management server uses an issuing CA to issue an X.509 v3 certificate to the client. Once enrolled, a user can send or receive signed e-mail, receive encrypted e-mail, and send encrypted e-mail to enrolled recipients.
Solution Deployed
We built a separate domain to contain the computers running Certificate Server so that we could independently upgrade this domain and the PKI to Windows 2000.
We decided to deploy a tri-level Certificate Server hierarchy to handle the customer's PKI needs. The root CA, policy CA, and the issuing CA form the tri-level hierarchy. The reasons for deploying a Certificate hierarchy are given in the section above.
The root server should be the most secure. It is the root of the trust hierarchy. Once the policy CA is installed and enrolls itself in the root server, the root server can be taken offline.
The policy CA makes routine trust decisions, such as what other root servers to trust. Once the issuing CA is installed the policy CA can also be taken offline to enhance security of the certificate hierarchy.
Only the issuing CA needs to be online. Exchange Key Management Server uses the issuing CA to issue certificates to enroll and issue certificates to users.
Note: Although the same validity time was used for each of the three CAs in the pilot project, in real practice, different times should be used for the root CA, the policy CA, and the issuing CA. The root CA can have a validity of five years, the policy CA can have a validity of three years, and the issuing CA can have a validity of two years. Key Management Server requires a two-year minimum.
Once we deployed a three-tier hierarchy, we installed and configured Exchange Key Management Server to use Certificate Server, and then enabled secure e-mail for a few test users. Finally, we upgraded the new domain and the PKI to Windows® 2000. Once the certificate servers were running Windows 2000, we reinstalled them as enterprise certificate servers because only the enterprise CA is Active Directory™ service-aware, which is an Exchange 2000 requirement. Also, templates required for Exchange 2000 were installed in the enterprise CA. This work was done to ensure a smooth future migration to Exchange 2000.
The setup is shown in the following figure and the steps are documented in the following sections.
Installing a Certificate Hierarchy
To establish a certificate hierarchy, you will need to first install the root CA on a computer running Windows NT® 4.0 Advanced Server, then install the policy CA on another computer running Windows NT 4.0 Advanced Server, and, finally, install the issuing CA on a third computer running Windows NT 4.0 Advanced Server.
Before you begin this procedure you must have the following programs installed on each computer running Windows NT 4.0 Advanced Server:
| • | Microsoft Internet Explorer 5.0 |
| • | Windows NT 4.0 Option Pack |
| • | Windows NT 4.0 Service Pack 6 |
To establish a certificate hierarchy as described earlier, complete the following procedure for each CA you want to install in the following order:
| • | Root CA |
| • | Policy CA |
| • | Issuing CA |
To install the root CA, policy CA, and issuing CA on computers running Windows NT 4.0 Advanced Server
1. | Ensure that the time on the computer is accurate since certificates have time stamps. | ||||||||||||||||||||||||||||||
2. | Click Start, point to Programs, point to Windows NT 4.0 Option Pack, and then click Windows NT 4.0 Option Pack Setup. The Setup wizard launches: click Next in the first wizard window. | ||||||||||||||||||||||||||||||
3. | Click Add/Remove, and then click Next. | ||||||||||||||||||||||||||||||
4. | Under Components, click the Certificate Server check box, and then click Next. | ||||||||||||||||||||||||||||||
5. | Under Configuration Data Storage Location, select a shared folder location, click the Show Advanced Configuration check box, and then click Next. On the cryptographic services provider wizard page, under CSP, select Microsoft Base Cryptographic Provider; under Key Length, select 1024; under Hash, select SHA-1. Then, click the Make this Certificate Server the default check box, and then do one of the following:
| ||||||||||||||||||||||||||||||
6. | Type the identifying information for the CA you are installing (root, policy, or issuing), and then click Next. | ||||||||||||||||||||||||||||||
7. | Select Browse the CD or LAN to locate this file, click Browse to locate the missing Certificate Server installation files or type the path, and then click OK to start and finish the installation. By default, the files are located on the Windows NT 4.0 Service Pack 6 CD in the Valueadd\Certsrv\i386 directory. | ||||||||||||||||||||||||||||||
8. | Change the Certificate Server validity time for the CA you are installing (root, policy, or issuing) from the default period of one year. You can do this by running Regedit.exe, and then changing the registry value ValidityPeriodUnits in the key HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Certsvc \Configuration\Name_of_CA Exchange Key Management Server needs a validity of two years or more. | ||||||||||||||||||||||||||||||
9. | Set up a share on the shared folder you specified in step 5. For example, if c:\certsrv is the shared folder, type: Net share certsrv=c:\certsrv You need to restrict the share to the domain administrators' group and mark it as read-only. | ||||||||||||||||||||||||||||||
10. | Reinstall Windows NT Service Pack 6. Do one of the following:
|
Install the subordinate issuing CA certificate by changing to the shared folder as the current folder and running the command certhier. Then start the Issuing CA using the net start certsvr command.
Installing and Configuring Exchange Key Management Server
This involves first installing the Exchange policy module on the issuing CA. Then, the Key Management Server can be installed and configured to use the issuing CA to issue X.509 v3 certificates. We chose to install Exchange Key Management Server on the issuing CA itself; however, a separate server can host Exchange Key Management Server. Once the Key Management Server is installed, mailboxes in the Exchange organization can be enabled for advanced security.
To install the Exchange policy module on the issuing Key Management Server CA
1. | Copy the Exchange policy module expolicy.dll from the Exchange 5.5 Service Pack 3 to the System32 directory on the issuing CA server. |
2. | Register the Exchange policy module by running regsvr32 expolicy.dll. |
3. | Stop the Certificate Server on the issuing CA using the net stop certsvc command. |
4. | Restart the Certificate Server on the issuing CA using the net start certsvc command. |
To install Exchange Key Management Server on the issuing CA
1. | Install Exchange 5.5 and Exchange 5.5 Service Pack 3. |
2. | Build a separate site and link it to a bridgehead site in the existing Exchange infrastructure using an X.400 connector. |
3. | Reinstall the Exchange 5.5 Setup, and then click Add/Remove. |
4. | Under Options, select the Microsoft Exchange Server check box, and then click Change Option. |
5. | Under Options, select the Key Management Server check box, click OK, and then click Continue. |
6. | In the Site Services Account dialog box, type the services account name and password, and then click OK. |
7. | The Key Management Server installation provides you with a temporary password (called the Key Management Server Startup Password) to use while starting up Key Management Server. Choose to either display the password once, which the administrator will need to write down, or write the password to a floppy disk, and then click OK. |
8. | Exchange 5.5 installation will copy the needed files. |
9. | Reinstall Exchange 5.5 Service Pack 3, and then restart the computer. |
10. | Click Start, point to Settings, click Control Panel, and then double-click Services. |
11. | Under Service, click Microsoft Exchange Key Management Server. Under Startup Parameters, type the Key Management Server Startup Password that you were provided with in step 7, and then click Start to start Exchange Key Management Server. |
To configure Exchange Key Management Server to use the issuing CA for its X.509.3 certificates
1. | Click Start, point to Programs, point to Microsoft Exchange, and then click Microsoft Exchange Administrator. |
2. | On the Key Management Server Exchange Server site node, click Configuration, and in the details pane, double-click CA to open the CA Properties dialog box. |
3. | In the Key Management Server Password dialog box, in KM Server password, type a password (the temporary default password), select the Remember this password for up to 5 minutes check box, and then click OK to open the CA Properties dialog box. |
4. | On the Administrator tab, select Change My KM Server Password. |
5. | In Current, type a password (the temporary default password) and then type a new personal password, and verify it. |
6. | On the Enrollment tab, select the Allow e-mail to be sent to the user check box, and then click Issue X.509 V3 certificates only. |
7. | At the warning message, click OK. |
8. | In the Key Management Server Configuration dialog box, select the issuing CA as the Certificate Server that the Key Management Server can use to issue certificates, click OK, and then click OK to close the CA Properties dialog box. |
9. | Next, add the Tagged-X.509-Cert attribute for all users in this site. On the Key Management Server Exchange Server site node, click Configuration, and in the details pane, double-click DS Site Configuration to open the DS Site Configuration Properties dialog box. |
10. | On the Attributes tab, under Configure, select Anonymous requests. Under Show attributes for, select All mail recipients, and select the Tagged-X509-Cert attribute check box. Repeat this for Authenticated requests and inter-site replication, and then click OK. |
To enable a user for advanced security
1. | Create a mailbox in Microsoft Exchange Administrator, attach it to one of the users on the domain or create a new user, and then double-click the user's mailbox to see its properties. |
2. | On the Security tab, click Enable Advanced Security, and then click Send Enrollment Message. In the Microsoft Exchange Administrator dialog box that displays the advanced security temporary key, click OK. Then, click OK again. |
Note: The enrollment message is sent to the specified user and contains the advanced security temporary key and instructions on how to set up advanced security in Outlook 98 or Outlook 2000.
To set up advanced security in Outlook® 98 or Outlook 2000
1. | On the Tools menu, click Options. |
2. | On the Security tab, click Get a Digital ID. |
3. | Click Set up Security for me on the Exchange Server, and then click OK. |
4. | In the Setup Advanced Security dialog box, in Digital ID Name, type a name to use for the Digital ID. In the Token text box, type the advanced security temporary key, and then click OK. |
5. | In the Microsoft Outlook Security Password dialog box, in the Password text box, type a password to protect your Digital ID, confirm it, and then click OK. Click OK again. This password will be needed whenever you receive encrypted e-mail. |
Notes
Users will receive the advanced security temporary key in e-mail after the administrator enables the user for advanced security.
Once you complete this procedure, you will receive a reply from system security. Upon clicking the message, you will be prompted for the password chosen as the Digital ID. Type the password, select the Remember password for 30 minutes check box, and then click OK. Click Yes to add the user certificate to the Root Store in Key Management Server Certificate Authority. You can now send signed and encrypted messages.
To send signed and/or encrypted e-mail messages in Outlook 98 or Outlook 2000
1. | In an open e-mail message, on the File menu, click Properties. |
2. | On the Security tab, select the Add digital signature to message check box to sign the message. To encrypt the message, select the Encrypt message contents and attachments check box. |
Upgrading the Public Key Infrastructure to Windows 2000
Now that the public key infrastructure (PKI) iss set up, the upgrade to Windows® 2000 takes place.
After upgrading the domain controller of the domain in which the certificate servers are set up with Windows® 2000 and Active Directory™, Windows NT® 4.0 certificate servers are migrated to Windows 2000.
The certificate server databases needed to be converted to the new database format used in Windows 2000.
To do this, on all the certificate servers (root CA, policy CA, and issuing Key Management Server CA) execute the following commands to stop the certificate server, convert the database, and then start it again.
| • | net stop certsvc |
| • | certutil –ConvertMDB |
| • | net start certsvc |
To prepare the certificate servers for use by Exchange 2000, they need to be upgraded to enterprise CAs from the stand-alone CAs that existed in Windows NT 4.0.
After upgrading the root CA, policy CA, and issuing CA to enterprise CA computers, templates need to be added to the issuing CA so that Exchange 2000 Key Management Server can use the Certificate Server in the future.
To convert the Certificate servers from stand-alone CAs to enterprise CAs
Follow this procedure for each of the three CAs starting with the root CA, then the policy CA, and lastly the issuing CA.
1. | Click Start, point to Settings, click Control Panel, double-click Add/Remove Programs, and then click Add/Remove Windows Components to remove Certificate Services. | ||||
2. | Under Components, clear the Certificate Services check box, click Next, and then click Finish. The Windows Component Wizard will stop Certificate Services and remove it. However, the certificate services database is not removed. | ||||
3. | Click Start, point to Settings, click Control Panel, double-click Add/Remove Programs, and then click Add/Remove Windows Components to reinstall certificate services. | ||||
4. | Under Components, select the Certificate Services check box, click Next, and then click Finish. At the warning, click Yes, and then click Next to start the installation. On the Certification Authority Type wizard page, under Certification Authority types, do one of the following:
| ||||
5. | Select the Advanced options check box, and then click Next: | ||||
6. | On the Public and Private Key Pair wizard page, under CSP, click Microsoft Base Cryptographic Provider, under Hash algorithm, click SHA-1, select the Use existing keys check box and use the existing key for the old certificate server installation on the computer. Then, select the Use the associated certificate check box, and click Next. | ||||
7. | On the CA Identifying Information wizard page, type a description for the CA, and then click Next. | ||||
8. | On the Data Storage Location wizard page, select to store configuration information in the same shared folder that was set earlier, and select to preserve the existing certificate database. Then, click Next to start the installation. | ||||
9. | In the Files Needed dialog box, under Copy files from, type a path to the binaries that are needed to complete the installation, and then click OK to complete the installation. |
To add templates to the issuing CA server
1. | Click Start, point to Programs, point to Administrative Tools, and then click Certificate Authority. |
2. | In the console tree, expand the node for the issuing Key Management Server CA, right-click Policy Settings, and then click Choose New Certificate To Issue. |
3. | In the Select Certificate Template dialog box, click Enrollment Agent (Computer), Exchange User, and Exchange Signature Only policy templates, and then click OK. The chosen templates are installed and can be used by Exchange 2000. |
The issuing CA can now be used by an Exchange 2000 installation. When Exchange 2000 is released the upgrade process to Exchange 2000 will upgrade the Key Management Server installation and use this Certificate server and the templates installed.
We went on further and upgraded the Exchange 5.5 installation to Exchange 2000 to verify the correctness of the certificate server upgrade. However, since Exchange 2000 is still in beta form, the upgrade process may vary by the time the product is released and is not documented in this paper.
Glossary
certification authority (CA)
A certification authority issues certificates to requesting entities. A requesting entity can be another certification authority or an end entity.
certificate
A certificate is a digitally signed statement containing a public key and the name(s) of the subject.
certificate revocation list (CRL)
A list of certificates that have been revoked, typically either because the owner's private key has been compromised or because the holder is no longer associated with the issuer.
cryptography
Cryptography is the science of transforming data. Cryptographic algorithms mathematically combine input data and a cryptographic key to transform the data.
Key Management Server
The Exchange Server component that enables advanced security for sending and receiving encrypted and/or signed e-mail messages. Key Management Server provides key management and key recovery functionality.
public key cryptography
Public Key Cryptography systems use two keys: a public key, which is designed to be shared, and a private key, which must be closely held. These keys are complementary: if you encrypt something with the public key, it can only be decrypted with the corresponding private key, and vice versa.
public key infrastructure (PKI)
A PKI is the set of operating system and application services that make it easy and convenient to use public key cryptography.
S/MIME
An Internet Engineering Task Force (IETF) standard protocol that enables secure e-mail messaging.
X.509
This is industry-standard protocol for PKI certificates.
Summary
We successfully set up a PKI for implementing secure e-mail. The PKI was set up such that it would maximize the security of the certificate servers' installation and would allow room for expansion for other users of PKI. The process was documented so that customers can have a reference installation to start with, and then customize it for their needs. Attention was paid to the installation for easy future upgrades to Exchange 2000.
For More Information
For the latest information on Windows 2000 Server, check out our Web site at http://www.microsoft.com/windows2000.