Using Public Key Infrastructure with Exchange Server 2003

Public Key Infrastructure (PKI), in a nutshell , is an extensible infrastructure used to provide certificate-based services. It is a conglomeration of digital certificates, registration authorities, and Certificate Authorities that can be used to provide authentication, authorization, non- repudiation , confidentiality, and verification. A Certificate Authority (CA) is a digital signature of the certificate issuer.

PKI implementations are widespread and are becoming more of a critical component of modern networks. Windows Server 2003 fully supports the deployment of various PKI configurations. PKI deployments can range from simple to complex, as illustrated in Figures 13.1 and 13.2, with some PKI implementations using internal and external PKIs to supply a wide range of services and trust relationships with other entities. Although entire books are dedicated to PKI, this chapter focuses on how PKI can be used to secure Exchange Server 2003 implementations.

Figure 13.1. A simple PKI.

Figure 13.2. A complex PKI.

Certificate Services in Windows Server 2003

Windows Server 2003 includes a built-in Certificate Authority (CA) known as Certificate Services. Certificate Services can be used to create certificates and subsequently manage them; it is responsible for ensuring their validity. Certificate Services can also be used to trust outside PKIs, such as a third-party PKI, to expand services and secure communication with other organizations.

The type of CA that you install and configure depends on the purpose or purposes of the Windows Server 2003 PKI. Certificate Services for Windows Server 2003 can be installed as one of the following CA types:

• Enterprise Root Certification Authority The enterprise root CA is the most trusted CA in an organization and, if required in an organization, should be installed before any other CA. All other CAs are subordinate to an enterprise root CA. Enterprise root CAs store certificates in Active Directory (AD) by default.

• Enterprise Subordinate Certification Authority An enterprise subordinate CA must get a CA certificate from an enterprise root CA but can then issue certificates to all users and computers in the enterprise. These types of CAs are often used for load balancing of an enterprise root CA; more importantly, using subordinates provides stronger security for the PKI.

• Standalone Root Certification Authority A standalone root CA is the root of a hierarchy that is not related to the enterprise domain information, and therefore certificates are not stored in AD. Multiple standalone CAs can be established for particular purposes.

• Standalone Subordinate Certification Authority A standalone subordinate CA receives its certificate from a standalone root CA and can then be used to distribute certificates to users and computers associated with that standalone CA.

Windows Server 2003 PKI can also be either online or offline. The key difference is the level of security that is required in the organization.

TIP

An enterprise root CA is the most versatile CA in Windows Server 2003 because it integrates tightly with AD and offers more certificate services. If you're unsure as to what CA to use, choose an enterprise root or subordinate CA for use with messaging. Most importantly, however, is that with any PKI there must be careful planning and design.

PKI Planning Considerations

Any PKI implementation requires thorough planning and design, as noted earlier. Possible planning and design considerations include the following:

• Multinational legal considerations, including creation and standardization of a formal Certificate Practice Statement (CPS)

• Policies and procedures for issuing, revoking, and suspending certificates

• PKI hardware identification and standardization, including employee badge integration

• Determination of CA hierarchy administration model

• Creation of a redundant CA infrastructure based on geographical location

• Policies and procedures for creation of CAs as subordinates and policy enforcers within a greater hierarchy including qualified subordination and cross-certification

• Policies and procedures for creation of Registration Authorities (RAs) and their placement within the CA hierarchy

• CA trust strategies

• Policies and procedures for maintaining the CA as a 7x24x365 operation

• Policies and procedures for key and certificate management, includingbut not limited tokey length, cryptographic algorithms, certificate lifetime, certificate renewal, storage requirements, and more

• Policies and procedures for securing the PKI

• Published plans for providing high availability and recoverability

• Policies and procedures for integrating the CA with LDAP and/or Active Directory

• Policies and procedures for integrating with existing applications

• Policies and procedures for security-related incidents (for example, bulk revocation of certificates)

• Policies and procedures for delegation of administrative tasks

• Standards for PKI auditing and reporting

• Policies and procedures for change control

