Installing Certificate Services | Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)

Installing Windows 2000 Server or Windows Server 2003 Certificate Services takes only a couple of minutes and requires just a few configuration settings. Unfortunately, the impact of these decisions is critical, and some settings cannot be changed without removing the entire CA infrastructure. For these reasons, you should always pilot your CA deployment in a lab environment prior to the actual production deployment. Moreover, because the settings you configure have enterprise policy implications, you should spend time working with other department leaders and IT management to define the policies and procedures for PKI.

Microsoft recommends that you define your certificate policies and CA practices on paper before you configure the test server in the lab. These definitions and requirements determine how the PKI environment is configured. We have already covered the basic information such as placement, performance, and overall administrative strategy. Now we have to consider the procedural aspects. It is highly recommended that the configuration be installed and tested in a lab environment before deploying in production. Here is a checklist of things that should be considered and documented before you begin testing.

First, you must settle on global settings and standards for your PKI; these standards govern the naming, trust, and maintenance requirements for your infrastructure. You should do the following:

Set naming standards for the CA naming components : the CA name itself, the organization and organizational unit (OU) names, and the administrator e-mail address for each CA. Usually, these names mirror the names you re already using in Active Directory. Generally, it is not recommended that the security or directory infrastructure be revealed through CA names .
Choose the key length, cryptographic algorithms, and CSP that you will use for your CAs.
Determine trust requirements, then design a hierarchy to implement them. In addition, decide who will have the ability to issue, revoke, and manage certificates and who can manipulate the contents of the CTL.
Identify which external CAs you re going to trust, then ensure that you understand what their policies and procedures are so you can see if they re trustworthy enough to put on your CTL or cross- certify with constraints using Windows Server 2003.
Explore your CA maintenance and recovery requirements. Make sure that you have an adequate backup and recovery plan for your CA data. Build a procedure for mass recoveries , re-enrollments, and rekeyings ”in other words, if your CA certificate is ever compromised, you should already have a plan in place to deal with it. Identify who will manage each CA and the roles and permissions for each administrator or certificate manager.

Next , identify the CAs (including their physical locations ”see Chapter 5, Physical and Operational Security ) and their roles. This process requires you to do the following:

Decide how many CAs you ll have; where they will be physically located; whether they will be enterprise or stand-alone; whether they ll act as issuing, intermediate, or root CAs; and if they will be maintained online or offline.
For each CA, determine its issuance policy (automatic or manual) and what types of certificates it can issue.
Define the security procedures required for each CA. This should include physical security, administrative access control, and any specific procedures for individual CAs.

Third, define the enrollment and renewal requirements for each of your CAs by doing the following:

Decide whether your CAs will issue certificates automatically or only after manual approval. Define issuance and authentication requirements, if applicable .
For each certificate template, set a default lifetime for the certificate validity.
For all CAs, decide ahead of time when you will renew certificates and when you will rekey them.

Finally, design revocation procedures and policies that make sense for your environment. Ask yourself the following questions:

Under what conditions will you revoke a certificate? Make a procedure and requirements list for administrative personnel to follow.
What procedures will be used for revocation? Who can notify the CA administrator that a particular certificate needs to be revoked ? Who is actually authorized to do the revocation?
How often will you publish CRLs, and where will they be hosted?

Now that you have designed and planned your operational environment, you can begin the installation process. If you are planning to install a stand-alone root, it is advisable to start with a machine that is not joined to a domain and has never been connected to a network.

Caution

Once you install Certificate Services on a computer, you cannot change its computer name or domain and workgroup membership.

Because Certificate Services is a Windows Server family component, installation begins by selecting Add/Remove Windows Components from the Add/Remove Programs Control Panel tool. The first page you see during the Certificate Services installation prompts you to choose the type of CA you wish to install: enterprise or stand-alone, subordinate or root. Select the Use Custom Settings check box to configure the additional settings for the CA, such as the key length and CSP. Based on your requirements, you might need to change the default CSP to an alternate provider. For most cases, the Microsoft Enhanced Cryptographic Provider 1.0 is appropriate, although you might have a specific requirement for a different CSP. The CSPs that ship with Windows 2000 Server and Windows Server 2003 are as follows :

