Technical White Paper

Published: February 2005; updated June 2009

Executive Summary

Many of the techniques and products available to help secure an enterprise network rely on some form of cryptography. A public key infrastructure (PKI) provides the certificates used by each party involved in a cryptographically secured electronic transaction. To help secure the Microsoft corporate network and certify its software, Microsoft Information Technology (Microsoft IT) needed to implement several initiatives that required cryptographic techniques. Today, these initiatives include:

• Certificate-based 802.1X wireless authentication.
• Smart cards for two-factor remote access authentication.
• Secure Multipurpose Internet Mail Extensions (S/MIME) for digitally signing and encrypting e-mail.
• Encrypting File System (EFS) for file and folder encryption.
• Internet Protocol security (IPsec) for the security of network transactions.
• Secure Sockets Layer (SSL) for the security of Web connections.
• Network Access Protection (NAP) for enforcing system health.

These initiatives required the presence of an enterprise-wide PKI to provide public key–based security services.

Running its own certification authorities (CAs) rather than using commercial, third-party services enabled Microsoft IT to more securely manage the infrastructure and reduce the costs associated with issuing certificates and managing an external CA relationship. Implementing an enterprise PKI enabled Microsoft IT to better secure its network-based communications.

Microsoft IT's easy-to-manage, standards-based, scalable PKI solution resulted in a method to exchange sensitive data, compatibility with other Microsoft applications, and lower infrastructure costs.

This white paper describes the production deployment and use of the PKI features available in the Windows Server® 2003, Windows Server 2008, and Windows Server 2008 R2 operating systems. This white paper also offers lessons learned and best practices, and it includes a discussion on the future directions of the technology at Microsoft. It assumes that readers are technical decision makers and are already familiar with the fundamentals of public key cryptography systems, the benefits that such systems offer, and the components required to implement those systems. Links to additional sources of information about PKI are available in the "For More Information" section at the end of this paper.

This paper, first published in June 2005 and updated in May 2009, reflects the deployment of new Microsoft products within the corporate infrastructure and describes associated infrastructure changes.

Introduction

The charter of Microsoft IT is to maintain an IT environment composed of services, applications, and an infrastructure that provides availability, privacy, and security to Microsoft employees in more than 400 locations worldwide. Microsoft IT is responsible for running the company's internal networks, telecommunication systems, corporate servers, and all line-of-business applications. In addition, Microsoft IT is committed to testing Microsoft enterprise products in a production environment before they are released to the public (a process commonly referred to as "dogfooding"), and providing feedback to the product development groups by being their first and best customer.

Currently, the server infrastructure at Microsoft consists of servers running Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. Security continues to be at the highest level of priority across all areas of product development at Microsoft and within the corporate infrastructure. By implementing an enterprise PKI, Microsoft IT can use standards-based cryptographic technologies to help secure the Microsoft corporate network and its data.

Initial PKI Deployment

The first PKI hierarchy at Microsoft was introduced in February 2000 and consisted of three tiers: one stand-alone offline root CA; two stand-alone intermediate CAs; and multiple specialized, online enterprise issuing CAs.

The offline root and two intermediates functioned as follows:

• Microsoft Corporate Root CA. This CA was the root of the corporate PKI hierarchy. Its only purpose was to issue or revoke the certificates of the two offline intermediate CAs.
• Microsoft Intermediate Intranet CA. This offline intermediate CA certified all other CAs used to issue certificates intended for use only within the bounds of the Microsoft corporate network environment.
• Microsoft Intermediate Extranet CA. This offline intermediate CA certified all other CAs used to issue certificates intended for use outside the bounds of the Microsoft corporate network, including the Internet and the Microsoft extranet environment.

There was no support for cross-forest enrollment; therefore, each forest required its own set of enterprise CAs. However, each forest used the same offline stand-alone root and intermediate CAs.

All the enterprise issuing CAs were subordinate to the intermediate CAs. Table 1 details the function of each issuing enterprise CA in the hierarchy.

Table 1. Types of Online Enterprise Issuing CAs Initially Deployed

Figure 1 shows the hierarchy of CAs in the initial primary PKI design that Microsoft IT created. A secure, Microsoft IT–controlled vault housed all of the CAs.

Figure 1. Hierarchy of the initial primary PKI design with Microsoft® Windows® 2000 Server

The stand-alone, offline root signed the offline intermediate CAs. Then, the offline intermediates signed the online enterprise subordinate CAs. The online enterprise CAs were the issuing CAs for all certificates issued internally at Microsoft.

Microsoft IT defined the root certificate as a 16-year CA certificate lifetime, a 4,096-bit key length, and a 90-day Certificate Revocation List (CRL) publishing interval. The CRL was published to an external Hypertext Transfer Protocol (HTTP) path and in the Active Directory® directory service through a Lightweight Directory Access Protocol (LDAP) URL. Microsoft IT defined a two-year CA lifetime for each of the issuing CAs, by using 2,048-bit keys. The CRL publication interval on the issuing CAs varied, depending on the function of the certificates being issued.

End-entity certificates are generally issued with a validity period of one year or less. Because a CA cannot issue a certificate with a validity period that exceeds that of its own certificate, the certificates for issuing CAs need to be renewed annually. The issuing CAs can thus continue to issue end-entity certificates that will be valid for their full, intended one-year validity period.

Changes to the Multi-Tier Structure

The primary reason for deploying the three-tier hierarchy was the intended separation of internally used certificates versus those that would be used outside the company, which would potentially drive the need for different certificate policies in addition to overall service management practices. However, the existing private corporate root was not very usable for security-enhanced communications outside the Microsoft corporate network. Because the Microsoft corporate root was unique to Microsoft, no one outside Microsoft trusted it by default. It is critical that client computers trust certificates, such as those used for SSL server authentication. Because of this requirement, Microsoft IT used to purchase individual certificates for SSL-enabled Web sites that non-Microsoft personnel were intended to access. Microsoft IT purchased these certificates from a publicly trusted, third-party provider, rather than issuing them from the Microsoft internal PKI infrastructure.

As the use of individual publicly trusted certificates grew, Microsoft IT found that purchasing these certificates was increasingly expensive. The use of S/MIME was also increasing. S/MIME certificates were all issued by CAs that chained to the Microsoft corporate root. To facilitate usage of these certificates outside the Microsoft corporate network, external recipients needed to manually install the Microsoft Corporate Root Certificate. This process and the user education around it proved to be laborious. Microsoft IT needed to include the architecture of a public root hierarchy in its PKI infrastructure for external security requirements, so that all parties could acknowledge that they trusted the root of the certificate chain.

Rather than continue to buy each end-entity certificate individually from a trusted third-party provider, Microsoft IT decided to create a second, independent PKI infrastructure by subordinating its own offline intermediate CA to that of a publicly trusted root CA. Microsoft IT agreed to pay GTE CyberTrust, Inc., an annual fee for subordinating a Microsoft CA under the GTE CyberTrust Root and GTE CyberTrust Global Root. Since 1998, both of these root certificates have been shipped as trusted roots in Microsoft operating systems and a variety of third-party operating systems. The GTE CyberTrust roots provide the ubiquity that Microsoft needed to satisfy its public trust needs for both SSL and S/MIME.

With this new model, the third-party provider handled all of the issuance and revocation needs for the new intermediate CA. Microsoft IT staff continued to own and manage all the internally managed CAs. These new developments negated the need to retain the original intranet and extranet offline intermediate CAs, for that reason Microsoft IT made a decision to retire them.

Figure 2 depicts the hierarchical changes after Microsoft IT adopted a publicly trusted root model.

Figure 2. Modified hierarchy

Security Requirements