• Standards for key length and expiration of certificates

• Policies and procedures for handling lost certificates (that is, smartcard )

• Policies and procedures for safe distribution of the CA public key to end-users

• Policies and procedures for enrollment (for example, auto-enrollment, stations , and so forth)

• Policies and procedures for incorporating external users and companies

• Procedures for using certificate templates

As you can see from this list, implementing PKI is not to be taken lightly. Even if the organization is implementing PKI just for enhanced Exchange Server 2003 messaging functionality, the considerations should be planned and designed.

Installing Certificate Services

To install Certificate Services on Windows Server 2003, follow these steps:

1. Choose Start, Control Panel, Add or Remove Programs.

2. Click Add/Remove Windows Components .

3. Check the Certificate Services box.

4. A warning dialog box will be displayed indicating that the computer name or domain name cannot be changed after you install Certificate Services. Click Yes to proceed with the installation.

5. Click Next to continue.

6. The next screen enables you to create the type of CA required. Refer to the preceding list for more information about the different types of CAs that you can install. In this example, choose Enterprise Root CA and click Next to continue.

7. Enter a common name for the CAfor example, TestCA .

8. Enter the validity period for the Certificate Authority and click Next to continue. The cryptographic key will then be created.

9. Enter a location for the certificate database and then database logs. The location you choose should be secured to prevent unauthorized tampering with the CA. Click Next to continue. Setup will then install the CA components.

10. If IIS is not installed, a prompt will be displayed indicating that Web Enrollment will be disabled until you install IIS. If this box is displayed, click OK to continue.

11. Click Finish after installation to complete the process.

Fundamentals of Private and Public Keys

Encryption techniques can primarily be classified as either symmetrical or asymmetrical . Symmetrical encryption requires that each party in an encryption scheme hold a copy of a private key , which is used to encrypt and decrypt information sent between the two parties. The problem with private key encryption is that the private key must somehow be transmitted to the other party without it being intercepted and used to decrypt the information.

Asymmetrical encryption uses a combination of two keys, which are mathematically related to each other. The first key, the private key, is kept closely guarded and is used to encrypt the information. The second key, the public key , can be used to decrypt the information. The integrity of the public key is ensured through certificates. The asymmetric approach to encryption ensures that the private key does not fall into the wrong hands and only the intended recipient is able to decrypt the data.

Understanding Certificates

A certificate is essentially a digital document issued by a trusted central authority that is used by the authority to validate a user 's identity. Central, trusted authorities such as VeriSign are widely used on the Internet to ensure that software from Microsoft, for example, is really from Microsoft, and not a virus in disguise.

Certificates are used for multiple functions, including, but not limited to, the following:

• Secure email

• Web-based authentication

• IP Security (IPSec)

• Secure Web-based communications

• Code signing

• Certification hierarchies

Certificates are signed using information from the subject's public key; identifier information such as name, email address, and so on; and the CA.

Certificate Templates

As mentioned earlier, there are multiple functions for certificates, and hence there are multiple types of certificates. In other words, one certificate may be used to sign code and another certificate used to provide support for secure email. This is a one-to-one relationship wherein a certificate is used for a single purpose. Certificates can also have a one-to-many relationship wherein one certificate is used for multiple purposes.

TIP

One of the best examples of a certificate that uses a one-to-many relationship is the user certificate. A User certificate by default provides support for user authentication, secure email, and the Encrypting File System (EFS), as shown in Figure 13.3.

Figure 13.3. Default properties for the User certificate.

Windows Server 2003 contains a large number of certificates, and each has an assigned set of settings and purposes. In essence, certificates can be categorized into six different functional areas:

• Server Authentication These certificates can be used to authenticate servers to clients as well as provide authentication between servers.

• Client Authentication These certificates are used to provide client authentication to servers or server-side services.

• Secure Email Users can digitally sign and encrypt email.

• Encrypting File System These certificates are used to encrypt and decrypt files using EFS.

• File Recovery These certificates are used for recovering encrypted EFS files.

• Code Signing These certificates can sign content and applications. Code signing certificates help users and services trust code.