The Gemplus GemSAFE, Infineon, and Schlumberger CSPs support smart cards from their respective vendors ; you ll only need them if you re using that particular type of smart card. These CSPs require that the Allow Interaction With The Desktop check box be enabled to allow for administrator PIN entry during CA operations.
The Microsoft Base Cryptographic Provider implements RSA with up to 1024-bit keys on Windows Server 2003 and 40-bit RC2/RC4.
The Microsoft Base DSS Cryptographic Provider implements support for the DSA (see Chapter 2) and Digital Signal Standard (DSS) algorithms.
The Microsoft Enhanced Cryptographic Provider and Microsoft Strong Cryptographic Provider implement the same algorithms as the Base CSP, but it lengthens the available streaming key lengths to128-bit such as RC2/RC4 as well as RSA maximum key sizes of 16,384. It also adds support for single and triple Data Encryption Standard (DES).

The next choice you make in the installation is the hash algorithm you wish to use. The choices will be different based on the CSP that is selected. The default and recommended hash algorithm is Secure Hash Algorithm 1 (SHA-1), but you might need to modify this based on your identified application or interoperability requirements.

The next page you see during the installation process is the CA Identifying Information page for the CA, shown in Figure 12-4. It is important that you follow your naming standards document to clearly identify your company and the name and purpose of the CA. If you specified a longer key length for your root CA certificate, you can change the information in the Valid For text box to assign a longer lifetime. For a root CA that will be the basis for a long life hierarchy, it is strongly recommended that you choose a lifetime of more than 5 years .

Figure 12-4: The information you provide here will be signed into the CA certificate, so don t misspell anything.

Next, you need to choose locations for the database and log files. If installing Windows 2000 Server only, after the installation, you should modify the access control lists (ACLs) for these folders to better protect the database against malicious users. After you have made these choices, the setup process installs the appropriate software and establishes the CA.

Note	If you need to install multiple CAs, install the root first, then before taking it offline, install the subordinate CAs. Just be sure to choose the appropriate CA type for the subordinate CAs.

Using Web Enrollment

In Windows 2000 Server, by default, the newly installed CA supports Web enrollment. A new Internet Information Services (IIS) virtual directory named CertSrv is added to the server. Users can then connect to http://CAServerName/certsrv/ to perform common certificate management tasks such as requesting a certificate, as shown in Figure 12-5, checking on the status of a request, or downloading the CA s certificate or a copy of the most recent CRL. Windows Server 2003 requires that IIS and Web enrollment be explicitly added.

Figure 12-5: Users can request certificates themselves by using the Web enrollment application.

If the CA is configured as an enterprise CA, you can choose to allow the CA to automatically process these requests by using one of the predefined certificate template types. Otherwise, the administrator for the CA needs to specifically approve the request using the MMC Certification Authority console. To do this, the administrator can open the console (it s in Start Programs Administrative Tools Certification Authority), view pending requests, and approve or deny them, as shown in Figure 12-6.

Figure 12-6: Using the Certification Authority console, the administrator can select the Pending Requests option from the left pane, and right-click a specific request to issue or deny.

The Web pages hosting the enrollment station or the console running the smart card enrollment station does not necessarily have to be the certificate server. In many cases, it is better to configure a separate server or workstation for this purpose. Moreover, if you are planning to use smart cards or other hardware devices that need programming, the certificate and enrollment tools should be installed on a machine that has the appropriate smart card readers or writers or other required hardware to enroll, manage, and configure the PKI environment. This station should be used by administrators to perform various PKI tasks; it is not intended to be directly accessed by the user community.

Using the Exchange 2000 KMS

KMS was once required if you wanted to encrypt Outlook mail, but that is no longer the case. At this point, you have already configured all that is necessary to provide certificates and PKI functionality to your user population. You d normally use the Exchange 2000 KMS if you have an existing Exchange 2000 organization and want to roll out advanced security before, and during, your upgrade to Exchange Server 2003. For that reason, I m going to discuss the process of setting up and configuring the KMS here, but you can skip this section if you re not using Exchange 2000 for security.