Even though Microsoft internal hierarchy no longer had the previous intermediate CAs, Microsoft IT did not lower any of the existing security controls. The root and the new intermediate CA were offline and never exposed to network traffic, thereby minimizing the chance of a compromise. Because these CAs were offline, Microsoft IT security staff manually issued and published their certificates (through a portable medium) to Active Directory. Additionally, the security staff issued certificates to all online enterprise CAs in the appropriate Active Directory forest by manually copying certificate request files from the online servers to the offline roots and intermediate. The security staff used portable media to transport the certificates between servers. The requests were processed, and security staff transferred the issued certificates from the offline CA back to the online server for installation.

To decide on the security required for a CA, Microsoft IT determined the risks of attack on the CA in addition to the costs of a CA compromise. Higher risks of attacks on the CA and higher costs of a CA compromise justified higher costs for security measures to protect the CA. Offline root (and subordinate) CAs usually need higher levels of protection than issuing CAs.

Certificate Services in Windows Server 2003—the feature called Active Directory Certificate Services (AD CS) in Windows Server 2008 and Windows Server 2008 R2—shipped with a software cryptographic service provider (CSP) that complied with the Level-1 requirements of Federal Information Processing Standard (FIPS) 140-1. To provide stronger protection of the CA's private keys, Microsoft IT installed Hardware Security Modules (HSMs) on each CA server. The modules were certified to FIPS 140-1, Level-2 and Level-3. Microsoft IT determined that it needed to raise the security level of the offline root to FIPS 140-1, Level-3.

After evaluating the risks of an attack and then weighing those against the cost of service recovery, an organization should determine its own level of security protection for its CAs, especially the root CA. Security protection does not have to be expensive, especially for smaller companies. There might be adequate protection in having the offline root CA in a secure computer cabinet or using removable media that is stored in a safe.

The sections that follow describe the security measures that Microsoft IT took in its Windows Server PKI infrastructure.

Protection of CA Private Keys

The operating system manages the private-key pairs generated by a software CSP in Windows Server. This situation exposes a considerable risk if the system is compromised. With these keys, an attacker can re-create the CA and issue seemingly valid certificates. This is a typical FIPS 140-1 Level-1 security risk, which an organization can mitigate by providing more difficult and verifiable physical access to the Windows Server CA system.

Microsoft IT chose to mitigate the risk associated with private key storage by using HSMs in all deployed CAs. By using specialized, tamper-resistant hardware to help protect private cryptographic keys, HSMs provide a high level of security for the keys, for the CA, and for the certificates that the CA signs. Microsoft IT decided to use the nCipher nShield HSM because:

• It provides interaction with CryptoAPI.
• It provides the FIPS 140-2 Level-2 and Level-3 validated security certifications that Microsoft IT required for its security standards.

The nCipher nShield modules are certified for FIPS 140-1 Level-3 compliance. This was important in establishing a level of trust between Microsoft and its business partners, including the U.S. government. The Microsoft Corporate Root CA used an HSM configured in FIPS 140-1 Level-3 mode.

Each nShield HSM contains an integrated smart-card reader. When configuring the nCipher HSMs, Microsoft IT created security worlds with administrative card sets, most composed of six smart cards, any three of which were required to perform administrative functions. A security world is a concept encompassing secure key protection practices, which can be certified according to the Federal Information Processing Standards (FIPS) standards Microsoft IT needed the administrative cards whenever it brought a new CA online and added it to the associated security world. The Legal and Corporate Affairs department received two cards, the Corporate Security team retained two others, and Microsoft IT stored the final two at an offsite facility as a backup. The requirement of three smart cards for signing operations provided role separation and guaranteed that performing such high-level functions required the involvement of members from more than one group.

Microsoft IT adhered to the following model when creating nCipher security worlds for various levels of the hierarchy:

• A root security world for the offline corporate root CA
• A policy security world for the offline intermediate CA
• An issuing security world containing all online issuing CAs

The security worlds provided a distinction between the various CAs and administration activities. By separating the issuing security world from the offline security worlds, and by using the principle of least privilege, Microsoft IT obtained a greater level of assurance.

In addition to the security worlds and the administrative cards, the HSM configuration used an operator smart card to help protect the private keys for each of the offline CAs. The Corporate Security team holds these cards. Because the Corporate Security team does not have access to the physical location of the servers, it had to cooperate with Microsoft IT whenever it needed access to these servers' private keys. Originally, the operator cards for the online issuing CAs remained inserted into the nShield modules because they were needed each time a CA's key was accessed. However, Microsoft IT decided to change that model and migrated to the module protection type instead, because leaving an operator card inside the module is essentially the same as having the module protect the keys itself.

This level of security, in combination with stringent physical access, helped maintain a high level of assurance regarding the use of these CAs.

Physical Security

A Microsoft IT-controlled vault houses the offline CAs. Without network connectivity, certificate signing and revocation are manual processes that require physical access to the vault.

Entrance into the vault requires at least two authorized people at a time, and only people who have been approved by Corporate Security can enter the vault. Entry into the vault is further controlled through multiple security requirements, including the combined use of building access cards, biometrics, and personal identification numbers (PINs). In addition, one of the persons entering the vault must be one of two specifically designated employees with knowledge of the code needed to disarm the security alarm inside the vault.

Furthermore, the Microsoft Security Control Center monitors all vault entries and the alarm status. By policy, the Security Control Center must be notified of any vault entry and provided with the identities of the individuals making the entry. If the Security Control Center does not receive a notification, it investigates any detected entry into the vault as suspicious.

Originally, the Microsoft IT vault housed the online issuing CAs as well. However, to provide a more effective server and service management, Microsoft IT decided to move all of the issuing CAs to a data center with the rest of the company's server infrastructure, but place the CA computers into a separate security cage that employs a series of stringent security controls for higher protection. CA cage access is restricted to a limited number of data-center support personnel, and it requires the use of biometrics in addition to card keys. Inside the cage, the rack that holds the CAs is protected with an alarm system that must be disarmed by a minimum of two authorized individuals who must swipe their card keys. Finally, all activities in the cage are monitored by video surveillance in addition to physical security staff in the data center.

Network, Server, and Directory Security

Access control list (ACL) permissions control enrollment permissions on both the CA servers and the certificate templates in Active Directory. Microsoft IT restricted the issuance of sensitive certificate types—such as issuance of server authentication certificates, which validate the identity of the server computer—to only designated personnel. All of the information was published to various Active Directory containers controlled by ACLs. These containers are part of the Active Directory Configuration container, enabling the Configuration container to be replicated to all domain controllers within the forest. Microsoft IT thus maintains central control over enrollment of these certificates, mitigating the possibility of unauthorized certificate issuance and usage.

Though authorized data-center personnel have physical access to the CA servers, logon is not allowed (access is limited to hardware maintenance and support only). To assist with operating system and service monitoring, Microsoft IT reached an agreement with the Microsoft Global Operations team that acts as the first point of contact for support of the entire infrastructure at Microsoft (including domain controllers and other high-security servers) and allowed a subset of Global Operations senior staff members to log on to the CAs for the purpose of troubleshooting and regular maintenance. Members of this support team must use two-factor authentication to log on. Before access can be provisioned, each support technician must take CA training (in the form of a video course prepared by the Microsoft IT CA team) and have his or her manager certify that training was successfully completed. Upon completion of the training, each support technician must go through an official access-provisioning request process, which has been recently tied into the overall elevated account-provisioning process for all high-security access at Microsoft. After CA access is approved, the records are logged into a secure-access database and reviewed on a quarterly basis.

Policy Controls