Customizing Certificate Templates

To customize a certificate template to be used in the network environment, use the Certificate Templates snap-in, as shown in Figure 13.4. To use this snap-in, do the following.

1. Open the Run dialog box from the Start menu and type MMC .

2. In the MMC console window, select Add/Remove Snap-in from the File menu.

3. Click the Add button and select the Certificate Templates snap-in.

4. Click Add and then click Close.

5. Click OK when done.

6. In the left pane, select Certificate Templates. This will display in the right pane all the available certificate templates.

7. Right-click the template to modify and select Duplicate Template. For this example, select the User certificate template.

8. Type the certificate template display name from within the General tab, as shown in Figure 13.5.

   Figure 13.5. Customizing a certificate template.

   

9. Within the Request Handling tab, verify that the purpose of the certificate is to provide signature and encryption capabilities.

10. On the Issuance Requirements tab, select whether the certificate requires manager approval and the number of authorized signatures that are required. These options control how and when users can get the certificate.

11. On the Security tab, check which users will have enroll or auto-enroll rights. By default, the Domain Users group has enroll permissions.

12. Click OK when done.

Figure 13.4. The Certificate Templates snap-in.

Smartcards in a PKI Infrastructure

A robust solution for PKI can be found in the introduction of smartcard authentication for users. Smartcards are small devices that have a microchip embedded in them; this chip enables them to store unique information in each card. User login information, as well as certificates installed from a CA server, can be placed on a smartcard. When a user needs to log in to a system, the user places the smartcard in a smartcard reader or simply swipes it across the reader itself. The certificate is read, and the user is prompted only for a PIN, which is uniquely assigned to each user. After the PIN and the certificate are verified , the user can log in to the domain.

NOTE

Smartcards can also be used to complement the use of passwords. For instance, strong passwords can be used in addition to a PIN number if the organization's security policy dictates very strong authentication requirements.

Smartcards have obvious advantages over standard forms of authentication. It is no longer possible to simply steal or guess someone's username and password, because the username can be entered only via the unique smartcard. If stolen or lost, the smartcard can be immediately deactivated and the certificate revoked . Even if a functioning smartcard were to fall into the wrong hands, the PIN would still need to be used to properly access the system. Smartcards are fast becoming a more accepted way to integrate the security of certificates and PKI into organizations.

Certificate Enrollment

Users must first be issued certificates before they are able to sign or encrypt messages. How users obtain the certificates depends on the organization's security policy and procedures and the infrastructure that is in place to support certificate services. If the organization is using Windows Server 2003 Certificate Services, users can obtain certificates in the following manner:

• Auto-enrollment

• Using smartcards

• Using the Web enrollment form

• Using the MMC

NOTE

When using Windows Server 2003 Certificate Services (PKI), public keys are stored in the AD, which enables users in the AD to encrypt messages for others in the AD. Private keys, on the other hand, are typically stored on the user's computer or on a smartcard.

Use the following steps to request a certificate using the MMC:

1. Type certmgr.msc from the Start, Run command window.

2. In the Certificate Manager window, expand CertificatesCurrent User.

3. Right-click on Personal and select All Tasks, Request New Certificate.

4. Click Next in the Certificate Request Wizard and then select the User certificate. It is important to note that these certificates must be made available to the users. Refer to the section "Customizing Certificate Templates," earlier in this chapter, for more information on how to provide certificates to users.

5. Click Next and then type the friendly name for the certificate.

6. Click Next and then Finish when done.

In the Certificate Manager window, click on the Personal, Certificates folder to display the certificates that have been issued to the current user, as shown in Figure 13.6.

Figure 13.6. Displaying issued certificates of a user, using the Certificate Manager.

TIP

The Active Directory Users and Computers snap-in can be used to display which certificates have been issued to a user. Select Advanced Features from the View menu and then double-click the user. The certificates can be viewed on the Published Certificates tab, as illustrated in Figure 13.7.

Figure 13.7. Displaying issued certificates of a user, using Active Directory Users and Computers.