Configuring KMS

Assuming that Exchange 2000 Server is already installed and working, installing KMS is easy. First, you ll need to add a couple of Certificate Services template policies, then run the Exchange 2000 Setup media to install KMS.

First comes the template installation:

Launch the Certification Authority MMC for the CA that will issue certificates on behalf of KMS to the end users.
Expand the branches underneath the issuing CA server name, and right- click the Certificate Templates folder if running Windows Server 2003 in the left pane. In Windows 2000 Server, this will be the Policy Settings folder. You ll only see this object on enterprise CAs, so if you don t see it, that s a good sign that you need to install an enterprise CA before attempting to use the KMS. From the folder shortcut menu, select New Certificate To Issue.
In the Select Certificate Template dialog box, select the Exchange Signature Only template and click OK.
Repeat steps 2 and 3 for the Exchange User and Enrollment Agent (Computer) templates. Depending on your other PKI requirements, you might need to enable more templates.

Once these templates are in place, you can install the Exchange KMS from the Exchange 2000 Server CD. Run Exchange Setup, then use the Change and Install options to add KMS to an Exchange server. Exchange s setup utility is smart enough to check for the existence of an enterprise CA with the correct templates. After you install the KMS, you ll be ready to start using it.

Note	The account you use to install the KMS is granted KMS administrator privileges. You ll need to use Exchange System Manager to assign additional administrators once KMS is up and running.

KMS requires a separate password to start. This is less of a hassle than it would seem, because the KMS only has to be running when you want to issue certificates. When you install the KMS, you ll get to specify whether you want to save the KMS password on a disk (removable or fixed) or write it down for manual entry. Keeping it on a removable disk allows you to lock it up to restrict KMS access; just remember that floppy disks are notoriously unreliable, so make sure you keep a backup, or perhaps use a more reliable storage medium.

Each account given KMS administrator privileges has a separate KMS password that must be entered for every KMS function. This password is completely separate from, and should differ from, the Active Directory account password. The account you used to install KMS will be assigned the default password of password . Obviously, this should be changed immediately (as described later).

Note	Remember that you have to manually start the KMS each time a KMS server reboots ”it s not set to automatically restart, and you shouldn t set it to do so. Use Exchange System Manager to start and stop the KMS when needed.

Managing KMS

After you install KMS, you ll see a new object in the administrative group you installed KMS in: Advanced Security. Selecting this object reveals that it has two subordinate nodes, Encryption Configuration and Key Manager.

Let s deal with the simpler one first: the Encryption Configuration. This object allows you to see that the KMS is installed (no kidding ”see the General tab) and to set the algorithms available to users of this KMS, as shown in Figure 12-7. In normal operation, you won t need to change these settings.

Figure 12-7: The KMS lets you set preferred algorithms for downlevel and S/MIME clients .

The Key Manager object is more complicated, because it s where you actually configure the KMS. To open it, you ll have to enter your KMS administrator password. The resulting Key Manager Properties dialog box has four tabs, each one of which allows you to do something useful:

The General tab The General tab allows you to view the CA certificate used by the KMS; click View Details to open the certificate s Properties dialog box, from which you can see its certification path or attributes. See Figure 12-8.

Figure 12-8: If your KMS certificate is invalid, you won t be able to use KMS.
The Enrollment tab The Enrollment tab allows you to choose whether or not you want tokens for enrolled or recovered users to be sent over e-mail, and, if you do, what you want the enrollment message to say.
The Administrators tab The Administrators tab shows you who has administrative permissions on the KMS; it allows you to add or remove administrator accounts or change passwords on existing accounts.

The Passwords tab The Passwords tab, shown in Figure 12-9, has a misleading name. It should be called the two-man rule tab, because its intent duplicates the long-standing U.S. policy that any operation involving arming or firing a nuclear weapon must involve at least two people. Likewise, the Passwords tab lets you specify how many administrators must concur before some kinds of changes can be made. The top field controls how many administrators must agree on adding or removing administrator accounts or editing any of the other policies on the Passwords tab; the others (whose values cannot be greater than the Add/Delete Administrators, Edit Multiple Password Policies value) apply to the specific actions listed.