In 2007, a new PKI Policy Committee was formed at Microsoft. It consisted of members of the Legal and Corporate Affairs department, the Corporate Security team, the PKI product group, and senior researchers in the area of cryptography. Additionally, the committee published a new document about PKI standards; this document required the committee to review and approved all proposed changes to the Microsoft IT PKI. Such changes include creating a new CA, modifying template permissions, and provisioning new access. This extra layer of control helps ensure that all Microsoft IT PKI operations match all corporate and government policies, in addition to the overall Microsoft direction in the Certificate Services arena.

CRL and AIA Considerations

During the installation and configuration of Certificate Services, Microsoft IT configured each of the following:

• Publication of offline CAs to Active Directory. Microsoft IT published the offline root and subordinate CAs to Active Directory through certutil.exe. Microsoft IT published the root certificate directly to the Certification Authorities and Authority Information Access (AIA) containers of Active Directory. Microsoft IT uses the Certification Authorities container to define trusted root CAs within the enterprise, and all enterprise clients recognize it. Microsoft IT could have opted to distribute the root certificate by using Group Policy. However, this distribution would have required separate policy configurations for each domain in the enterprise structure. By publishing the root certificate directly to Active Directory, Microsoft IT pushed it to all enterprise clients—in multiple domains throughout the forest—in one process.

  Microsoft IT also originally published the offline intermediate CAs' certificates in the AIA container. This action provided a location from which users could obtain the certificates for the CAs. This container was an effective repository for CA certificates because it, along with the other PKI-related containers, is part of the Configuration container, which is replicated to every domain controller within the forest.

• Certificates to be issued. Microsoft restricted the issuing CAs to issuing only specific certificate types. By default, an enterprise CA is preconfigured with a variety of certificate templates. Microsoft IT deleted unwanted certificate templates from the CAs and added the templates that it wanted.
• CRL distribution point. The CRL distribution point is an extension in a certificate that defines where a CA publishes its CRL. The CRL distribution point is where any client or application that is performing certificate validation, including revocation checking, can retrieve the current CRL from the issuing CA. This location is written into the certificates that the CA issues. Before Microsoft IT installed Certificate Services, it defined the CRL distribution point URLs that would be included in the offline root certificate by creating a Capolicy.inf file and defining the paths that it wanted. Configuration of this extension in Certificate Services after installation then defined which URLs would be included in the certificates that the root CA issued.
• Authority Information Access. Similar to the CRL distribution point extension, the AIA extension defines where the CA's certificate is published. This information is also written into certificates that the CA issues. Prior to the installation of the CA, Microsoft IT defined in Capolicy.inf the information that would be written into the root certificate. Configuration of this extension in Certificate Services after installation then defined which URLs would be included in the certificates that the root CA issued.

CRL Publication

When any application, user, or process validates a certificate, it makes sure that the certificate chains to a root that is trusted on that system, is time-valid, and contains the specific functional capabilities for which it is being presented. If all of these checks pass, the certificate is considered valid.

The CRL is checked to make sure that certificates that otherwise would be considered valid have not been revoked. The CRL itself is a file, signed by the CA, that contains a list of revoked certificates. The list defines the revoked certificates by serial number, and it includes the revocation date in addition to the reason for revocation. The application that is performing the certificate validation determines whether or not it checks for revoked certificates as part of the validation process. When an application checks for revoked certificates, it retrieves the current CRL from one of the URLs specified in the CRL distribution point extension of the certificate being validated. After the CRL is retrieved, it is typically cached until its expiration. After a CRL is cached, the application performs further revocation checks against this cached copy, eliminating the need to retrieve the CRL for each revocation check. When expired, the CRL itself becomes invalid, forcing the download of a new CRL.

CRL Lifetime

Microsoft IT configured different CAs to have different CRL publication intervals, depending on how the certificates that the CAs issued were being used. For example, Microsoft IT configured the CRL lifetime to be 24 hours for the smart-card CAs, and four days for the utility CAs (Utility CAs are those CAs that issue a variety of certificates to Microsoft users and computers, including IPsec, wireless, domain controller authentication, remote access and IAS, and EFS.

The purpose of the differential was to balance the need for timely CRL updates if a certificate needed to be revoked, while minimizing the performance impacts of frequent CRL retrieval and directory replication. With the revocation of a smart-card authentication certificate, Microsoft IT wanted the revocation status to take effect as quickly as possible. Because a CRL is cached until it expires, short expirations would ensure timely CRL updates that would reflect current revocation status more quickly.

CRL publishing for the offline CAs is a manual process. The CRL lifetime for the offline CAs at Microsoft is 90 days. Members of the Corporate Security team must enter the vault to manually publish the CRL from these offline CAs because they are normally turned off and always lack network connectivity. Certificate Services/AD CS handles CRL publishing for the online CAs automatically.

A CRL has an established lifetime, and a new CRL must be published before the old CRL expires. The CRL publication interval includes a buffer to define a specific amount of time for which existing CRLs will remain valid after the next scheduled CRL publication. The purpose of this overlap period is to provide time for manual publication and replication of the newly created CRL prior to the expiration of the original CRL, and to avoid leaving a gap in the availability of a valid CRL. The default overlap period is 10 percent of the CRL lifetime period, with a maximum of 12 hours.

When Microsoft IT decided to publish a new CRL every 24 hours for smart-card CAs, the default overlap period was reduced to just 2.4 hours. Because this period did not provide sufficient time for replication of the new CRL throughout Microsoft IT‘s worldwide enterprise, before the previous CRL expired, Microsoft IT needed to manually configure the CRL overlap to extend the validity period. The extended period ensured that the old CRL would remain valid while the new CRL was being replicated throughout the network. As such, smart-card CA CRLs are published 24 hours with a 24-hour overlap period, making the CRL valid for 48 hours. The rest of the CA CRLs are published every four days with a four-day overlap period, making those CRLs valid for eight days.

PKI-Enabled Services

Microsoft IT had several user requirements that needed the deployment of cryptographic technologies. These requirements included:

• Enabling strong network user authentication by using smart cards.
• Helping to ensure the confidentiality and integrity of transmitted data by using IPsec.
• Helping to ensure the confidentiality of stored data by using EFS.
• Helping to secure e-mail by using S/MIME encryption and digital signatures.
• Helping to secure Web connections by using SSL or Transport Layer Security (TLS).
• Enforcing health of domain-member computers by implementing NAP.

The following sections describe how Microsoft IT was able to meet each of those requirements with the help of Certificate Services/AD CS.

Smart Cards for Remote Access

A smart card is a credit card–size, portable token that holds memory, a file and operating system, and a microprocessor; it might also contain radio frequency identification (RFID) and a personal identification photo printed on it—both important in considering physical authorization to company buildings or other controlled-access facilities.

Microsoft IT considered several alternative technology solutions before selecting smart cards as the preferred solution. Smart cards provided the best overall value based on reliability, performance, cost, features, mobility benefits, ease of support, and integration with the Microsoft IT Windows network environment.

Smart cards must support authentication and authorization: The cardholder is authenticated through the PIN, and can be authorized to access only a particular range of data on the card, or carry out a particular range of activities with the card. A key feature of smart cards is that they provide security-enhanced storage for data; one important component of such storage is smart-card logon certificates.

The combined use of the smart cards and Extensible Authentication Protocol (EAP)/TLS enables a much stronger authentication mechanism over the standard approach of entering a user name and password.

The smart-card solution initially took advantage of technologies found in the Windows 2000 Server infrastructure, including Certificate Services, Routing and Remote Access, and Internet Authentication Service (IAS). The smart-card solution was enhanced when Microsoft IT upgraded to Windows Server 2003. The PKI enhancements to Windows Server 2003 and Windows Server 2008 enabled Microsoft IT to better manage certificate enrollment and renewals, as well as delegate the process of creating and distributing smart cards.

To enable issuance of smart-card logon certificates, Microsoft IT deployed two CA servers for each production forest, and configured those to chain under the Microsoft Corporate Root CA. The two smart-card CAs act as smart-card issuing authorities only—no other certificate templates are deployed on these servers.

Two other certificate types are required for enabling smart-card-based logon:

• Domain controller authentication certificates (for all domain controllers in the forest)
• Remote access and IAS server certificates (for all Remote Authentication Dial-In User Service [RADIUS] servers participating if smart cards are used for virtual private network [VPN] access)

Microsoft IT issues both of those certificates from another set of CAs (utility CAs) that also chain to the Microsoft Corporate Root.

The Microsoft corporate environment encompasses nine forests, which include production, preproduction, and other business and test environments. Today, one administrator must sometimes manage resources across multiple forests. Hence, if an administrator must use his or her card to authenticate to a resource in another forest, the smart-card CA that issued the administrator's logon certificate must be trusted for authentication in the forest where the resource is being accessed. To accomplish that, Microsoft IT manually publishes the certificate of the issuing smart-card CA to the NTAuth container of every forest where the administrator might attempt to access the resource.

Delegated Issuance

Microsoft IT did not want to allow users to simply enroll themselves for smart cards. Microsoft IT wanted to maintain control of the issuance and distribution so that a face-to-face authentication could be performed and so that only authorized users received smart cards.

For the initial pilot deployment, the plan was for Microsoft IT staff (located in Redmond, Washington) to create and issue smart cards to all Puget Sound users, and then subsequently issue smart cards to all other users worldwide. However, Microsoft IT quickly discovered that for ongoing support, it needed a more distributed plan to securely and quickly cover the issuance of smart cards to users on a regional basis. Microsoft IT decided to use the delegated issuance model to support smart cards after the initial deployment.

The implementation of the delegated issuance model was possible only after Microsoft IT upgraded the corporate PKI to Windows Server 2003. The enhanced flexibility of the Windows Server 2003 and Windows Server 2008 PKIs—particularly the ability to specify detailed issuance requirements on the certificate templates—enabled the delegated issuance model to support the required limited functionality role of Delegated Issuance Officers (DIOs). Microsoft IT wanted to distribute the issuance of smart cards and maintain control over the issuance of the certificates on them. The delegated issuance model allowed the DIOs to submit certificate requests on behalf of other users, but the issuance of those certificates required the explicit approval of Microsoft IT. The new issuance requirement settings on Windows Server 2003 certificate templates enabled Microsoft IT to specify all new certificate requests to be set to a pending status and require approval from a certificate manager. After the request was approved and the certificate was issued, the DIO would be able to retrieve the certificate and write it to the user's smart card.

Members of Microsoft IT went on a worldwide tour to visit and train the various DIOs on their duties, required procedures, security considerations for smart-card distribution, and how to use the internally developed smart-card tools. Afterward, DIOs participated in weekly teleconferences with Microsoft IT to keep up to date on emerging and continuing issues.

Smart-Card Renewal

The Microsoft IT team also took advantage of the flexibility of PKI features in Windows Server 2003 and Windows Server 2008 to enable users to renew their smart-card certificates themselves. By using the new issuance requirement features, Microsoft IT was able to configure the certificate template such that authorized enrollment agents must perform initial enrollments for all new smart-card certificates. However, each user can renew his or her own smart-card certificate by employing the existing valid certificate to sign the renewal request for its replacement. This ability greatly reduces the ongoing costs associated with a smart-card deployment because Microsoft IT no longer needs to manually renew each smart card when the certificate expires.

In addition to enabling users to renew their own smart-card certificates, auto renewal functionality helps to ensure that users renew their certificates prior to expiration. The certificate template configuration allows for specification of the renewal period. When a certificate reaches this period, auto renewal code prompts the user to renew the certificate and provides an automated method to do so.

IPsec

IPsec is a framework of open standards for helping to protect communications over IP networks through the use of cryptographic security services.

In 2004, Microsoft IT introduced the concept of domain isolation to its corporate network. The purpose of such an initiative was to help protect domain-member, IT-managed resources from clients that are not members of an isolated domain. Microsoft IT chose IPsec as the enforcement method, and through a combination of Group Policy, IPsec policies and filters, Kerberos, and other key technologies, implemented it across the company.

Connection Manager, deployed to allow secure remote access to the corporate network, was also designed to require the use of IPsec in order to establish a secure connection to a domain-member resource. Additionally, Microsoft IT integrated Secure Remote User scripts that ran a set of checks on a client attempting to connect to the corporate network, and then performed several actions on that client to ensure that it met all the appropriate security policies. One of those actions was acquiring a computer certificate from one of the corporate utility CAs.

Microsoft IT provided two utility CAs (per forest) that were issuing IPsec certificates to client computers. Microsoft IT set the templates used for configuring the issuance of IPsec certificates to autoenroll, which helped streamline the issuance process. If, for any reason, the client failed to automatically obtain an IPsec certificate when trying to connect via remote access (Connection Manager), the client had an option to manually acquire such a certificate by using the CAs' Web enrollment pages. To allow that, however, Microsoft IT had to ensure that the issuing CA servers themselves would allow non-IPsec traffic; as a result, the servers were configured as IPsec boundary computers. Microsoft IT then published an IPsec Offline template on each of the utility CAs so that non-IPsec configured hosts could enroll for an IPsec certificate via the Web pages.

For more information about domain isolation via IPsec, refer to the IT Showcase white paper "Improving Security with Domain Isolation" at http://www.microsoft.com/downloads/details.aspx?FamilyID=A97DDC48-A364-4756-BB3C-91DA274118FE&displaylang=en

EFS

EFS is a component of the NTFS file system. It enables transparent encryption and decryption of files by using advanced, standard cryptographic algorithms. Any individual or program that does not have the appropriate cryptographic key cannot read the encrypted data. Encrypted files can be protected even from those who gain physical possession of the computer that contains the files. Even persons who are authorized to access the computer and its file system cannot view the data.

Microsoft IT enabled EFS via auto enrolled certificate templates published on two utility CAs (in each supported forest) that are signed by the Microsoft Corporate Root CA. Microsoft IT configured the two CAs with key archival to enable easy recovery of lost keys. It configured the EFS auto enrolled templates with a one-year validity period.

S/MIME

S/MIME is a technology that helps prevent impersonation and tampering with e-mail messages. S/MIME enables users to encrypt outgoing messages and attachments so that only intended recipients who have proper S/MIME certificates can read them. With S/MIME, users can also digitally sign outgoing messages. When a user digitally signs a message, he or she gives the recipient a way to verify the identity of the sender and verify that the message has not been tampered with.

The current Microsoft implementation of S/MIME includes storing encryption and digital signature certificates on smart cards. Employees can use any workstation equipped with a smart-card reader to send and receive S/MIME-enabled e-mail.

Before Microsoft IT started issuing S/MIME certificates, it configured a dedicated issuing CA, enabled it for key archival, and chained that CA up to a publicly trusted root (GTE CyberTrust Global Root). Configuring the CA for key archival allowed for fast key recovery in the case of lost keys, whereas establishing a third-party trust enabled Microsoft users to easily exchange security-enhanced e-mail with external recipients. However, the default third-party root CA policy did not include a key archival application policy. To enable it, Microsoft IT cross-certified its own intermediate CA that included such an application policy with the GTE CyberTrust Global Root which in turn allowed that function.

Microsoft IT now needed to publish certificate templates. Because the usage requirements and management practices for digital signature were going to be slightly different from that of encryption, Microsoft IT decided to create two separate templates. Table 2 shows the differences that led to that decision.

Table 2. Differences Between Digital Signature and Encryption

Microsoft IT chose to allow users to auto enroll for digital signature certificates at any time because there was no need to preserve those.

However, to simplify the recovery process, Microsoft IT decided to have a controlled deployment of encryption certificates. As such, Microsoft IT restricted auto enrollment to specific security groups. Such an approach also provided the opportunity for users to "opt in" to the use of S/MIME, as well as reduced additional support costs that would otherwise be associated with a global auto enrollment. As a result, Microsoft IT used a combination of an internal group management tool called Autogroup and back-end synchronization jobs to allow controlled enrollment of S/MIME encryption certificates.

Key Archival and Recovery

As previously mentioned, both EFS and S/MIME can use key archival. Private-key recovery does not recover any data or messages; it provides only recovery of lost or damaged keys. Often, keys must be recovered before encrypted data can be recovered.

One of the advantages of key recovery over data recovery is the savings recouped in support costs. For example, without key archival, if an EFS user encrypts a folder that contains 5 gigabytes (GB) of data on his or her local workstation and subsequently loses the private key, support teams must go through a laborious process of data recovery. This process includes:

1. Backing up the locally encrypted data.
2. Transporting the backup to a recovery workstation.
3. Restoring the encrypted data onto a support technician's recovery computer.
4. Decrypting the data.
5. Creating a new backup set of the decrypted data.
6. Providing the data back to the user on a read-only network share.
7. Having the user restore and re-encrypt the data for his or her own use.

Alternatively, due to the costs involved, decisions on when to spend limited support resources on such tasks might prohibit the data recovery effort except in critical cases, thereby depriving some users of access to their lost data.

With key archival, support staff must restore only the user's private key to enable the user to decrypt his or her own data at will. Key archival and recovery benefits the user by improving support services and speeding access to the encrypted data, while reducing support costs for the enterprise. Additionally, the recovery agent does not need to have direct access to the encrypted material, providing an even greater level of security for confidential business data.

Key Recovery Agents

Only users with specific rights can perform key recovery. When keys are archived, they are encrypted with the key recovery agent's public key and stored in the CA database. To mitigate potential abuses of the key recovery process, Microsoft IT recommends using role separation. The people who hold the key recovery agent certificate may be separate from those who are able to retrieve the encrypted blob from the CA. As a result, the people authorized to retrieve archived key blob from the CA database may not possess the key recovery agent certificate and key needed to decrypt the blob. Those who do possess the key recovery agent certificate and key may not have access to the CA database. In this scenario, to recover a lost key, multiple people from different groups must be involved in the process.

To provide further security of the highly sensitive key recovery agent certificate and private key, Microsoft IT uses an nCipher HSM to store and help protect this key on recovery workstations. In this scenario, each designated key recovery agent has an nCipher nShield HSM installed on his or her workstation. Access to the recovery agent key requires this module.

Dependencies

Several dependencies are required for an organization to take advantage of key archival and recovery:

• Key archival can be enabled only on Version 2 templates.
• Key archival and recovery can be performed only on Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter software running Certificate Services/AD CS.
• The CSP must be able to export the key. For example, the Microsoft CSP that Microsoft IT uses with its smart-card infrastructure is capable of a one-time export of its private key, for the purpose of key archival. Most smart-card CSPs, however, cannot export private keys.

For more information about the key archival and recovery process, refer to the white paper "Key Archival and Management in Windows Server 2003" at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx.

SSL

SSL is a protocol that provides authentication and encryption capabilities for Web browsers, network devices, and other connection-related technologies.

In the past, Microsoft purchased its SSL certificates from a third-party PKI provider by prepaying for a large quantity on a yearly basis. Additionally, to manage the issuance of those certificates to the end user and provide technical support, Microsoft IT had a staff of two administrators who were enrolled into the third-party SSL administration service, which also required the use of "administrator"-type SSL certificate that needed to be paid for and renewed on a periodic basis. This approach posed a significant cost to the company, taking into account the large population of Web servers that Microsoft IT must maintain to run the company's Web based services.

As a result, Microsoft IT decided to use Microsoft technology—Certificate Services—and introduce an internal PKI that would issue its own SSL certificates to Microsoft Web server administrators, but at the same time provide a public root trust by chaining to a third-party root. The root is the GTE CyberTrust Global Root, which Microsoft IT is currently using for S/MIME and the SSL PKI services.

Today, the SSL CA issues thousands of certificates that are used both inside and outside the company, with significantly lower operational costs.

To manage the issuance of SSL certificates, Microsoft IT collaborated with an internal development team and created a custom registration authority tool that is now being used to service internal SSL consumers. All SSL certificate requests must go through this tool; no direct enrollment is allowed. The CA has been configured to allow only Enroll permissions to the service account, which is used by the registration authority tool.

Before a user can request an SSL certificate through the tool, he or she must obtain an authorization for the site. The authorization process ensures that a valid business justification is presented and all proper approval is received before any further action can be taken. After that has been accomplished, the user can successfully start submitting his or her certificate requests via the tool. Only requests for the approved URL will be allowed; requests for any additional sites must follow the same process as described previously.

Another key feature that the internal registration authority application provides is a notification service that notifies the user's contact distribution list (required for enrollment) 30 days, 7 days, and 1 day before the certificate expiration date. This functionality helps prevents service interruptions by enabling timely renewals.

The SSL CA is an enterprise CA that is dedicated to SSL certificate issuance only. It currently chains to an offline subordinate, which then chains to the GTE CyberTrust Global Root.

Wireless

Wireless networking enables users to easily access resources on a corporate network without having to maintain a physical network connection. To provide secure authentication to company resources, a proper authentication mechanism must be put in place. Microsoft IT's implementation of such a mechanism was a combination of 802.1X authentication with certificates and EAP-TLS.

Microsoft IT chose to enforce the use of both user and computer certificates for 802.1X authentication. When a computer comes online and attempts to access the network in order to log on to the domain, it must present a valid computer certificate. When it does so, the authentication request is processed, and if successful, the computer is connected to the network. After the computer is connected to the network, the normal computer authentication occurs, and normal processes such as Group Policy updates can occur. By the time the computer authentication has occurred, the system is ready for user logon. The process of authenticating the computer and obtaining network access prior to user logon enables the user to perform an online interactive logon, as opposed using cached credentials.

After the user successfully logs onto the computer, a short delay occurs before the system attempts the 802.1X user authentication. The system attempts to perform an 802.1X authentication, by using the user certificate, similar to the one performed via the computer certificate. If the authentication attempt fails, the wireless network access is dropped. If it succeeds, the system remains on the network.

To enable user-based and machine-based certificate authentication, Microsoft IT relied on the deployment of the existing utility CAs, which enabled autoenrollment for domain-member, authenticated users and computers. Because the certificate provisioning process was automated, successful enrollment required no additional action.

Product Updates and Associated Infrastructure Changes

Windows Server 2008 and Windows Server 2008 R2 have introduced certificate service–related enhancements, including the following:

• Windows Server 2008:
  • Improved enrollment capabilities that enable delegated enrollment agents to be assigned on a per-template basis
  • Enhanced performance monitoring with the addition of new performance counters
  • Scalable, high-speed revocation status response services that combine CRLs and integrated Online Responder services
  • Support for Cryptography Next Generation (CNG) to enable the use of Suite B algorithms
  • Enhanced service monitoring with the introduction of the Windows Server 2008 Active Directory Certificate Services Management Pack for Microsoft Operations Manager 2005
  • More detailed server administration with restricted certificate managers
  • Failover cluster support
• Windows Server 2008 R2:
  • Cross-forest enrollment capability that allows for consolidation of existing hardware
  • Databaseless CA feature to avoid storing unnecessary certificate records
  • Best Practice Analyzer for improved configuration practices
  • Web-based certificate enrollment protocol to allow enrollment over the Internet

NAP and Databaseless CA implementation

As part of Windows Server 2008 deployments, Microsoft IT added a new PKI-enabled service—Network Access Protection—to its existing offerings. NAP is a technology introduced in the Windows Vista® and Windows Server 2008 operating systems; it includes client and server components that enable administrators to create and enforce health requirement policies that define the required software and system configurations for computers that connect to the corporate network. NAP enforces client health by inspecting and assessing the health of client computers, limiting network access when client computers are deemed noncompliant, and remediating noncompliant client computers for unlimited network access.

Some of the enforcement combinations include:

• NAP with IPsec enforcement*
• NAP with 802.1X enforcement
• NAP with VPN enforcement
• NAP with Dynamic Host Configuration Protocol (DHCP) enforcement
• NAP-NAC (Network Admission Control) enforcement

  *Microsoft IT implementation

A NAP implementation usually consists of the following components: NAP clients, a NAP enforcement point, and a NAP health policy server (a server that is running Network Policy Server [NPS]). Additionally, NAP with IPsec-specific enforcement requires a CA server and a Health Registration Authority (HRA) for issuing NAP health certificates to clients in order to be able to communicate on the IPsec-protected network

HRA's responsibility is to validate client credentials and forward a certificate request to the NAP CA on behalf of the client. HRA validates certificate requests by checking with the NAP policy server to determine whether the NAP client is compliant with network health requirements.

NAP certificate service requirements included the following:

• Subject name: Supply in the Request
• Application Policies): client authentication, NAP health (custom), IPsec Internet Key Exchange (IKE)
• Validity period: 72 hours with no renewal
• Enrollment access: HRA accounts only