Figure 12-9: Use the Passwords tab to specify how many people must concur before revoking or recovering users certificates.

Tip	You re probably familiar with the common recommendation to use groups to assign permissions on objects in Windows. That would be a bad idea for the KMS, so you can only add domain user accounts using the Administrators tab.

Enrolling Users with KMS

Enrollment consists of creating a temporary secret key for the user and providing it to him or her; the user then generates a key pair and uses the temporary key to encrypt it and return it to the KMS. The temporary key can be sent in an e-mail ( convenient , but not terribly secure), or you can deliver it to the user manually. In either case, once the user has his or her token, he or she can enroll using Outlook (as described in Chapter 13).

Enrolling Individual Users

Enrolling individual users is simple; you do it from the Active Directory Users And Computers snap-in. Just do the following:

Verify that the Microsoft Exchange KMS is started.
Launch the Exchange-aware version of Active Directory Users And Computers and open the user s Properties dialog box.
Click the Exchange Features tab, then select E-Mail Security and click Properties. After you enter your KMS password, you are given a list of available options based on the current enrollment status of the user: Enroll, Recover, and Revoke, as shown in Figure 12-10.

Figure 12-10: You can enroll, recover, or revoke users from their Properties dialog boxes in Active Directory Users and Computers.
Click Enroll on this screen to begin the enrollment process; the KMS generates a temporary token and (depending on the option you set on the KMS Enrollment tab) either e- mails it to the user or displays it in a dialog box so that you can send it on.

Enrolling Users en Masse

You can enroll multiple users at once using the KMS Key Manager object in Exchange System Manager. The trick is to right-click Key Manager; when you do, you ll see that the All Tasks command in the shortcut menu has commands to enroll, revoke, recover, import, or export users in batches. To enroll multiple users, right-click Key Manager, choose All Tasks Enroll Users, and enter your KMS password. The Enroll Users Selection dialog box opens, so you can choose your preferred method of enrollment from these options:

Choose users from the global address list. This gives you fine-grained control, but the filter that KMS uses is not smart enough to filter out contacts. However, it is smart enough not to let you select them for enrollment. If you have numerous contacts, this might cause some extra scrolling hassle when enrolling.
Choose a mailbox database from the administrative group that the KMS is in. This allows you to quickly enroll all users in that mailbox store.

Note that there s no middle ground ”for example, it would really be nice to have a way to enroll an OU or domain of users, but at present KMS can t use anything other than mailbox database membership as a selection criteria. Once you select the users to be enrolled, enrollment proceeds as it does with individual users.

Recovering and Revoking User Certificates

Recovering users certificates is what you do when they ve lost access to the private key (usually because they forgot the associated password); in essence, recovery rekeys the certificate. When you recover a certificate, the user gets a new enrollment token and proceeds as though it were the initial enrollment; KMS is smart enough to update the keys and reissue the certificate. Revocation, of course, is a different matter altogether; when you revoke a certificate through KMS, it goes on the CRL and can no longer be used.

In either case, you can recover or revoke users one at a time or en masse: individual actions happen through the Active Directory Users And Computers snap-in, and group operations require you to right-click the Key Manager node and choose the appropriate shortcut menu command, as described earlier in the chapter.

Migrating Exchange KMS to Windows Server 2003

Windows Server 2003 fortunately provides an easy migration path from the Exchange 2000 Key Management Server; however, if you re running Exchange 5.5, you must first upgrade your Exchange 5.5 KMS servers to Exchange 2000 in order to perform the migration. Similarly, customers that desire to upgrade to Exchange Server 2003 must first migrate the KMS server prior to upgrading the Exchange server hosting KMS to Exchange Server 2003. You can t migrate from the Exchange 2000 KMS to a Windows 2000 certificate authority.

The migration steps required to move from an Exchange 2000 KMS to a Windows Server 2003 certificate authority are fairly straightforward. First, let s outline the basic requirements for a migration:

Exchange 2000 KMS server If you have an Exchange 2000 KMS server, you must first upgrade to Exchange 2000.
Windows 2000 Active Directory with SP3 or higher on all domain controllers Windows Server 2003 certificate services requires secure channel communication with Active Directory provided first in Windows 2000 Server SP3.
Windows Server 2003 schema extensions for Active Directory Windows Server 2003 certificate services requires version 2 templates for key archival enabled with the Windows Server 2003 schema extensions.

Windows Server 2003 Enterprise Edition or Datacenter Edition running Certificate Services in enterprise mode Key archival and recovery requires version 2 certificate templates that are only available for use with certificate services running in enterprise mode on Windows Server 2003 Enterprise Edition or Datacenter Edition.

Caution

Exchange KMS has the capability to publish an x.509 v1 certificate revocation list to support x.509 V1 certificates. Once Exchange KMS is migrated to a Windows Server 2003 CA, the v1 certificates can no longer be revoked and it is recommended that a KMS migration is only performed when all V1 certificates are expired and/or are no longer being issued by Exchange KMS. If x.509 version 3 certificates are being issued by Exchange KMS with a Windows 2000 or Windows Server 2003 CA, the existing CA will need to be maintained to publish CRL(s) until all the original certificates issued by Exchange KMS have expired .

Once you have the proper environment to facilitate the migration, the basic steps for performing the migration are quite simple.

Configure the Windows Server 2003 certificate services for key archival. Configuring the CA for key archival requires configuring the Recovery Agents tab of the certification authority MMC snap-in. To enable key archival, select the Archive the key radio button and select the correct number of key recovery agent certificates on the CA.
Enable foreign key import functionality on Windows Server 2003 certificate services. This step is necessary to allow certificates and keys not issued by the certificate authority to be imported and managed on the CA. To enable this functionality, the following command must be run from the command line:
```
 certutil -setreg ca\KRAFlags +KRAF_ENABLEFOREIGN 
```
Once the command has been completed, the certificate server service must be restarted.

Identify, select, and export an encryption certificate to protect the files exported from the Exchange 2000 KMS database. Exchange 2000 KMS requires a public key certificate to be supplied as part of the user export process and the certificate authority holds the corresponding private key to decrypt and import the exported files. To view and export (and possibly enroll) a certificate to be used for the Exchange KMS export process, open the Certificates MMC console for the local machine on the Windows Server 2003 certificate authority and view the available certificates under the Personal store. Either a Web server authentication or computer authentication certificate will support an Exchange KMS database migration. Export the certificate and make the certificate available to the Exchange 2000 KMS server.

Caution

Windows Server 2003 will maintain an encryption certificate for the purposes of client key archival. This certificate should be used for the purposes of protecting and exporting Exchange KMS users.

The next step is to export the Exchange KMS database. To perform the export operation on the KMS Server, first start the Exchange System Manager. Locate the Advanced Security node, right-click Key Manager, select All Tasks, and then Export Users. Next, enter the KMS password (the default password for KMS is password ), and then click OK. The Exchange KMS Key Export Wizard will start. Click Next. Click Browse to select the Certificate that will be used to encrypt the export file. This is the certificate file exported from the Windows Server 2003 certificate services. The export wizard requires validation of the encryption certificate before proceeding with the export. Type the first eight characters of the certificate thumbprint in the thumbprint field, and then click Next. To continue, type the name of the database export file to be used without a path as part of the file name. The files will be saved in the default installation folder for Exchange. Next, select the set of users or administrative groups to be included in the database export. When complete, copy the export files to the certificate server.
To complete the migration, the Exchange KMS database migration files must be imported on the Windows Server 2003 certificate server. To import the files, run the following command from the command line:
```
 CertUtil.exe -f -importkms <name of export file> 
```
The Windows Server 2003 will report status on the number of certificates and private keys imported and the success of the overall import process.

That s it ”you may now deprecate the Exchange KMS from your secure messaging infrastructure.