Because the subject name was set to Supply in the Request, Microsoft IT applied name constraints to help further prevent unauthorized enrollment. The reason for establishing such a short validity period, as well as no renewal value on the HRA-only certificate template, is to enforce more frequent state checks that must pass through the HRA.

NAP templates contain the Client Auth Application Policy. For the certificates to use the Client Auth Application Policy , Microsoft IT needed to publish every NAP CA certificate in the NTAUTH container of every NAP-enforced forest.

Because of the complex enrollment logic involving evaluating various parameters on multiple enrollment requests, the NAP CAs started to exhibit much higher memory consumption compared to any other CA. Additionally, the short validity period on the NAP certificate templates triggered a significantly larger number of issued certificates. Microsoft IT determined to take the following actions to address these concerns:

• Increase the database session count on each CA (to 120). This change allowed for much larger number of requests to be processed per second.
• Increase physical memory (to 8 GB).

As a short-term solution for the overgrowing database size, Microsoft IT enabled circular logging, ran regular database clean-up scripts, and ran database defragmentation tasks to preserve available disk space.

A long-term solution is use of the Databaseless CA feature in Windows Server 2008 R2. Databaseless CA allows a CA server to not store issued certificates in its database. This feature is especially valuable for the services like NAP where there is no requirement to maintain records of issued certificates. Instead of performing database clean-up tasks after thousands of certificates have already been issued, this feature prevents the certificate from entering the Issued Certificates database altogether—after it is enabled on the CA (running Windows Server 2008 R2 Beta) and a specific template (configured via Windows Server 2008 R2 Beta or a Windows 7 client operating system).

As of this writing, Microsoft IT is upgrading all of its NAP CAs to Windows Server 2008 R2 Beta and enabling the new Databaseless CA feature on the CAs and on the templates servicing NAP clients that are running Windows Server 2008 R2 Beta or a Windows 7 client operating system.

Cross-Forest Enrollment and Server Consolidation

Perhaps one of the biggest challenges in managing a multiple-forest PKI is the necessity to mirror the original configuration to the other supported forests, due to the lack of cross-forest enrollment functionality. Such a limitation has always equated to duplicated administrative efforts as well as hardware cost. Windows Server 2008 R2 (Beta) has finally broken those boundaries.

Cross-forest enrollment now available in Windows Server 2008 R2 helps organizations consolidate their infrastructure by enabling users and computers from forests B, C, and D to enroll from a CA server in forest A. That is accomplished by copying the necessary Active Directory objects from forest A (resource forest) to forest B (account forest) and enabling referral on the Windows Server 2008 R2 Beta CA.

In March 2009, Microsoft IT began updating its infrastructure by enabling cross-forest enrollment for its internally consumed services. In preparation for this important milestone, Microsoft IT did not renew its issuing CA certificates for the services that it planned to enable for cross-forest enrollment. Microsoft IT intends to continue to maintain the CRLs for the remainder of the old CA certificates' lifetime, and will retire the CAs after those certificates expire.

Geographically Disbursed PKI

The introduction of NAP and its requirements for very short-lived certificates and reliance on almost instantaneous enrollment abilities produced the need for not only multiple CAs to ensure service availability, but also—for the first time in Microsoft IT history—to host issuing CAs in remote locations, in closer proximity to the client. As a result, Microsoft IT collaborated with its international data-center management teams and built secure locations to host NAP CAs at international data centers. Microsoft IT then negotiated special security procedures with remote teams to ensure those CAs, which were no longer physically maintained by the Microsoft IT PKI staff, remained compliant with the high security requirements for the rest of the infrastructure.

Because the remote CAs were no longer in physical care of the primary PKI staff, Microsoft IT decided to initialize the HSMs protecting those CAs into separate security worlds. This way, if those modules are compromised on the way to the remote data centers, only the security world that they are part of will be affected, and no harm will be done to the other CAs.

Due to the introduction of the previously mentioned services to the Microsoft environment, Microsoft IT needed to include additional CAs and make other changes to its hierarchy. Figure 3 shows the revised Microsoft IT PKI hierarchy.

Figure 3. Primary Microsoft IT PKI

Figure 4 shows the infrastructure of the third-party root.

Figure 4. Existing third-party root infrastructure

CA Server Management and Support

Microsoft IT's current PKI support model includes four tiers:

• Tier 1: Microsoft Service Desk (multiple members). All user enquires originate at this tier. Technician asks users a series of questions to help direct them to the appropriate team.
• Tier 2: Microsoft Global Operations team (multiple members). The Global Operations team receives escalations from the Service Desk, or sometimes from other infrastructure support teams if an issue has already been identified. This team also receives and responds to all PKI monitoring alerts. A Global Operations analyst then begins investigation and follows support articles prepared by the Microsoft IT PKI team. Even though Global Operations staff members have been provisioned with CA access, they are not PKI experts; if they receive a request that requires more in-depth knowledge of Certificate Services/AD CS, they forward the request to Tier 3 in the support model.
• Tier 3: Certificate Services Operations team (four members). This team manages certificate enrollment, revocation, and recovery of Microsoft IT issued certificates. It also provides assistance with troubleshooting of specific PKI usage scenarios.
• Tier 4: Certificate Services Engineering team (two members). This team manages the deployment of new cryptographic solutions, identifies shortfalls in the current infrastructure, and proposes and deploys new design changes. It also receives escalation requests from Tier 3 and helps resolve operational issues. In the case of an overly complex case or a potential software bug, the team involves the PKI product group, and then both teams work together to find and document a solution.

Backup

Microsoft IT regularly backs up its online and offline CAs. Online CAs are backed up on a daily basis via an automated solution that copies the CA database, registry configuration, and nCipher key protection–related files to a remote location, which is then backed up and stored to tape. Microsoft IT decided to employ such backup practices to preserve the limited CA server access. This way, multiple members of the backup organization are not required to have access to the CA servers themselves; they only need to be able to access the remote location that contains the specific files necessary for backup.

Microsoft IT backs up its offline CAs every time after signing a new subordinate CA certificate request. CA database, registry information, and nCipher key protection–related files are all copied to two copies of CDs, which are then stored at two separate, secure off-site locations.

In the event of a corrupted CA, the backed-up data can be used to successfully restore the services onto a different piece of hardware with a properly configured nCipher module.

Monitoring

Service monitoring is critical to production operations. Microsoft IT relies on a combination of Microsoft Operations Manager and a custom Certificate Services/AD CS monitoring tool to oversee the health of its PKI.

A Microsoft Operations Manager implementation consists of a monitoring server, health agents, and a set of management packs, each specific to a particular area being monitored. Microsoft IT deployed monitoring agents to every CA in its managed environment. The agents run and perform the checks enforced by each management pack, and then report to the management server. From there, an automatic ticketing system generates support tickets and forwards those to the Global Operations group.

The custom Certificate Services/AD CS monitoring tool runs on every CA as well; its job is to perform Certificate Services/AD CS-specific checks, including verifying that the service is running, the CRL publication occurred on time, the CA certificate is not nearing its expiration date, and all AIA and CRL distribution point paths contain the expected data. If the tool identifies any discrepancies, it generates and forwards an alert to the Global Operations team's Microsoft Operations Manager console with the help of the Microsoft Operations Manager agent.

Both the Microsoft Operations Manager agent account and the service account used by the custom monitoring tool run with limited permissions on the CAs and have only read and write access to the CAs' Application Event log, for the purpose of logging the event. This helps prevent a potential attack on the server if either of those accounts is compromised.

Software Updates

To make sure that the CA servers are up to date on all software updates, including fixes and security updates, Microsoft IT uses Microsoft System Center Configuration Manager 2007(MSCCM)).

MSCCM includes a server and an agent component, where the agent runs on every CA and applies a set of updates based on the information it gets from the MSCCM server. To minimize impact to production operations, the agents are configured to only execute the updates restart the server (if necessary) during off hours. The entire process is automated, which helps avoid a potential administrative overhead.

Hardware Upgrades

Microsoft IT follows the same hardware refresh schedule that is followed by the rest of the departments within the company, which includes upgrading the hardware components every three years. When a hardware upgrade is necessary, the Microsoft PKI team backs up the current server, takes it offline, and then restores the backup on the newly built server.

Upcoming Initiatives

With so many new and exciting features being introduced to PKI-based technologies today, here are some key areas that Microsoft IT will focus on next:

• Microsoft Forefront™ Identity Manager Certificate Management (FIMCM). The CM feature of Forefront Identity Manager is a centralized management system for deploying and managing certificates and smart cards. Microsoft IT is currently engaged in an early production deployment of CM, and plans to integrate all smart-card logon and S/MIME certificates into CM within the next year.
• Additional cross-forest enrollment and hardware consolidation efforts. Microsoft IT is working aggressively toward consolidating its existing infrastructure. During the consolidation process, the team is also re-evaluating the overall design and is considering making additional changes to the infrastructure, such as moving all services that involve archived keys to a shared set of CAs for simplified management and administration.
• Virtualization. With today's efforts to minimize overall infrastructure management costs, virtual server–based services are driving many deployment goals. The Microsoft PKI team is considering moving most (if not all) of its PKI servers to virtual machine–based infrastructure. As part of the initiative, network-based HSMs would become the primary key storage mechanisms
• Certificate Services Management Pack. The Windows Server 2008 Active Directory Certificate Services Management Pack for Microsoft Operations Manager 2005 provides a predefined set of processing rules and guidance designed specifically for monitoring the performance and availability of the AD CS role services, including the Certification Authority, Online Responder, and Network Device Enrollment services. Microsoft IT has already begun using the new AD CS performance counters available in Windows Server 2008 for enhanced performance monitoring, and is now considering evaluating the complete new monitoring solution in its production environment.
• Following key management standards—migrating from 1,024-bit RSA keys. The U.S. National Institute of Standards and Technology issued NIST Special Publication 800-57, Recommendation for Key Management, which advises that 1024-bit RSA keys will no longer be viable after December 31, 2010. Microsoft IT is currently working on identifying all dependencies in addition to the migration steps.

For more information about the key migration standards, refer to the publication at http://csrc.nist.gov/publications/drafts/800-57-part3/Draft_SP800-57-Part3_Recommendationforkeymanagement.pdf.

Lessons Learned and Best Practices

By thoroughly evaluating detailed service requirements and future growth potential, Microsoft IT learned several valuable lessons that can be applied as best practices in most other PKI deployment plans. Microsoft IT learned many of the lessons during the deployment and some of the lessons as outcomes of the deployment.

Plan for Future Upgrades to the Windows Server PKI

If upgrading from Windows Server 2000 Server to obtain all the benefits associated with the Windows Server 2003 or Windows Server 2008 PKI, the Active Directory schema must be extended at least to the version provided with Windows Server 2003. Additionally, client computers should be running Windows XP Professional or Windows Vista.

The first step in preparing for the upgrade is to plan for the schema extension. An organization must run Adprep.exe with the /ForestPrep command-line switch to extend the schema before any other work commences.

Carefully Consider the Number of CA Servers Needed

An organization should be realistic about the number of CAs that it needs to deploy. When an organization uses Windows Server 2003 Certificate Services, it does not need to create separate CAs for different applications. Each CA can issue all the certificates that are in use in that forest.

Microsoft IT realized that the number of CAs deployed in the original plans created unnecessary administrative complications and overhead. Decommissioning some underused CAs and consolidating their certificate templates to other CAs proved to have no effect on performance, but yielded significant savings in server hardware and ongoing maintenance. In situations where enrollment services are critical, Microsoft IT employs multiple CAs, configured identically, to provide failover redundancy.

Consider Integration with a Public Root

An organization should consider how it will address the issue of root trust for public-facing PKI-enabled services. Implementing only a self-signed root CA will not provide root trust for users outside the bounds of a network environment. Depending on an organization's needs and the scope of its deployment, there are two primary ways that an organization can address this problem: It can either purchase individual certificates as needed or subordinate its own CA under a publicly trusted root.

Microsoft IT implemented a new offline intermediate CA that chains to the publicly trusted GTE CyberTrust Root and GTE CyberTrust Global Root. The offline intermediate CA subordinates multiple issuing CAs, which can issue both SSL and S/MIME certificates. Purchasing the necessary SSL certificates through a third party represented a significant cost for Microsoft. With the use of the new, publicly trusted infrastructure, Microsoft IT's internal PKI realizes significant savings. Microsoft IT pays an annual fee for subordination to a publicly trusted root and can issue an unlimited number of certificates, rather than paying for each certificate issued. Additionally, Microsoft increased its control over the certificate issuance process by handling the issuance of all end-entity certificates internally.

Automate CRL Publication

The availability of valid CRLs is crucial for uninterrupted operation by PKI-enabled services and applications. Automating CRL publication to external locations can be challenging because most enterprises do not connect their public-facing Web servers directly to corporate network resources. There are typically firewalls and perimeter networks that isolate publicly accessed servers from other servers.

Windows Server 2003 CAs can be configured to automatically write new CRL files to shares on other servers, whereas Windows 2000 Server requires separate procedures to perform this function. This improvement enabled Microsoft IT to reduce its external CRL publication intervals from once a week to once every 24 hours for such time-sensitive certificates as those used for smart-card remote access logons. Microsoft IT CAs now write their CRL material directly to a specific drop point. A periodic synchronization routine automatically runs, accesses the data on the drop point, and makes the data available on the externally facing Web servers in a timely manner.

Customize the CRL Publication Overlap Interval

The overlap between the time when a new CRL is issued and the time when an old CRL expires needs to be managed. With CRL publication in Active Directory, replication time must be considered. Microsoft IT needed to provide sufficient time for replication of the newly published CRL before the old CRL expired and would no longer be valid for certificate validation purposes. Additionally, with external HTTP URLs, Microsoft IT needed enough time to provide for manual publication of newly issued CRLs to these points.

For detailed information about defining CRL publication overlap, refer to the white paper "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx.

Use New Keys for CA Renewal

Microsoft IT recommends renewing CA certificates by using new keys rather than reusing the old keys. Using new keys for CA renewal reduces the likelihood of having any ambiguous or improper certificate chains in the hierarchy.

Using existing keys for certificate renewal may cause certificate chains to link to either the old or the new CA certificate, creating ambiguous certificate chains. However, if an organization uses a new key during CA certificate renewal, the certificate chains down the line will use only the new key, thereby eliminating any ambiguity.

Using a new key does not break the chains created for end-entity certificates issued under the old CA certificate. Previously issued certificates will continue to chain to the appropriate CA certificate. However, multiple keys require multiple CRLs. During revocation checking, a CRL must be signed by the same key used to sign the end-entity certificate. As a result of using new keys for CA renewal, the CA must issue a CRL for each valid key to help ensure the validity of the certificates issued. Because of the importance of CRL availability in successfully managing the issuance of new keys for CA renewal, an organization should plan its CRL propagation strategy carefully.

Multiple CRL files and CA certificate files are typically differentiated through the addition of a key version suffix to the file name. For this reason, Microsoft IT recommends using the appropriate variable when defining CRL distribution point and AIA extensions.

Plan for Certificate Issuance Policies

The Windows Server 2003 or Windows Server 2008 PKI includes certificate policies and application policies (EKU in Windows 2000 Server). Each type of policy has its own unique object identifier (OID) values. These OID values are written into corresponding extensions within the certificate. For a certificate to be valid for any specific purpose, the appropriate OID for that purpose must be present within the appropriate policy extension. For example, for an end-entity certificate to be valid for EFS usage, the EFS OID value must be present in the application policy extension for every certificate in the chain.

By default, a root CA certificate is valid for all application policies and all certificate policies. However, by default, subordinate CAs are valid only for all application policies. By using the value of "all" for these policies, every application or issuance policy OID, whether recognized or not, is considered valid. However, specifying any individual policy OID overrides the "all" value. When the "all" value is overridden, a particular policy must be explicitly defined in the policy to be considered valid.

Initially, Microsoft IT did not anticipate using issuance policies. Shortly after the initial deployment process, Microsoft IT planned to include an issuer statement in the root certificate. This statement included a space within the certificate for embedding legal disclaimers or other items of reference, and it included a hyperlink to the Microsoft Certification Practice Statement CPS. The CA interpreted the inclusion of the issuer statement as an issuance policy, which thereby invalidated all other possible issuance policies. Initially, this situation was not a problem. However, when Microsoft IT decided to accommodate the potential use of issuance polices in its issuing CAs, it attempted to renew the intermediate certificates and include the All Issuance Policies value within them as well. Because the All Issuance Policies value had been overridden in the root certificate with the inclusion of the issuance statement, the effective issuance policies in the intermediate CA certificates were then restricted to only the issuance statement policy.

To re-enable the All Issuance Policies functionality, Microsoft IT had to renew the root certificate. To provide this functionality, in addition to the desired issuer statement, Microsoft IT needed to modify the Capolicy.inf file to include the specific All Issuance Policies OID along with the appropriate information for the issuer statement. Microsoft IT then repeated this configuration by renewing each of the offline intermediate CAs to match the "all" functionality of the root. The online enterprise subordinate CAs, however, have no issuance policies defined, thus limiting the use of any issuance policies in certificates that they issue. If ever required in the future, Microsoft IT can easily implement needed policies by simply renewing the issuing CA certificate and including the policies.

Microsoft IT recommends that all deployments of PKI that incorporate the use of subordinate CAs should plan for the use of issuance policies. Planning for issuance policies forces the consideration of which specific enhanced key usage and issuance policies an organization will enable when it deploys a CA. Alternatively, security administrators can change the default settings for issuance policies on the subordinate CAs to match the root. In either case, consideration of this factor at the planning stage of a deployment will eliminate the need to renew the certificate chain from the root down every time an organization needs a new enhanced key usage or issuance policy.

For more information about setting policies in the Capolicy.inf file, refer to the white paper "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx.

Sanitize Elements of the PKI

Microsoft IT discovered that issued certificates may contain potentially sensitive information about the Microsoft infrastructure. By default, LDAP paths explicitly defining the Microsoft Active Directory structure were stored in the CRL distribution point and AIA extensions. Microsoft IT chose to remove this information from its CA and end-entity certificates for reasons of corporate confidentiality.

Enterprises concerned with the security of their Active Directory structures should plan to sanitize their certificates of any corporate confidential information that they do not want released externally. An organization should include contact information in the certificates only if it wants users to be able to use those channels for support. The publication of internal e-mail addresses on the Internet can lead to customer replies and unwanted e-mail. Official contact information is more appropriately placed in an organization's publicly released CPS documentation.

Ensure Service Availability for High-Demand Applications

Carefully examine the requirements of each PKI-enabled service, including the frequency at which the certificates must be issued, the number of such requests, and the potential impact to the service if redundancy and appropriate availability are not accounted for. An organization should configure its CAs with enough memory to process all requests and to enable the newly available features (such as Databaseless CA feature) to prevent the servers from running out of disk space.

Conclusion

By designing, implementing, and supporting a PKI that uses a self-signed root CA certificate for internal security needs and a separate PKI chained to a public root for enabling public-facing SSL and S/MIME requirements, Microsoft IT accomplished its goals for the Microsoft PKI implementation. Business benefits can be summarized as follows:

• Increased security. Microsoft employees use cryptographic technologies and applications each day. The remote access logon to the corporate network is accomplished through smart cards. The ability to use S/MIME when exchanging e-mail helps give senders, by means of encryption, confidence that no one other than the intended recipient can read messages. The ability to use S/MIME helps give recipients, by means of digital signatures, confidence that the contents of messages have not been altered. With the use of SSL, users of intranet and Internet Web sites can exchange sensitive data through an encrypted connection.
• Application and service compatibility. Deploying a self-hosted Microsoft PKI enables Microsoft teams to test each new Microsoft product for compatibility and interoperability with Windows 2000 Server, Windows Server 2003, and Windows Server 2008 PKI services before it is released to the market.
• Reduced certificate costs. Before the current infrastructure, the costs of using a third-party public CA for certificate delivery on a certificate-by-certificate basis were high. Running an internal PKI at Microsoft has reduced these costs. In addition, the new PKI model has reduced the required support infrastructure by enabling the consolidation of CA servers in each forest.
• Ease of manageability. Because Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 offer PKI capability out of the box, a self-hosted PKI solution was easy to implement and is easy to manage.
• Conformance to industry standards. Implementing an enterprise PKI enables Microsoft IT to use standards-based cryptographic technologies to help secure Microsoft corporate resources. These technologies include encrypted files, folders, wireless communications, e-mail, remote network access, and Web server connections.
• Reduced overall infrastructure management cost. By enabling cross-forest enrollment and consolidating physical hardware, companies can cut significant costs associated with the management of multiple CAs scattered across multiple forests.

For More Information

For more information about PKI, refer to the following sources.

• White papers:
  • "Key Archival and Management in Windows Server 2003"
    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx
  • "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure"
    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx
• Web sites:
  • Microsoft Public Key Infrastructure for Windows Server 2003 Technology Center
    http://www.microsoft.com/windowsserver2003/technologies/pki/default.mspx
  • Federal Information Processing Standards
    http://csrc.nist.gov/publications/fips/
  • National Institute of Standards and Technology Federal PKI
    http://csrc.nist.gov/pki/
  • Windows Server 2003 Security Services Technology Center
    http://www.microsoft.com/windowsserver2003/technologies/security/

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Forefront, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.