C H A P T E R 1 6 Designing a Public Key Infrastructure Microsoft® Windows® Server 2003 enables a variety of secure applications and business scenarios based on the use of digital certificates. Before you can use digital certificates, however, you need to design a public key infrastructure (PKI), which involves planning configuration options for one or more certification authorities, preparing certificates to meet the needs of your organization, and creating a PKI management plan. In This Chapter Overview of the PKI Design Process ............................................................................................... 730 Defining Certificate Requirements ................................................................................................. 735 Designing Your CA Infrastructure .................................................................................................... 746 Extending Your CA Infrastructure .................................................................................................... 776 Defining Certificate Configuration Options .................................................................................... 788 Creating a Certificate Management Plan ...................................................................................... 810 Deploying the PKI .............................................................................................................................. 830 Additional Resources ........................................................................................................................ 842 Related Information For more information about Windows Server 2003 public key features, see the Distributed Services Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). For more information about using certificates in conjunction with Encrypting File System, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). For more information about deploying smart cards, see ―Planning a Smart Card Deployment‖ in this book. 730 Chapter 16 Designing a Public Key Infrastructure Overview of the PKI Design Process Organizations use a variety of technology solutions to enable essential business processes, such as online ordering, exchanges of contracts, and remote access. A public key infrastructure based on Microsoft Windows Server 2003 Certificate Services provides a means by which organizations can secure these critical internal and external processes. Deploying a PKI allows you to perform tasks such as: Digitally signing files such as documents and applications. Securing e-mail from unintended viewers. Enabling secure connections between computers, even if they are connected over the public Internet or through a wireless network. Enhancing user authentication through the use of smart cards. If your organization does not currently have a public key infrastructure, begin the process of designing a new public key infrastructure by identifying the certificate requirements for your organization. If your organization already uses a public key infrastructure based on Microsoft ® Windows NT® version 4.0, Microsoft® Windows® 2000, or third-party certificate services, you can improve your PKI capabilities by taking advantage of new and enhanced features in Microsoft ® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; and Windows® Server 2003, Datacenter Edition. When you have completed the PKI design process, you can deploy a public key infrastructure that provides solutions for all of your internal security requirements, as well as security requirements for business exchanges with external customers or business partners. Note For a list of the job aids that are available to assist you with the PKI design process, see ―Additional Resources― later in this chapter. Overview of the PKI Design Process 731 Process for Designing a PKI Designing a PKI for your organization involves defining your certificate requirements, creating a design for your infrastructure, creating a certificate management plan, and deploying your PKI solution. Figure 15.1 shows the steps that are involved in designing a public key infrastructure. Figure 15.1 Designing a PKI Note The steps involved in designing a PKI are interdependent. For example, defining certificate server configurations, locations, and roles has a significant impact on how you address key certificate management issues. Your evolving certificate management standards in turn have significant implications for the certificate server roles, locations, and configurations that you develop. 732 Chapter 16 Designing a Public Key Infrastructure Basic PKI Concepts Public key infrastructure is the term used to describe the laws, policies, procedures, standards, and software that regulate or control the operation of certificates and public and private keys. More specifically, a PKI is a system of digital certificates, certification authorities, and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction. A PKI consists of the following basic components: Digital certificates Electronic credentials, consisting of public keys, which are used to sign and encrypt data. Digital certificates provide the foundation of a PKI. One or more certification authorities (CAs) Trusted entities or services that issue digital certificates. When multiple CAs are used, they are typically arranged in a carefully prescribed order and perform specialized tasks, such as issuing certificates to subordinate CAs or issuing certificates to users. Certificate policy and practice statements The two documents that outline how the CA and its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the trust is broken, and so on. Certificate repositories A directory service or other location where certificates are stored and published. In a Windows Server 2003 domain environment, the Active Directory® directory service is the most likely publication point for certificates issued by Windows Server 2003–based CAs. Certificate revocation lists (CRL) Lists of certificates that have been revoked before reaching the scheduled expiration date. Note With Certificate Services in Windows Server 2003, Microsoft introduces a new type of certificate revocation list called a delta CRL, which allows you to publish information about recently revoked certificates more frequently without using the bandwidth required for publishing full CRLs. Certificate trust lists These are signed lists, which are located on the client, of trusted CA certificates. Certificate trust means that a certificate is part of a certificate trust list (CTL) or that the CTL contains a trusted certificate from another CA that is part of the certificate’s certificate chain. Windows Server 2003 domain administrators can use Group Policy objects (GPOs) to publish and maintain CTLs. Overview of the PKI Design Process 733 Key archival and recovery A feature that makes it possible to archive and recover the private key portion of a public-private key pair, in the event that a user loses his or her private keys, or an administrator needs to assume the role of a user for data access or data recovery. Private key recovery does not recover any data or messages; it merely enables the recovery process. Public key standards Standards developed to describe the syntax for digital signing and encrypting of messages and to ensure that a user has an appropriate private key. To maximize interoperability with third-party applications that use public key technology, the Windows Server 2003 PKI is based on the standards recommended by the Public-Key Infrastructure (X.509) (PKIX) working group of the Internet Engineering Task Force (IETF). Other standards that the IETF has recommended also have a significant impact on public key infrastructure interoperability, including standards for Transport Layer Security (TLS), Secure/Multipurpose Internet Mail Extensions (S/MIME), and Internet Protocol security (IPSec). Windows Server 2003 PKI You can use PKI-based applications on workstations and servers running Microsoft ® Windows® XP Professional, Windows Server 2003, Windows® 2000, or Windows NT 4.0, as well as on workstations running Microsoft® Windows® 95 and Microsoft® Windows® 98. The ability to create and manage a PKI is available in Microsoft® Windows NT® 4.0 Server, Microsoft® Windows® 2000 Server, and Windows Server 2003. However, Windows Server 2003 provides more extensive support for a PKI. In addition, a growing number of applications and system services that require the secure transfer of information also rely on the Windows Server 2003 PKI. Applications that are enabled for certificate-based security include Microsoft® Outlook®, Internet Explorer®, Internet Information Services, Microsoft® Exchange Server, Microsoft® Commerce Server 2000 and Commerce Server 2002, Outlook Express, and Microsoft® SQL Server™. A number of third-party applications also take advantage of the Windows Server 2003 PKI. How a Public Key Infrastructure Works A Windows Server 2003 PKI makes it possible for an organization to do the following: Publish certificates. The PKI administrator makes certificate templates available to clients (users, services, applications, and computers) and enables additional CAs to issue certificates. Enroll clients. To participate in a PKI, users, services, or computers must request and receive certificates from an issuing CA or a Registration Authority (RA). Typically, enrollment is initiated when a requester provides unique information and a newly generated public key. The CA administrator or enrollment agent uses the information provided to authenticate the identity of the requester before issuing a certificate. 734 Chapter 16 Designing a Public Key Infrastructure Use certificates. Clients use their certificates, which are validated or invalidated in a timely manner as long as CAs and certificate revocation lists are available to verify or deny their authenticity. If they are validated, a PKI provides an easy way for users to use keys in conjunction with applications that perform public key cryptographic operations, making it possible to provide security for e-mail, e-commerce, and networks. Renew or revoke certificates. A well-designed PKI makes it easy for you to renew or revoke existing certificates, and to manage the trust level associated with certificates used by different clients or for different applications. The status of a public key certificate is determined by means of the chain building process. Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. Figure 15.2 shows a certification path in a two-level CA hierarchy. Figure 15.2 Certification Path in a Two-Level CA Hierarchy In this example, the issuing CA issued the User certificate, and the root CA issued the certificate of the issuing CA. This is considered a trusted chain, because it terminates with a root CA certificate that has been designed and implemented to meet the highest degree of trust. The chain building process validates the certification path by checking each certificate in the certification path from the end certificate to the certificate of the root CA. If the CryptoAPI discovers a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is either considered invalid or is given less weight than a fully validated certificate. For more information about how PKIs function, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). Defining Certificate Requirements 735 Defining Certificate Requirements You can use a Windows Server 2003 public key infrastructure to provide a wide range of strong, scalable, cryptography-based solutions for network and information security. The value of the information that you want to protect, as well as the costs involved with implementing a strong security system, impact the level of security that you choose for your organization. Figure 15.3 shows the steps that are involved in determining your certificate requirements. Figure 15.3 Defining Certificate Requirements 736 Chapter 16 Designing a Public Key Infrastructure Determining Secure Application Requirements Before you begin to design your public key infrastructure and configure certificate services, you need to define the security needs of your organization. For example, does your organization require electronic purchasing, secure e-mail, secure connections for roaming users, or digital signing of files? If so, you need to configure CAs to issue and manage certificates for each of these business solutions. A Windows Server 2003 PKI can support the following security applications: Digital signatures Secure e-mail Software code signing Internet authentication IP security Smart card logon Encrypting file system user and recovery certificates 802.1x authentication Digital Signatures A digital signature is a means for originators of a message, file, or other digitally encoded information to bind their identities to the data. This can be extremely useful for important documents such as legal opinions and contracts. The process of digitally signing information involves transforming the information, together with some secret information held by the sender, into a tag called a signature. Digital signatures are used in public key environments to help secure electronic commerce transactions by providing verification that the individual sending the message is who he or she claims to be, and by confirming that the message received is identical to the message sent. You can use digital signatures even when data is distributed in plaintext, such as with e-mail. In this case, while the sensitivity of the message itself does not warrant encryption, it can be important as a means to ensure that the data is in its original form and has not been sent by an impostor. One way that your organization can capitalize on the use of digital signatures is by using CAPICOM. CAPICOM is an ActiveX control that provides a COM interface to Microsoft CryptoAPI. It exposes a select set of CryptoAPI functions to enable application developers to incorporate digital signing and encryption functionality into their applications. Because CAPICOM uses COM, application developers can access this functionality in a number of programming environments, such as Microsoft ® Visual Basic®, Microsoft® Visual Basic® Scripting Edition, Active Server Pages, Microsoft® JScript®, C++, and others. CAPICOM is packaged as an ActiveX control, allowing Web developers to use it in Web-based applications as well. Defining Certificate Requirements 737 You can use CAPICOM for: Digitally signing data with a smart card or software key. Verifying digitally signed data. Displaying certificate information. Inspecting certificate properties such as subject name or expiration date. Adding and removing certificates from the certificate stores. Encrypting and decrypting data with a password. Encrypting and decrypting data by means of public keys and certificates. Secure E-mail Standard Internet mail is sent as plaintext over open networks with no security. In the increasingly interconnected network environments of today, intruders can monitor mail servers and network traffic to obtain proprietary or sensitive information. You also risk exposure of proprietary and confidential business information when you send mail over the Internet from within your organization. Another form of intrusion is impersonation. On IP networks, anyone can impersonate mail senders by using readily available tools to counterfeit the originating IP address and mail headers. When you use standard Internet mail, you can never be sure who really sent a message or whether the contents of the message are valid. Moreover, malicious attackers can use mail to cause harm to the recipient computers and networks (for example, by sending attachments that contain viruses). For these reasons, many organizations have placed a high priority on implementing secure mail services that provide confidential communication, data integrity, and non-repudiation. A Windows Server 2003 public key infrastructure allows you to enhance e-mail security by using certificates to prove the identity of the sender, the point of origin of the mail, and the authenticity of the message. It also makes it possible to encrypt mail. To provide message authentication, data integrity, and non-repudiation, secure mail clients can sign messages with the private key of the sender before sending the messages. The recipients then use the public key of the sender to verify the message by checking the digital signature. S/MIME clients that run on any platform or operating system can exchange secure mail because all cryptographic functions are performed on the clients, not on the servers. 738 Chapter 16 Designing a Public Key Infrastructure Software Code Signing A growing number of applications, ActiveX® controls, and Java applets are being downloaded and installed on computers with little or no user notification. In response to this problem, Microsoft introduced Authenticode™ digital signature technology in 1996, and in 1997 added significant enhancements to this technology. Authenticode technology allows software publishers to digitally sign any form of active content, including multiple-file archives. These signatures can be used to verify both the publishers of the content and the content integrity at time of download. Many software vendors already sign their applications and you can use these signatures to manage the software applications used on your network. Authenticode relies on a certification authority structure in which a small number of commercial CAs issue software-publishing certificates. If you want to expand the use of software-publishing certificates in your own organization, the Windows 2000 and Windows Server 2003 PKI allows you to issue your own Authenticode certificates to internal developers or contractors and allows any employee to verify the origin and integrity of downloaded applications. Internet Authentication The Internet has become a key element in the growth of electronic commerce. However, for many users, security considerations impact how much and what kind of information they are willing to share across the Internet. The major concerns are: Confidentiality. Data that is transferred between clients and servers needs to be encrypted to prevent its exposure over public Internet links. Server authentication. Clients need a way to verify the identity of the servers they are communicating with. Client authentication. Servers need a way to verify the identity of clients. Client authentication of the server takes place when the client verifies the cryptographic signatures on the certificate of the server, and any intermediate CA certificates, to a root CA certificate located in the trusted root store on the client. Server authentication of the client is accomplished when the server verifies the cryptographic signatures on the certificate of the client, and any intermediate CA certificates, to a root CA installed in the trusted root store on the server. When the identity of the client is verified, the server can establish a security context to determine what resources the client is allowed or not allowed to use on the server. Defining Certificate Requirements 739 IP Security Windows 2000 and Windows Server 2003 incorporate Internet Protocol security (IPSec) to protect data moving across the network. IPSec is a suite of protocols that allows encrypted and digitally signed communication between two computers or between a computer and a router over an insecure network. The encryption is applied at the IP network layer, which means that it is transparent to most applications that use specific protocols for network communication. IPSec provides end-to-end security, meaning that the IP packets are encrypted or signed by the sending entity, are unreadable en route, and can be decrypted only by the recipient entity. Due to a special algorithm for generating the same shared encryption key at both ends of the connection, the key does not need to be passed over the network. You do not need to use public key technology to use IPSec; instead you can use the Kerberos version 5 authentication protocol or shared secret keys that are communicated securely by means of an out-of-band mechanism at the network end points for encryption. However, if you use public key technology in conjunction with IPSec, you can create a scalable distributed trust architecture in which IPSec devices can mutually authenticate each other and agree upon encryption keys without relying on prearranged shared secrets, either out-of-band or in-band. This, in turn, yields a higher level of security than IPSec without a PKI. For more information about deploying IPSec solutions, see ―Deploying IP Security‖ in Deploying Network Services of this kit. Smart Card Logon Smart card logon is integrated with the Kerberos version 5 authentication protocol implemented in Windows Server 2003. When smart card logon is enabled, the system recognizes a smart-card insertion event as an alternative to the standard Ctrl + Alt + Del secure attention sequence to initiate a logon. The user is then prompted for the smart card PIN code, which controls access to operations performed by using the private key stored on the smart card. In this system, the smart card also contains a copy of the certificate of the user (issued by an enterprise CA). This allows the user to roam within the domain. Smart cards enhance the security of your organization by allowing you to store extremely strong credentials in an easy-to-use form. Requiring a physical smart card for authentication virtually eliminates the potential for spoofing the identities of your users across a network. In addition, you can also use smart card applications in conjunction with virtual private networks and certificate mapping, and in e-commerce. For many organizations, the potential to use smart cards for logon is one of the most compelling reasons for implementing a public key infrastructure. For more information about deploying smart cards, see ―Deploying Smart Cards‖ in this book. 740 Chapter 16 Designing a Public Key Infrastructure Encrypting File System Use and Recovery The Windows Server 2003 Encrypting File System (EFS) allows users and services to encrypt their data to prevent others who authenticate to the system from viewing the information. However, EFS also provides for data recovery if another means is needed to access this data — for example, if the user who encrypted the data leaves the organization, or if the original encryption key is lost. To support this requirement, EFS allows recovery agents to configure public keys that are used to enable file recovery. The recovery key only makes available the randomly generated file encryption key, not a private key of the user. This ensures that no other private information is accidentally revealed to the recovery agent. Note You do not need to have a public key infrastructure to use Windows Server 2003 Encrypting File System. However, the use of public keys improves the manageability of EFS. In a Windows domain environment, it is recommended that EFS be used in conjunction with a PKI. For more information about EFS, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). Wireless (802.1x) Authentication A growing number of organizations and facilities such as airports and hotels are implementing wireless network access. This creates the challenge of ensuring that: Only authenticated users can access the wireless network. Data transmitted across the wireless network cannot be intercepted. Public key infrastructures, in conjunction with the IEEE 802.1x standard for port-based network access control, support both of these goals by providing centralized user identification, authentication, dynamic key management, and accounting to provide authenticated network access to 802.11 wireless networks and to wired Ethernet networks. For more information about deploying a wireless network, see ―Deploying a Wireless LAN‖ in this book. Defining Certificate Requirements 741 Determining Certificate Requirements for Users, Computers, and Services After you have identified the security technologies that you need to implement to meet the business needs of your organization, you need to identify the categories of users, computers, and services that will use these technologies and for which you need to provide certificate services. For example, certificate use might be based on job function, location, organizational structure, or a combination of these three, or all computers or users in the organization might use certain certificate applications. For each of the groups that you have identified, you need to determine: The types of certificates to be issued. This is based on the security application requirements of your organization and the design of your PKI infrastructure. The number of users, computers, and applications that need certificates. This number can include as few as one or as many users, computers, or applications as are in an entire organization. The physical location of the users, computers, and applications that need certificates. Different certificate solutions might be required for users in remote offices or for users who travel frequently than are required for users in the headquarters office of an organization. Also, requirements can differ based on geography. For example, you might want to restrict users in one country/region from using their certificates to access data in an organizational business unit in another country/region. The level of security that is required to support the users, computers, and applications that need certificates. Users who work with sensitive information typically require higher levels of security than other members of the organization. The number of certificates required for each user, computer, and application. In some cases, one certificate can meet all requirements. Other times, you need multiple certificates to enable specific applications and meet specific security requirements. The enrollment requirements for each certificate that you plan to issue. For example, do users have to present one or more pieces of physical identification, such as a driver’s license, or can they simply request a certificate electronically? Note For a worksheet to assist you in identifying user certificate requirements, see ―Summary of User Certificate Requirements‖ (DSSPKI_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Summary of User Certificate Requirements‖ on the Web at http://www.microsoft.com/reskit). 742 Chapter 16 Designing a Public Key Infrastructure Documenting Certificate Policies and Practices Designing a public key infrastructure involves configuring certificates and certification authorities, developing support procedures, and establishing a system of checks and balances for administrative authority. Only by effectively addressing both the technical and administrative issues related to your public key infrastructure can you ensure that your certificate services provide the level of security that your organization requires It is helpful to record the decisions that you make as you design your PKI by creating certificate policy statements and certificate practice statements. These documents assist you in planning and in communicating with individuals and businesses outside your organization. For many organizations and certificate uses, certificate policy statements and certificate practice statements are considered legal documents or legal disclaimers. In general, the IT department is responsible for setting and maintaining PKI policies and practices. However, because of the legal, financial, and tactical uses of PKIs, representatives from outside the IT department, such as human resources, finance, legal, and marketing, might also be involved in establishing certificate policies. A certificate policy is a set of rules that indicates the applicability of a certificate to a particular group of clients or applications that have common security requirements. Certificate policy statements generally include the following types of information: How users are authenticated to the CA. Legal issues, such as liability, that might arise if the CA is either compromised or used for something other than its intended purpose. The intended purpose of the certificate. Private key management requirements, such as storage on smart cards or other hardware devices. Whether the private key can be exported or archived Requirements for users of the certificates, including what users must do in the event that their private keys are lost or compromised. Requirements for certificate enrollment and renewal. Minimum length for the public key and private key pairs. Important You can implement many of the decisions that you document in your certificate policy statements by creating a CAPolicy.inf file and copying it to the system directory of the CA before the CA is installed or renewed. For more information about CAPolicy.inf file contents and configuration, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). Defining Certificate Requirements 743 A certificate practice statement is a statement of the practices that IT uses to manage the certificates that it issues. It describes how the certificate policy of the organization is interpreted in the context of the system architecture of the organization and its operating procedures. The IT department is responsible for preparing and maintaining the certificate practice statement. A certificate practice statement usually includes the following types of information: Positive identification of the CA (including CA name, server name, and DNS address). The certificate policies that are implemented by the CA and the certificate types that are issued. The policies, procedures, and processes for issuing, renewing, and recovering certificates. Cryptographic algorithms, cryptographic service providers (CSPs), and key length used for the CA certificate. Physical, network, and procedural security for the CA. The certificate lifetime of each certificate issued by the CA. Policies for revoking certificates, including conditions for certificate revocation, such as employee termination and misuse of user rights. Policies for CRLs, including where to locate CRL distribution points and how often CRLs are published. A policy for renewing the certificate of the CA before its expiration. It is best to create a certificate practice statement for each CA in your public key infrastructure. The certificate practice statement associated with a CA can incorporate multiple certificate policies. Also, to consolidate information, the certificate practice statement for a subordinate CA can reference common or general information in the certificate practice statement of a parent CA. For an outline to assist you in creating a certificate practice statement, see ―Certificate Practice Statement Outline‖ (DSSPKI_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Certificate Practice Statement Outline‖ on the Web at http://www.microsoft.com/reskit). Important In some situations, such as when digital signatures are used on binding contracts, the certificate practice statement can also be considered a legal statement about the level of security that is provided and the safeguards that are being used to establish and maintain the security level. 744 Chapter 16 Designing a Public Key Infrastructure Example: Defining Certificate Requirements An organization decides to implement a public key infrastructure because a number of business units within the organization are using certificate services independently. The business units use similar infrastructures that include many of the same components — such as CAs and certificate templates — and have similar goals. Therefore, the organization develops a PKI with a central corporate root that also allows individual business units to implement certificate services for their specific needs. The organization chooses to use certificate services for the following: E-mail Internet authentication Encrypting File System Software code signing Smart card logon In addition, they identify the following requirements: All users throughout the organization are required to use certificates in order to secure e-mail traffic. Individual business units need to use Internet authentication to facilitate the sharing of data on their local networks with their joint venture partners. All users are able to use Encrypting File System. Developers and network administrators must use software code signing for the custom applications and scripts of the organization. Administrators are required to log on using a smart card before they can perform certain tasks, such as administering domain controllers. The organization then divides these requirements into the following security classifications: Medium security, which includes the e-mail and EFS certificates. Internal high security, which includes the software code signing and smart card logon certificates, and serves the needs of network administrators and developers. External high security, which includes the Internet authentication certificates and meets the need of the organization to share information with joint venture partners. Defining Certificate Requirements 745 Figure 15.4 shows an example of the User Certificate Requirements worksheet that the organization created to summarize these classifications. Figure 15.4 Example of a User Certificate Requirements Worksheet For a worksheet to assist you in documenting your certificate requirements, see ―User Certificate Requirements‖ (DSSPKI_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―User Certificate Requirements‖ on the Web at http://www.microsoft.com/reskit). After they have planned the trust relationships for the internal CA infrastructure and extended external CA infrastructure, the organization can design its certificates and certificate management processes. Administrators must examine the security and user requirements to develop a secure certificate services solution. For more information about designing certificates and configuring CAs, see ―Creating a Certificate Management Plan‖ later in this chapter. 746 Chapter 16 Designing a Public Key Infrastructure Designing Your CA Infrastructure To support the certificate-based applications of your organization, you must establish a framework of linked CAs that are responsible for issuing, validating, renewing, and revoking certificates as needed. The goal in establishing a CA infrastructure is to provide reliable service to users, manageability for administrators, and flexibility to meet both current and future needs, while maintaining an optimum level of security for the organization. Figure 15.5 shows the steps involved in designing your CA infrastructure. Figure 15.5 Designing Your CA Infrastructure Designing Your CA Infrastructure 747 Planning Core CA Options Before you can establish a CA infrastructure that meets the security needs and certificate requirements for your organization, you need to make decisions about a number of core CA options that are available. Planning the CA infrastructure for your organization involves making decisions about the following: Location of the root certification authorities. Internal versus third-party CAs. Requirements for CA capacity, performance, and scalability. Your Active Directory structure. Your PKI management model. CA types and roles. Use of hardware cryptographic service providers. Number of CAs required. Designing Root CAs A CA infrastructure consists of a hierarchy of CAs that trust one another and authenticate certificates belonging to one another. Within this infrastructure, a final authority, called a root CA, must be in place. The root CA certifies other certification authorities to publish and manage certificates within the organization. Before you establish a CA hierarchy, you must determine the following: Who designates the root certification authority in the organization. For example, determine whether this is the responsibility of central IT, divisional IT departments, or a third-party organization. Where the root certification authority is to be located. Who manages the root certification authority. Whether the role of the root CA is only to certify other certification authorities, or also to serve certificate requests from users. After you have made these determinations, you can define the roles for any additional certification authorities, including who manages them and what trust relationships they have with other CAs. For more information about CA roles, see ―Defining CA Roles in the Trust Hierarchy‖ later in this chapter. 748 Chapter 16 Designing a Public Key Infrastructure Selecting Internal CAs vs. Third-Party CAs Depending on the functionality that you require, the capabilities of your IT infrastructure and IT administrators, and the costs that your organization can support, you might choose to base your certification authority infrastructure on internal CAs, third-party CAs, or a combination of internal and third-party CAs. Internal CAs If your organization conducts most of its business with partner organizations and wants to maintain control of how certificates are issued, internal CAs are the best choice. Internal CAs: Allow an organization to maintain direct control over its security policies. Allow an organization to align its certificate policy with its overall security policy. Can be integrated with the Active Directory infrastructure of the organization. Can be expanded to include additional functionality and users at relatively little extra cost. The disadvantages associated with using internal CAs include: The organization must manage its own certificates. The deployment schedule for internal CAs might be longer than that for CAs available from third-party service providers. The organization must accept liability for problems with the PKI. External CAs If your organization conducts most of its business with external customers and clients and wants to outsource certificate issuing and management processes, you might choose to use third-party CAs. Third-party CAs: Allow customers a greater degree of confidence when conducting secure transactions with the organization. Allow the organization to take advantage of the expertise of a professional service provider. Allow the organization to use certificate-based security technology while developing an internally managed PKI. Allow the organization to take advantage of the provider’s understanding of the technical, legal, and business issues associated with certificate use. The disadvantages associated with use of third-party CAs include: They typically involve a high per-certificate cost. They might require the development of two different management standards, one for internally issued certificates and one for commercially issued certificates. They allow less flexibility in configuring and managing certificates. Designing Your CA Infrastructure 749 The organization must have access to the third-party CAs in order to access the CRLs. Autoenrollment is not possible. Third-party CAs allow only limited integration with the internal directories, applications, and infrastructure of the organization. You might need to use both internal and third-party CAs. For information about using a combination of internal and third-party CAs in your organization, see ―Extending Your CA Infrastructure‖ later in this chapter. Evaluating CA Capacity, Performance, and Scalability Organizations must agree upon a definition of acceptable CA performance. To determine the appropriate number of CAs and the best configuration for your CA infrastructure, you need to evaluate and address the factors in your organization that impact CA capacity, performance, and scalability. These include: The number of certificates that you need to issue and renew. The key lengths of the issuing CA certificates. The type of hardware that is used for your CAs. The number and configuration of the client computers that you need to support. The quality of your network connections. A stand-alone Windows Server 2003 CA supports more than 35 million certificates per physical CA without any degradation of performance. An individual departmental certification authority running on a server with a dual processor and 512 megabytes (MB) of RAM can issue more than 2 million standard-key-length certificates per day. Even with an unusually large CA key, a single stand-alone CA with the appropriate hardware is capable of issuing more than 750,000 user certificates per day. Using a greater number of small CAs with strategically located CRL distribution points reduces the risk that your organization might be forced to revoke and reissue all its certificates if a large CA is compromised. However, using a greater number of CAs might increase your administrative overhead. For many organizations, the primary limitations to CA performance are the amount of physical storage available and the quality of the clients’ network connectivity to the CA. If too many clients attempt to access your CA over slow network connections, autoenrollment requests can be delayed. Another significant factor is the number of roles that a CA server performs on the network. If a CA server is operating in more than one capacity in the network — for example, if it also functions as a domain controller — it can negatively impact the capacity and performance of the CA. It can also complicate the delegation of administration for the CA server. For this reason, unless your organization is extremely small, use your CAs only to issue certificates. 750 Chapter 16 Designing a Public Key Infrastructure Some hardware components impact PKI capacity and performance more than others. When you are selecting the server hardware for your CAs, consider the following: Number of CPUs. Large CA key sizes require more CPU resources. The greater the number of CPUs, the better the performance of the CA. CPU power is the most critical resource for a Windows Server 2003 certification authority. Note Because of the architecture of their databases, Windows Server 2003 certification authorities are CPU-intensive and use a substantial amount of the disk subsystem. However, other hardware resources can also impact the performance of a CA when the system is put under stress. Disk performance. In general, a high-performance disk subsystem allows for a faster rate of certificate enrollment. However, key length impacts disk performance. With a shorter CA key length, the CPU has fewer calculations to perform and, therefore, it can complete a large number of operations. With longer CA keys, the CPU needs more time to issue a certificate and this results in a smaller number of disk input/output (IO) operations per time interval. Number of disks. You can improve performance slightly by using separate physical disks for the database and log files. You can improve performance significantly by placing the database and log files on RAID or striped disk sets. In general, the drive that contains the certification authority database is used more than the drive hosting the log file. Note Using separate logical disks does not provide any performance advantages. Amount of memory. The amount of memory that you use does not have a significant impact on CA performance, but must meet general system requirements Hard disk capacity. Certificate key length does not affect the size of an individual database record. Therefore, the size of the CA database increases linearly as more records are added. In addition, the higher the capacity of the hard disk, the greater the number of certificates that a CA can issue. Tip Plan for your hard disk requirements to grow over time. In general, every certificate that you issue requires 17 kilobytes (KB) in the database and 15 KB in the log file. Designing Your CA Infrastructure 751 The type of hardware that your clients use can also impact performance. When you are selecting or evaluating the capabilities of the hardware for your CA clients, consider the following: Key length. The greater the key length of a requested certificate, the greater the impact on the CPU of the server hosting the CA. Network bandwidth. Assuming that the CA is not serving in more than one capacity, a 100- megabit network connection is sufficient to prevent performance bottlenecks. As you plan your CA infrastructure, you also need to ensure that your design is flexible enough to accommodate changes to your organization. For example, you need to be able to accommodate: Changes in the functionality that you require from your public key infrastructure. Growth or decline in demand for certificates. The addition or removal of locations that CAs need to serve. The effect of revocation. Revoking large numbers of certificates can take several minutes and increase the size of the database. Using multiple CAs is an excellent way to ensure that your infrastructure can support enterprise scalability. The use of multiple CAs, even for organizations with minimal certificate requirements, provides the following advantages: Greater reliability. If you need to take an individual CA offline for maintenance or backup, another CA can service its requests. Scalability. Increases in demand, either from new users or from new applications, can be accommodated more easily. Distributed administration. Many organizations distribute security administration across a number of IT administrators to prevent one individual or team from controlling the entire security technology infrastructure of the organization. Improved availability. Users in remote offices can access a CA that is local to them rather than accessing a CA across slow Wide Area Network (WAN) links. Note You can reorganize your CA infrastructure by adding or removing a CA and its associated users from a CA hierarchy. However, you cannot move a subset of users on a single CA to a new CA without forcing the users to re-enroll with the new CA. 752 Chapter 16 Designing a Public Key Infrastructure Integrating the Active Directory Infrastructure Your CA infrastructure is independent of the domain structure of your Windows environment. For example, one CA can service requests from multiple domains, or multiple CAs can serve a single domain. CA hierarchies with stand-alone CAs can even span multiple Active Directory forests. If possible, take your PKI requirements into account when you design your Active Directory infrastructure. Active Directory and PKI technology impact each other in the following ways: Enterprise CAs are bound to the forest. As a result, enterprise CAs can only issue certificates to computers and users in the forest. In addition, you cannot change the name of the CA or the computer after it is deployed. Moreover, the computer cannot be removed from the domain or forest. Because much of the security of an organization is established at the forest level, the security of an enterprise CA is connected to the forest in which it is located. For this reason, each forest requires its own enterprise CAs. Note If certificates from stand-alone CAs are published to Active Directory, these stand-alone CAs cannot be renamed or removed from the forest without their certificates becoming invalid. However, you can rename stand-alone CAs that belong to workgroups without impacting the status of their certificates. Certificate storage affects the size of your directory. If you store certificates in user objects, the size of the directory increases and replication time might increase. Because the userCertificate attribute contains data about all the user certificates, the addition of a certificate to that multivalued attribute causes Active Directory to replicate attribute data for all certificates. Complications such as failure to recognize the user or the certificate can occur. This happens if you do not apply a consistent naming structure for both your distinguished names (also known as DNs) and your user principal names (UPNs). Enterprise CAs rely on the existence of an Active Directory schema. If your schema is based on Windows 2000 Active Directory, you might need to extend it to support Windows Server 2003 Certificate Services functionality, such as version 2 certificate templates. For more information about version 2 templates, see ―Selecting Certificate Templates‖ later in this chapter. For certificates with a long life, the availability of the CA services themselves is much less important than the availability of the directory that holds the certificates and the certificate revocation lists. If you integrate your CAs with Active Directory, your certificates and CRLs are automatically published to the directory and replicated throughout the forest as part of the global catalog. Designing Your CA Infrastructure 753 Note If you use Active Directory to publish and replicate information about CRLs throughout your organization, be sure to review Active Directory replication schedules and policies in order to ensure that this data is distributed in a timely manner. Windows Server 2003 Certificate Services functions whether Active Directory in your organization is based on Windows 2000 or Windows Server 2003. It also functions if your organization is operating in mixed mode. Configuring Public Key Group Policy If you have an Active Directory environment, Group Policy allows you to link certificate services to groups of users or computers based on their domains or organizational unit membership. You must configure public key Group Policy in order to perform the following tasks: Add trusted root certificates for groups of computers. You can define the following: Which root CAs users can trust when verifying certificates. Whether users are allowed to trust additional CAs of their own choosing. The purposes for which certificates issued by each CA can be used. Enterprise root CAs within your domain forest are automatically added to these policies. Distribute certificate trust lists for computers and users. For more information about certificate trust lists, see ―Evaluating Factors That Affect Extended Trusts‖ later in this chapter. Enable autoenrollment. For more information about autoenrollment, see ―Selecting a Certificate Enrollment and Renewal Method‖ later in this chapter. Designate EFS recovery agent accounts. You can define an EFS recovery policy within the scope of the policy object. If a recovery policy is defined, it is populated with the certificates of the recovery agents. In many organizations, users and computers are already organized into domains and organizational units that are based on the organization structure, location, and job function. If your organization has not already created an Active Directory domain structure, the best way for you to take advantage of Public Key Group Policy is to define the groups of users and computers that will use your Certificate Services and communicate this information to the Active Directory and Group Policy administrators, so that they can address your public key requirements in their planning. For more information about how to plan for the use of Group Policy, see ―Designing a Resource Authorization Strategy‖ in this book. 754 Chapter 16 Designing a Public Key Infrastructure Defining PKI Management and Delegation It is important to define a PKI management model early in the process of designing your CA infrastructure. This PKI management model must complement your existing security management delegation plan and help you to meet Common Criteria requirements for role separation. To ensure that a single individual cannot compromise PKI services, it is best to distribute management roles across different individuals in your organization. This involves deciding which individuals are to perform each of the following tasks: Creating or modifying existing CAs Managing certificate templates Issuing cross certificates Issuing or revoking user certificates Configuring and viewing audit logs You can use discretionary access control lists (DACLs) to manage CA permissions and delegate CA management tasks. Windows Server 2003 includes the following CA management roles: Service Manager. Configures and manages Certificate Services for local users, assigns certificate managers, and renews CA certificates. Certificate Manager. Issues and revokes certificates. Auditor. Audits the actions of local administrators, service managers, and certificate managers. The extent to which you separate roles depends on the level of security that you require for a particular service. Assign the fewest possible rights to users in order to achieve the greatest level of security. For example, you can adopt the following rules: No user can assume the roles of both CA Administrator and Certificate Manager. No user can assume the roles of both User Manager and Certificate Manager. If you need stricter guidelines, you can include the following: No user can assume the roles of both Auditor and Certificate Manager. To facilitate this delegation process, you need to understand how various PKI administrative roles align with Windows Server 2003 administrative roles. Table 15.1 lists the Windows Server 2003 administrative roles that correspond to each PKI administrative role. Designing Your CA Infrastructure 755 Table 15.1 PKI Administrative Roles and Their Corresponding Windows Server 2003 Administrative Roles PKI Administrative Windows Server 2003 Description Role Administrative Role PKI Administrator Configures, maintains, and User renews the CA. Backup Operator Performs system backup Backup Operator on the and recovery. server on which the CA is running Audit Manager Configures, views, and Local Administrator on maintains audit logs. the server on which the CA is running Key Recovery Requests retrieval of a User Manager private key stored by the service. Certificate Manager Approves certificate User enrollment and revocation requests. User Manager Manages users and their Account Operators (or associated information. person delegated to create user accounts in Active Directory) Enrollee Requests certificates form Authenticated Users the CA Table 15.2 lists the actions that each PKI administrative role can perform. Table 15.2 Actions Performed By PKI Administrative Roles Local Enroll CA Certificate Audit Backup Action Server ee Admin Manager Manager Operator Admin Install a CA Configure a CA Policy and exit module configuratio n Stop/start service Change configuratio n Assign user roles (continued) 756 Chapter 16 Designing a Public Key Infrastructure Table 15.2 Actions Performed By PKI Administrative Roles (continued) Local Enroll CA Certificate Audit Backup Action Server ee Admin Manager Manager Operator Admin Establish user accounts Maintain user accounts Configure profiles Renew CA keys Define key recovery agent(s) Define officer roles Enable role separation Issue/Appro ve certificates Deny certificates Revoke certificates Unrevoke certificates Renew certificates Enable, publish, or configure CRL schedule Configure audit parameters Audit logs Back up system Restore system (continued) Designing Your CA Infrastructure 757 Table 15.2 Actions Performed By PKI Administrative Roles (continued) Local Enroll CA Certificate Audit Backup Action Server ee Admin Manager Manager Operator Admin Read CA properties, CRL Request certificate Read CA database Read CA configuratio n information Read issued, Revoked, pending certificates Note As you delegate roles and responsibilities, be sure to keep track of the permissions that you configure on certificate directories. Distributing access to a PKI to a number of individuals creates greater security risks. Defining CA Types and Roles To plan your CA infrastructure, you need to understand the different types of CAs available with Windows Server 2003 and the roles that they can play. Windows Server 2003 Certificate Services supports the following two types of CAs: Enterprise Stand-alone Enterprise and stand-alone CAs can be configured as either Root CAs or Subordinate CAs. Subordinate CAs can further be configured as either Intermediate CAs (also referred to as a policy CA) or Issuing CAs. Before you create your CA infrastructure, you need to determine the type or types of CAs that you plan to use, and define the specialized roles that you plan to have each CA assume. 758 Chapter 16 Designing a Public Key Infrastructure Enterprise vs. Stand-Alone CAs Enterprise CAs are integrated with Active Directory. They publish certificates and CRLs to Active Directory. Enterprise CAs use information stored in Active Directory, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type. If you want to enable automated certificate approval and automatic user certificate enrollment, use enterprise CAs to issue certificates. These features are only available when the CA infrastructure is integrated with Active Directory. Additionally, only enterprise CAs can issue certificates that enable smart card logon, because this process requires that smart card certificates be mapped automatically to the user accounts in Active Directory. Stand-alone CAs do not require Active Directory and do not use certificate templates. If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but this is less secure and is usually not recommended, because the requests are not authenticated. From a performance perspective, using stand-alone CAs with automatic issuance enables you to issue certificates at a faster rate than you can by using enterprise CAs. However, unless you are using autoissuance, using stand-alone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request. For this reason, stand- alone CAs are best used with public key security applications on extranets and the Internet, when users do not have Windows 2000 or Windows Server 2003 accounts, and when the volume of certificates to be issued and managed is relatively low. You must use stand-alone CAs to issue certificates when you are using a third-party directory service or when Active Directory is not available. Note You can use both enterprise and stand-alone certification authorities in your organization. Table 15.3 lists the options that each type of CA supports. Designing Your CA Infrastructure 759 Table 15.3 Options for Enterprise vs. Stand-Alone CAs Enterprise Stand-alone Option CA CA Publish certificates in Active Directory and use Active Directory to validate certificate requests. Take the CA offline. Configure the CA to issue certificates automatically. Allow administrators to approve certificate requests manually. Use certificate templates. Authenticate requests to Active Directory. Root CAs A root CA is the CA that is at the top of a certification hierarchy and must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA. Because there is no higher certifying authority in the certification hierarchy, the subject of the certificate issued by a root CA is also the issuer of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. Windows Server 2003 only allows you to designate a self-signed CA as a root CA. The decision to designate a CA as a trusted root CA can be made at either the enterprise level or locally, by the individual IT administrator. A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject public key belongs to the subject identity information that is contained in the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys. The root CA is the most important CA in your hierarchy. If your root CA is compromised, every other CA and certificate in your hierarchy might have been compromised. You can maximize the security of the root CA by keeping it disconnected from the network and using subordinate CAs to issue certificates to other subordinate CAs or to end users. For more information about using a third-party CA as the root CA, see ―Extending Your CA Infrastructure‖ later in this chapter. For more information about disconnecting CAs from the network, see ―Using Offline CAs‖ later in this chapter. 760 Chapter 16 Designing a Public Key Infrastructure Subordinate CAs CAs that are not root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can, in turn, use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but also serves as a higher certifying authority to one or more subordinate CAs. An intermediate CA is often referred to as a policy CA because it is typically used to separate classes of certificates that can be distinguished by policy. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline. Note Most organizations use one root CA and two policy CAs — one to support internal users, the second to support external users. The next level in the CA hierarchy usually contains the issuing CA. The issuing CA issues certificates to users and computers and is almost always online. In many CA hierarchies, the lowest level of subordinate CAs is replaced by RAs, which can act as an intermediary for a CA by authenticating the identity of a user who is applying for a certificate, initiating revocation requests, and assisting in key recovery. Unlike a CA, however, an RA does not issue certificates or CRLs; it merely processes transactions on behalf of the CA. Using Offline CAs Securing your CA hierarchy is a critical task. If an intruder can gain access to a CA, either physically or by means of the network, he or she might retrieve the private key of the CA and then impersonate the CA to gain access to valuable network resources. The compromise of even one CA key invalidates the security protection that it and any CAs below it in the hierarchy provide. For this reason, it is important to avoid connecting root CAs to the network. Designing Your CA Infrastructure 761 To ensure the reliability of your CA infrastructure, specify that any non-issuing root and intermediate CAs must be offline. This minimizes the risk of the CA private keys becoming compromised. You can take a CA offline in any of the following ways: By installing a CA on a stand-alone Windows 2000 or Windows Server 2003 and configuring it as a stand-alone CA. By physically removing the computer from the network. By shutting down the CA service. By shutting down the computer. Caution Shutting down a CA computer prevents auditing from taking place. Therefore, if a CA computer is compromised, a hardware failure does not generate an audit notification. Make sure that you keep CAs in a secure area with limited access. Installing an offline CA on a server that is a member of a domain can cause problems with a secure channel when you bring the CA back online after a long offline period. This is because the computer account password changes every 30 days. You can get around this by making offline CA computers members of a workgroup. Installing an offline CA as an enterprise CA can cause Active Directory to have problems updating when you disconnect the server from the network. Therefore, do not use an enterprise CA as a root CA. Because they can operate offline, it is a good idea to use stand-alone CAs for root and intermediate CAs. When a CA is supposed to be an offline CA, you can still publish its certificate and CRL in Active Directory. You must be sure to bring an offline CA online at regular intervals, based on your CRL publication schedule, to generate a new CRL for the CA. You must also bring the CA online to process certificate requests for subordinate CA certificates. Important In general, the CRL and Authority Information Access (AIA) paths of an offline CA have to be modified before the first certificate is issued because the CRL and AIA paths, by default, point to the local http server and the local file system. Because the CA is offline and not accessible to other members of a network, the functionality of the CA must be separated from CRL and AIA distribution. 762 Chapter 16 Designing a Public Key Infrastructure Because offline CAs process a small number of certificate requests at infrequent intervals, the administrative costs of maintaining offline CAs is low. The client-side certificate validation process is not affected when a CA is offline because the client verifies the validity of the certificate by checking the certificate chain and the CRL. You cannot store both sources on the offline CA because clients need access to the CRL and AIA paths that are part of the certificate. Important Taking a root CA offline does not reduce its importance, so be sure to use reliable hardware for offline root CAs. A hardware failure on an offline CA prevents you from publishing CRLs or issuing certificates to new subordinate CAs. Using Hardware CSPs Hardware CSPs can support a wide range of cryptographic operations and technologies. Keys stored in tamper- resistant hardware crypto-devices are more secure than keys stored on local computer hard disks. Therefore, keys stored in hardware cryptographic devices can have key lifetimes that are longer than keys stored by software CSPs on hard disks. Note Another advantage to using hardware CSPs is that the key material is kept outside the memory of the computer and within the hardware device. This makes it impossible to access the key of the CA by means of a memory dump. If you determine that a hardware CSP is too costly, consider using smart cards for key storage. When you store cryptographic keys on a smart card, no one in your organization can issue or revoke certificates without the appropriate smart card together with the correct personal identification number (PIN). If you choose to use hardware cryptographic service providers for CA private key storage, you must ensure that the hardware device is physically secured, or at least back up the operator cards or tokens. You might, for example, keep it in a highly secured area in the computer room of your company, or lock it in a safe. Designing Your CA Infrastructure 763 Determining Number of CAs Required After you have identified your application and user requirements, you can begin to estimate the number of CAs that you need to deploy. If your organization has limited certificate requirements, a small user base, and limited expansion goals, a single CA might be sufficient. By using a single CA, you can still meet a variety of needs by customizing and deploying certificate templates and using role separation. However, if availability or distributed functionality of Certificate Services is a priority, you must deploy multiple CAs. You also need multiple CAs if you want separate CAs to issue certificates for different purposes. To determine the number of CAs required, answer the following questions: Do you require more than one CA? If you are only supporting a single application and location, and if 100 percent availability of the CA is not critical, you might be able to use a single CA. Otherwise, you probably require at least one root and multiple subordinate CAs. If you need more than one CA, how many root CAs do you require? Generally, it is recommended that you have only one root CA as a single point of trust. This is because significant cost and effort is required to protect a root CA from compromise. With multiple root CAs, root maintenance becomes much more difficult. However, organizations with a decentralized security administration model, such as corporations with multiple, largely independent business units and no strong central administrative body, might require more than one root CA. For more information about using more than one root CA, see ―Extending Your CA Infrastructure‖ later in this chapter. How many intermediate or policy CAs do you need? How many issuing CAs or RAs do you need? The number of intermediate and issuing CAs that you deploy depends on the following factors: Usage. Certificates can be issued for a number of purposes (for example, secure e-mail, network authentication, and so on). Each of these uses might involve different issuing policies. Using separate CAs provides a basis for administering each policy separately. Organizational or geographic divisions. You must have different policies for issuing certificates, depending on the role of an entity or its physical location in the organization. You can create separate subordinate CAs to administer these policies. Distribution of the certificate load. You can deploy multiple issuing CAs to distribute the certificate load to meet site, network, and server requirements. For example, if network links between sites are slow or discontinuous, you might need to place issuing CAs at each site to meet Certificate Services performance and usability requirements. 764 Chapter 16 Designing a Public Key Infrastructure The need for flexible configuration. You can tailor the CA environment (key strength, physical protection, protection against network attacks, and so on) to provide a balance between security and usability. For example, you can renew keys and certificates more frequently for the intermediate and issuing CAs that are at high risk for compromise, without requiring a change to established root trust relationships. Also, when you use more than one subordinate CA, you can turn off a subsection of the CA hierarchy without affecting established root trust relationships or the rest of the hierarchy. The need for redundant services. If one enterprise CA fails, redundancy makes it possible for another issuing CA to provide users with uninterrupted service. Strive to have only as many CAs and RAs as you need to function efficiently. Deploying more CAs than you need creates an unnecessary management burden, and introduces additional areas of security vulnerability. Note You cannot install more than one CA on a server. Selecting a Trust Model The Windows Server 2003 PKI is based on a hierarchical CA model that is comprised of well-defined trust and CA naming standards. This type of CA trust model provides scalability, easy administration, and consistency with a growing number of third-party CA products. In a hierarchical CA model, multiple CAs are organized into clearly defined parent-child relationships. Child CAs are certified by parent CA-issued certificates, which bind the public key of a CA to its identity. With a hierarchical CA model, you minimize the number of root CAs that you need in order to verify certificates. At the same time, hierarchical CAs allow you great flexibility in the number of certificate-issuing subordinate CAs that you can use. The basic types of CA trust hierarchies include: Rooted trust model. In a rooted trust model, a CA is either a root or a subordinate, and you can use offline root CAs for the highest level of security. Network (or cross-certification) trust model. In a network trust model, every CA is both a root and a subordinate. Hybrid trust model. Hybrid trust models combine elements of both the rooted and network trust models. Your PKI trust hierarchy must be based on one of these three trust models. Designing Your CA Infrastructure 765 Whether you choose to apply a rooted, network, or hybrid trust model to your CA infrastructure, you need to base your trust structure on the business requirements of your organization and on the way your organization delegates responsibility for IT administration. In this way, your trust model might be based on one or a combination of the following: Quality of identification Organizational structure User location Rooted Trust Model In a rooted trust model, the root CA is the trust anchor and has a self-signed certificate. The root CA issues a certificate to all direct subordinate CAs, if needed, which, in turn issue certificates to their subordinate CAs. A subordinate CA is trusted cryptographically, based on the signature of its parent. Figure 15.6 illustrates the rooted trust model. Figure 15.6 Rooted Trust Model 766 Chapter 16 Designing a Public Key Infrastructure Numerous products and services offered by major software vendors, including Microsoft, support rooted trust hierarchies. You can add a new CA to a rooted trust hierarchy by enrolling it to a CA anywhere in the trust hierarchy. If you create a new trust hierarchy, it only needs to trust the root CA of the new PKI in order to trust all the subordinate CAs in the new hierarchy. A rooted trust model enables you to compartmentalize risks, management, and certificate processing. Rooted trust hierarchies are more scalable and easier to administer than other hierarchies because each CA serves a single role within the hierarchy and is not operationally dependent on other CAs. Any CA in a rooted trust hierarchy is either a root or a subordinate but never both. Each CA is responsible for processing requests and issuing certificates signed by its own key; each CA is responsible for revoking certificates and publishing CRLs to accessible locations; and each CA can be managed separately by different personnel in different parts of an organization. Because CAs in a rooted trust hierarchy can be online or offline, rooted trust hierarchies allow great flexibility in the ways in which you can deploy and manage a PKI. You can protect the private key of a CA by taking the CA offline. Because offline CAs are typically the root and/or policy CAs that only issue certificates to other CAs, taking the CA offline does not impact other parts of the hierarchy. Because most protocols deliver a chain of certificates that terminates in a trusted root CA, rooted trust hierarchies provide a straightforward means by which CAs can determine whether a certificate can be trusted. Note If the certificate of a root CA expires, all certificates that are issued by the root CA or by its subordinate CAs also expire. For more information about managing certificate lifetimes, see ―Selecting Certificate Security Options‖ later in this chapter. Network Trust Model If your organization has multiple, distributed IT departments, you might not be able to establish a single, trusted root. In this situation, you can implement a network trust model, in which all CAs are self-signed and trust relationships between CAs are based on cross-certificates. Cross-certificates are special certificates that are used to establish complete or qualified one-way trusts between otherwise unrelated CAs. For more information about the use of cross-certificates and how to manage cross-certified relationships, see ―Selecting an Extended CA Infrastructure Configuration‖ later in this chapter. A network trust model can be viewed as a hierarchy because a cross-certificate is essentially the same as a subordinate CA certificate in a rooted trust model. The cross-certifying CA is the issuer and the cross-certified CA is the subject. Designing Your CA Infrastructure 767 Because a cross-certificate is a logical subordination of one CA to another CA, a network trust model is in effect a hierarchy, with the added property that a root CA is also a subordinate CA in the cross-certifying PKI. Unlike the rooted trust model, in which a global directory such as Active Directory is not required, a global directory is essential in a network trust hierarchy. Without a global directory, cross-certificates need to be preinstalled on all clients of the PKI; otherwise there is no way to discover them. Figure 15.7 shows an example of a network trust model. Figure 15.7 Network Trust Model The trusts in Figure 15.7 are bidirectional, which means that CA1 issued a cross-certificate of trust to CA2 and CA2 issued a cross-certificate of trust to CA1. It is also possible to rescind trust for a CA by revoking its cross- certificate. Cross-certification does not need to be bidirectional, and a cross-certifying CA does not need the cooperation of the CA being certified. For example, CA1 can cross certify CA2, without CA2 cross certifying CA1. In such a case, clients of CA1 trust CA2 and CA3, while clients of CA2 and CA3 do not trust CA1. To do this, CA1 creates a cross-certificate without the knowledge of CA2, because all that CA1 needs is the public key certificate of CA2. This is known as unilateral cross-certification, where one CA cross-certifies another CA but not the reverse. Bidirectional cross-certificates are usually preferred, although with this model you need to manage a greater number of cross-relationships as the number of cross-certificates increases. Full trust between cross-certified CAs also means that the client trusts all certificates issued by the other CA, regardless of the purpose of the certificate. In a native Windows Server 2003 environment, however, you can filter by certificate types. You can also limit trust between CAs by means of qualified subordination, which can be implemented in the form of name constraints, policy constraints, policy mapping, and path constraints. For more information about these methods, see ―Extending Your CA Infrastructure‖ later in this chapter. 768 Chapter 16 Designing a Public Key Infrastructure Cross-certification enables you to create bridges between separate PKIs without either PKI being directly subordinate to the other. Because cross-certification is an indirect subordination of one PKI to another, the trust point does not change relative to either PKI. In fact, bidirectional cross-certification models the way in which companies form relationships; that is, each side participates in establishing the relationship. A network trust model, however, is much more difficult to maintain and troubleshoot than a rooted trust model. Note Use a network trust model only in conjunction with name constraints. For more information about name constraints, see ―Name Constraints‖ later in this chapter. Hybrid Trust Model Some organizations might find a pure rooted trust model too restrictive, because no single CA can serve as the root for all other CAs. At the same time, a pure network model can become prohibitively complex if too many different CAs are involved. If you use a hybrid approach, however, you can cross-certify only certain CAs and thus use the benefits of both the rooted and network trust models. Trust Hierarchy Based on Quality of Identification A trust hierarchy based on quality of identification enables an organization to configure CAs to issue certificates to specific groups of users. This type of trust hierarchy is ideal for organizations in which different identification and authentication requirements are applied to different groups of users, computers, and activities. For example, an organization requires employees to appear in person to provide identification such as a driver’s license or passport to a security officer, who checks an employee database to ensure that the individual is authorized, before they can receive appropriate credentials. However, because computers cannot assert an identity, managers in the organization are responsible for ensuring that computer names are correct and that computers are authorized to have a certificate. Because the organization requires CAs for employee certificates and computer certificates and each requires a different form of identification, the organization chooses to create a trust hierarchy based on quality of identification. In a trust hierarchy based on quality of identification, the CAs subordinate to the root CA are organized according to the quality of identification required for the certificate to be issued. The subordinate CAs use certificates signed by the root CA in order to issue certificates to users, computers, services, or another CA. Designing Your CA Infrastructure 769 A typical CA hierarchy based on quality of identification includes two or three issuing CAs for each of the following: Employee certificates Computer certificates Contractor certificates, if applicable. These certificates might require the same identification that employee certificates require, but contain an issuer statement stating that the individual is not a full-time employee. Trust Hierarchy Based on Organizational Structure Although a two- or three- tier trust hierarchy based on the quality of identification is sufficient for most organizations, some organizations might need to deploy a three-tier CA trust hierarchy based on the administrative structure of the organization. In a trust hierarchy based on organizational structure, issuing CAs are configured to support different organizational divisions, such as permanent employees and contractors. The issuing policy, for example, might be based on the organization of user accounts, so that stronger security measures are applied to independent contractors, temporary employees, or external business partners. Figure 15.8 shows a rooted trust hierarchy based on organizational structure. Figure 15.8 Rooted Trust Hierarchy Based on Organizational Structure 770 Chapter 16 Designing a Public Key Infrastructure Design your trust hierarchy according to organizational structure if your certificate requirements vary according to organizational units; for example, all employees receive certain certificates, all partners receive a different set of certificates, and so on. Do not use this type of design if you can define too many different groups of requirements; in this case, a trust hierarchy based on certificate usage is more appropriate. Trust Hierarchy Based on Location Some organizations might find it necessary to implement a three-tier trust hierarchy based on location. This configuration allows regional administrators to manage the certificate requirements for users in a defined area such as a continent, country/region, or locale. Figure 15.9 shows a CA trust hierarchy based on location. Figure 15.9 Trust Hierarchy Based on Location Depending on the nature of your business, you might need to issue certificates based on location to comply with legal requirements — for example, if you perform work for a government agency — or other local regulations. Designing Your CA Infrastructure 771 Defining CA Roles in the Trust Hierarchy After you have designed the trust hierarchy for your organization, you must define the roles for your root, policy, and issuing CAs. The root CA, for example, might be used to sign, certify, and/or revoke subordinate CAs. Intermediate or policy CAs might serve internal or external customers, or, in larger organizations, might serve more specialized functions or locations. Issuing CAs and RAs might be defined according to the clients that they serve or the certificates that they issue. You might choose to select some or all of the following roles for your intermediate and issuing CAs: Intermediate CA. Certifies subordinate CAs to issue certificates. Rudimentary CA. Issues certificates for the most basic operations, such as user authentication without an identity check. Note Stand-alone CAs are primarily used in intermediate and rudimentary roles. Basic security CA. Issues certificates, based on an Active Directory identity check, to users and computers that do not have special security requirements. Medium security CA. Issues certificates to users and computers that meet special security requirements and whose identities are validated in Active Directory. High security CA. Issues certificates to users or computers that meet especially high security requirements, and whose identities must be verified by means of the examination of physical credentials. Note Enterprise CAs are primarily used for basic, medium, and high security roles. Keep the following considerations in mind as you define CA roles: Use a three-tier hierarchy with policy CAs only if necessary. Third-party CAs can form all or part of a Windows Server 2003 CA trust hierarchy. Some third-party products might require other CA trust models that might not be interoperable with rooted CA hierarchies. Windows Server 2003 and most commercial CAs support rooted CA hierarchies. 772 Chapter 16 Designing a Public Key Infrastructure Establishing a CA Naming Convention Before you configure CAs in your organization, you must establish a CA naming convention. Names for CAs cannot be more than 64 characters in length. You can create a name using any Unicode character, but you might want to use the ANSI character set if interoperability is a concern. The CA name does not have to be identical to the name of the computer. The name that you specify when you configure a server to be a CA becomes, in Active Directory, the common name of the CA, and is reflected in every certificate that the CA issues. For this reason, it is important that you do not use the fully qualified domain name (FQDN) for the common name of the CA. This way, malicious users who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a potential security vulnerability. Note You cannot change the name of a server after Certificate Services has been installed without invalidating all the certificates issued by the CA. To change the server name after Certificate Services has been installed, you must uninstall the CA, change the name of the server, reinstall the CA, and reissue all the certificates issued by the CA. You do not have to reinstall a CA if you rename a domain; however, you will have to reconfigure the CA to support the name change. Selecting a CA Database Location When you install a CA in your organization, you must specify a location for the database and log files of the CA. You must also indicate whether you want to store the configuration information for the CA. Storing the CA configuration information is helpful for backing up and, if necessary, restoring your CA. Designing Your CA Infrastructure 773 You can choose to copy the naming information and the certificate for the CA to the file system (the configuration directory is automatically shared by means of a share named certconfig). Note You can change the location of the database and log files manually at a later time. However, you cannot perform this task by using the user interface. Windows Server 2003 uses the JET database engine for the CA database. As with any JET database, it is a good idea to place the database and its log files on different physical disk drives, in order to improve fault tolerance and performance. By default, all these files are located in the certlog subdirectory of the system directory. Tip Use a separate RAID for both the database and log files for the highest level of fault tolerance between backup intervals. The CA database consists of the files listed in Table 15.4. Table 15.4 CA Database Files Database file Purpose <CA name>.edb The CA store edb.log The transaction log file for the CA store res1.log Reservation log file to store transactions if disk space is exhausted res2.log Reservation log file to store transactions if disk space is exhausted edb.chk Database checkpoint file Note You can determine the location of the database files for a CA by typing certutil -databaselocations at a command prompt or by looking in the Certificate Services snap-in user interface. 774 Chapter 16 Designing a Public Key Infrastructure Example: Designing a CA Infrastructure After an organization defines its certificate requirements, it creates a linked hierarchy of certification authorities to enable it to distribute certificates as needed, and to validate or reject certificates as appropriate. In creating this CA infrastructure, the organization takes the following elements into account: The security administration model of the organization. For example, security administration is managed centrally from the headquarters of the organization, but individual business units create and support their own security requirements as needed for individual projects and business relationships. Some units operate autonomously, but report back to corporate IT. The Active Directory infrastructure of the organization. Because the organization has a single-forest logical structure, the CA infrastructure design is simple. The existing single-forest structure allows them to set up CAs, based on geography and bandwidth, to serve clients in multiple domains. For example, one or more common CAs support clients in offices on opposite coasts. Potential use of a third-party CA. The organization is concerned about IT costs and also prefers to manage its own security infrastructure. It addresses both concerns by creating and administering its own CA infrastructure. When joint venture business partners deploy PKIs, it is possible to integrate the two CA infrastructures without having to rely on a third-party CA. For more information about using third-party CAs to extend the CA infrastructure, see ―Extending Your CA Infrastructure‖ later in this chapter. Although the organization deploys Active Directory, it places a stand-alone root CA in a workgroup, rather than in the domain, for increased security. Also, it keeps this root CA offline and in a secure location that can only be accessed by an administrator who is authenticated by means of a smart card. Directly below the root CA, the organization adds three policy CAs. One CA signs all certificates that have been issued to meet the high security standards of the organization, including software code signing, smart card logon, and Internet authentication certificates. The second CA signs all certificates that have been issued to meet the medium security standards of the organization, such as e-mail and EFS certificates. The third signs certificates for the CAs that issue certificates to external partners. These are also offline. Figure 15.10 shows the CA infrastructure for the organization. Designing Your CA Infrastructure 775 Figure 15.10 Example of a CA Infrastructure of an Organization Table 15.5 summarizes the configuration of these CAs. 776 Chapter 16 Designing a Public Key Infrastructure Table 15.5 CA Configuration CA Name State Role Domain Root CA RtCA01 Offline Stand-alone None Internal medium security policy PolCA01 Offline Stand-alone None Internal high security policy PolCA02 Offline Stand-alone None External high security policy PolCA03 Offline Stand-alone None Internal medium security issuing IsCA01 Online Member Corp 1 server Internal medium security issuing CA06 Online Member Corp 2 server Internal medium security issuing CA07 Online Member Corp 3 server Internal high security issuing 2 CA08 Online Member Corp server Internal high security issuing 3 CA09 Online Member Corp server External high security issuing 1 CA01 Online Member Corp server Extending Your CA Infrastructure You can use a rooted CA hierarchy to enable many PKI applications. However, you might find that your PKI needs are too complex to be met by a simple rooted hierarchy. For example, you might need to extend your CA infrastructure to accommodate joint ventures, mergers, geographic, or other business requirements. Figure 15.11 shows the steps involved in extending your CA infrastructure. Extending Your CA Infrastructure 777 Figure 15.11 Extending Your CA Infrastructure 778 Chapter 16 Designing a Public Key Infrastructure Evaluating Factors That Affect Extended Trusts Extending and refining your trust hierarchy is a critical step in the process of creating a secure PKI, and it involves complex decisions. It is important to define appropriate and inappropriate uses for certificates in your organization before you extend your CA infrastructure. Without proper planning, you might grant business partners and users more trust than you intend. If you want to link your established Windows Server 2003 trust hierarchy with an external PKI, a number of factors can impact interoperability. Before you extend your CA infrastructure, evaluate the following features and standards in both PKIs: Standards support Algorithm support CRL distribution points Authority information access (AIA) Authority key identifier (AKI) Certificate extensions Key length Extended key usage (EKU) Directory integration Determine whether any other PKIs with which you need to establish trust support these features and standards, and how you can accommodate differences. Addressing these issues when you design your PKI can help you to ensure the extensibility and interoperability of your PKI environment. Standards Support A number of technical standards provide a basis for interoperability between Windows Server 2003 and other PKI applications. To promote third-party interoperability with the Windows Server 2003 API, Microsoft supports the following standards: PKIX. Defines interoperable PKI standards for the Internet. X.509. Describes the standard format of a certificate. PKCS. Provides a standard for public key message exchanges. TLS. Provides a secure and authenticated channel between hosts on the Internet above the transport layer. Extending Your CA Infrastructure 779 S/MIME. Serves as a standard for secure e-mail across the Internet. Kerberos authentication protocol. Provides a symmetric key framework for authentication in large networks. PC/SC. Serves as a standard for integrating smart cards and smart card readers. Most PKI vendors have adopted many or all of these PKI standards. Different vendors, however, can implement the standards in different ways. While it might be possible to link external PKI implementations to yours, this might involve making some changes to your existing design. For this reason, it is strongly recommended that you evaluate the external PKI to determine whether it meets all your critical requirements. Algorithm Support It is important for a PKI to interoperate with many different hardware vendors and to provide a hardware abstraction layer so that applications do not have to know where keys are stored. Windows Server 2003 uses CryptoAPI to abstract hardware-based key management from applications, and it uses the PC/SC standard instead of PKCS#11 to communicate with smart cards and readers. Many third-party CAs have their own cryptographic APIs and use PKCS#11 to interface to hardware tokens such as smart cards. Because Windows 2000 and Windows Server 2003 require hardware devices to support Plug and Play and power management features, and PC/SC includes support for these ease-of-use features, Windows Server 2003 does not support PKCS#11. Note The Windows Server 2003 PKI can use third-party CSPs, and can enroll users for certificates that have keys that were generated by third-party CSPs. CRL Distribution Points The CRL distribution point (CDP) extension in a certificate identifies how revocation information for the certificate can be obtained. If a CRL distribution point is not always available, certificate chain building can be delayed, causing inconvenience for the user. If a CRL is not available at the distribution point that has been specified in the certificate, CRL retrieval might even fail and the certificate will be considered invalid. Tip Publish CDP URLs for all CAs so that users who need to know whether or not issued certificates have been revoked can find that information. 780 Chapter 16 Designing a Public Key Infrastructure You need to compare any third-party CRL support with the Windows Server 2003 CRL support. For example, the third-party PKIs might not support the Windows Server 2003 CRL process, which includes the use of delta CRLs. Conversely, the Windows Server 2003 PKI might not support the methods of the third-party PKI for processing CRL information. Your extended PKI deployment plan needs to account for these differences. In general, follow these guidelines when you configure the CDP extension: If available, use Active Directory to support internal corporate clients. Use an externally referenced and trusted Lightweight Directory Access Protocol (LDAP) directory to support business partners and customers. Consider using HTTP distribution points, especially for certificates that will be used externally. Authority Information Access The Authority Information Access (AIA) extension is a pointer to the most currently published CA certificate of a CA. The AIA extension helps clients find CA certificates dynamically during chain building. The Windows Server 2003 PKI uses this extension to assist in building trust chains to validate certificates. It is recommended that you publish AIA URLs for all PKIs for which users might need to retrieve up-to-date CA certificates. Whether a CA is online or offline, and whether it is a root, intermediate, or issuing CA, using the AIA extension minimizes the likelihood that PKI clients will encounter unverified certificate chains or revocation data. Such encounters can result in unsuccessful VPN connections, failed smart card logons, or unverified e-mail signatures. Some third-party PKIs do not provide the AIA extension. In this case, parent certificates need to be distributed to domain clients so that the certificates are available before the chain building process begins. Cross-certificates must also be available locally on domain clients, because there is no information in a certificate specifying where it can be found. Authority Key Identifier The Authority Key Identifier (AKI) extension provides a means to identify the public key of the CA that validates the signature on a CRL. This identification is based on either the subject key identifier (SKI) or the issuer name and serial number from the certificate issued by the CRL issuer. The AKI extension is useful in cases when a CRL issuer has more than one signing key. An organization that expects its PKI certificates to be used by other Windows Server 2003 PKIs must populate the Authority Key Identifier extension with a unique key identifier and an issuer name and serial number. The Windows Server 2003 PKI attempts to construct certificate chains by using the issuer name and serial number in the AKI first, and then the subject key identifier. Note By default, Windows Server 2003 does not automatically add issuer names and serial numbers to the AKI extension. This data must be added manually by means of Certutil.exe, although in most cases it is not necessary to do so. Extending Your CA Infrastructure 781 Certificate Extensions Not all certificate extensions are universally recognized. If a CA does not recognize a certificate extension in a request and it has been marked critical, it rejects the certificate. Unless you intend to limit the use of the certificate to a specific application that understands the critical extension, avoid putting critical extensions in certificates because it limits interoperability. Key Length When different PKIs support different minimum and maximum key lengths, an interoperability problem results. Be sure that your internal PKI and the external PKI support the necessary encryption keys. Extended Key Usage The Extended Key Usage (EKU) extension indicates the purposes for which the public key contained in the certificate can be used. The Windows Server 2003 PKI uses the EKU extension to indicate certificates that support special functions, such as IPSec and EFS file encryption backup. The EKU extensions of other organizations might be used for different purposes. Directory Integration Windows Server 2003 PKI certificates can be published to any directory or repository, although the default CA exit module only supports Active Directory. However, by default, a Windows Server 2003 PKI relies on Active Directory and the LDAP for authentication, including smart card logons and certificate autoenrollment, as well as for certificate management. With Microsoft Certificate Services, certificates issued by a third-party CA can be associated with a Windows Server 2003 user account stored in Active Directory. This is possible because applications such as Internet Explorer and Internet Information Services (IIS) can be used to authenticate a user to an account stored in Active Directory, based on the UPN name information in a certificate. The account to which the certificate maps provides information about user access rights on the server. This is an extremely powerful feature for Web- based applications and third-party CAs because it combines strong authentication by means of public key technology with the native authorization model of Windows Server 2003. For example, to enable extranet and remote access scenarios without requiring the application and certificate to manage access rights, administrators can use certificates from partner companies and map them to accounts in Active Directory by means of one-to- one or many-to-one mappings. For more information about using one-to-one and many-to-one mapping, see ―Mapping Certificates to User Accounts‖ later in this chapter. Also, for more information about certificate mapping, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. 782 Chapter 16 Designing a Public Key Infrastructure Selecting an Extended CA Infrastructure Configuration You can use one of three configurations to create an extended CA trust infrastructure: Third-party root CA. Use a third-party CA as a root CA for a new extended CA hierarchy shared between two organizations. New root CA. Establish your own new root CA to combine separate CA hierarchies for two organizations. Cross-certification and qualified subordination. Keep the existing CA hierarchies separate, but use cross-certification and qualified subordination to implement as much or as little trust as needed between the two organizations. There are advantages and disadvantages to each approach. If you need to extend your CA infrastructure to include third-party PKIs, you need to evaluate the requirements of your organization to determine the method that is most appropriate for you. Using Third-Party Root CA Configuration Building a new public key hierarchy from an existing third-party root CA is an appropriate solution if you want to cross-certify with multiple business partners simultaneously. The third-party root CA is used to build a new public key hierarchy designed specifically to serve the needs of multiple organizations. Figure 15.12 shows an example of an extended CA infrastructure built from an existing root CA. In this example, organization A and organization B maintain their existing PKIs and share a new PKI that serves the specific needs of their business relationship. Extending Your CA Infrastructure 783 Figure 15.12 Extended CA Infrastructure Built from an Existing Third-Party Root CA The advantage to this approach is that you can off-load responsibility for maintaining the new infrastructure to an organization that specializes in this type of service. The intermediate and issuing CAs that you create on your side of the shared infrastructure can be administered separately from your existing internal PKI. In this way, the functions of the external PKI cannot compromise the internal PKI, and the organizations that share the extended infrastructure do not have to share transitive trust between their existing PKIs. The disadvantage to this approach is that it involves the creation of a new, separate infrastructure with its own administrative requirements. Although much of this administration is off-loaded to a third party, this approach involves considerable additional cost. The costs can multiply each time you add a new business relationship that requires a separate shared PKI infrastructure. You need to plan for an extended PKI based on an existing root CA in the same way that you plan for your existing internal PKI, in that you must decide where to locate intermediate and issuing CAs, how to manage them, how to protect them, and so on. In this case, you must work with your business partner and the root CA provider to make these decisions. 784 Chapter 16 Designing a Public Key Infrastructure Third-party CAs can form all or part of a CA trust hierarchy. To ensure that third-party CAs provide interoperability with your existing infrastructure, test all proposed interoperability scenarios in your lab. Note Some PKIs require CA trust models that are not interoperable with rooted CA hierarchies. Windows 2000 and most commercial CAs support rooted CA hierarchies. Adding Trusted Root Certificates to Group Policy If a stand-alone CA is not a domain member buts runs as a member of a workgroup, the root CA certificate must be added manually to the domain Group Policy. In contrast, when you install a stand-alone root CA on a computer that is a domain member, the certificate of the CA is added to the Trusted Root Certification Authorities Group Policy for the domain. You can also add certificates for other root CAs to Trusted Root Certification Authorities Group Policy manually. These root CAs then become trusted root CAs for the computers within the scope of the Group Policy. For example, if you want to use a third-party CA as a root CA in a certification hierarchy, you must add the certificate for the third-party CA to the Trusted Root Certification Authorities Group Policy. Using a New Root CA Configuration You or your partner organization can create a new root CA to establish an extended CA infrastructure that supports your business requirements. The structure of this extended CA infrastructure is similar to that of an extended infrastructure based on a third-party rood CA. With a new root CA configuration, however, you and your partner organization must create a security management infrastructure, and must take responsibility for administering and maintaining the extended PKI. If one organization assumes this responsibility, the other organization must trust that its partner will protect the security interests of both parties. This option can be more cost-effective than using a third-party root CA. In addition, you can use Windows Update to distribute new root certificates, improving reliability and decreasing costs. The planning considerations for a new root CA–based extended infrastructure are similar to those that apply to your existing internal PKI. You and your partner organization are responsible for creating administrative policies for the root CA and enforcing the integrity of the new root. Extending Your CA Infrastructure 785 Using a Cross-Certification Configuration With the cross-certification method for extending the CA infrastructure, neither party creates a separate PKI; instead, cross-certificates, accompanied by qualified subordination, enable communication between existing public key infrastructures of two organizations to the degree of trust that their business relationship dictates. Cross-certification creates a shared trust between two CAs that do not share a common root CA. These CAs exchange cross-certificates that allow their organizations to communicate. In this way, the organizations do not have to create and manage additional root CAs. Cross-certification might be the best option if a common root CA for both PKIs does not exist. Figure 15.13 shows an example of an extended CA infrastructure based on cross-certification between the root CA of organization 1 and a subordinate CA in organization 2. Figure 15.13 Extended CA Infrastructure Based on Cross-Certification The advantages to using cross-certification to extend the PKI include low cost and a high degree of flexibility, as you can cross-certify at any level in the hierarchy. For example, if a division of organization 2 wants to share information with all of organization 1, the division can cross-certify with the root CA of organization 1. This, however, creates a security risk, as it exposes resources in parts of the organization that are not part of the business relationship. On the other hand, if a division of organization 1 and a division of organization 2 want to share information, the two divisions can cross-certify CAs that are lower in the CA hierarchy. This option is more secure, as the other divisions of the organizations are not unnecessarily exposed. Cross-certification requires greater administrative overhead than other methods for extending the CA infrastructure, and entails the risk that outsiders might unintentionally be given access to internal resources. If an organization becomes involved in many cross-certification relationships with different levels of trust and different applications, the management overhead can be significant. 786 Chapter 16 Designing a Public Key Infrastructure Limiting Unplanned Trusts When you extend your CA trust infrastructure beyond the boundaries of the PKI of your organization, you can inadvertently create unplanned trust relationships. Unplanned trusts that can occur include: Allowing certificates to be used for unintended applications Allowing external certificates to be used for longer than intended Enabling trust with the extended business partners of a business partners For example, if company A trusts company B by means of an unconstrained cross-certificate, and company B trusts company C, then company A unintentionally trusts company C. Equally serious problems can occur when company A and company B cross-certify, and company A does not realize that company B does not have the same level of control over the manner in which its certificates are issued and used. To limit the creation of unplanned trust relationships and the potential security risks that they pose, you can use CA constraints to define limits on your cross-certificate relationships. Constraints in Windows Server 2003 can be based on: Use and path length (basic constraints) Names Issuance policy Application policy Policy mapping Implement these constraints when you configure your CA and end user certificates. For more information about defining constraints, see ―Using Qualified Subordination‖ later in this chapter. Using Certificate Trust Lists to Limit Unplanned Trusts You can use certificate trust lists (CTLs) to limit unplanned trusts. CTLs are the primary means of limiting unplanned trust relationships in Windows 2000 environments. A CTL is a predefined list of certificates that is signed by a trusted entity. The CTL includes either hashes of certificates or a list of the actual certificate names. In most cases, the CTL is a list of hashed certificate contexts. The CTL allows you to limit the purposes for which certificates issued by an external CA can be used, and the validity period of those certificates. Extending Your CA Infrastructure 787 Windows Server 2003 certificate trust lists allow you to do the following: Create trust certificates from specific CAs without requiring broader trust for the root CA. For example, you can use certificate trust lists on an extranet to trust certificates issued by certain commercial CAs. If you map certificates that are issued to an account stored in Active Directory, you can grant appropriate permission to users who need access to restricted extranet resources. This is possible because they have certificates issued by the trusted commercial CAs. Restrict the permitted use of certificates issued by trusted CAs. For example, you can use a certificate trust list on an extranet to restrict the permitted use of certificates to applications such as secure mail. Control the period of time in which third-party certificates and CAs are valid. For example, the CA of a business partner can have a lifetime of five years and issue certificates with lifetimes of one year. However, you can create a certificate trust list with a lifetime of six months to limit the time that certificates issued by the CA of the business partner are trusted on your extranet. You might use a CTL to allow users to trust certificates that are issued by a commercial CA and restrict the permitted uses for those certificates. You might also use CTLs to control trust on an extranet for certificates that are issued by CAs that are managed by your business partners. Note After a CTL is defined, it must be applied to client computers by means of Group Policy. Example: Selecting an Extended CA Infrastructure Configuration Organizations frequently enter into joint ventures, which can involve the sharing of confidential information, such as engineering data that stored is on an internal network. To facilitate this type of data sharing, an organization can initiate a cross-certified relationship that allows some, but not all, employees of another organization to access data on its network. One way to enable this cross-certified relationship is to create a subordinate CA to a high security Issuing CA. This subordinate CA is then used to facilitate the joint venture relationship. Although it is possible to cross- certify directly with a corporate high security CA, the advantage of using a separate CA specifically for the joint venture is that it allows you to restrict the capabilities of the people who work for the other partners in the joint venture. They cannot, for example, use their certificates for unintended purposes or to access portions of the network that are not relevant to the joint venture. Figure 15.14 illustrates the position of the new CA in the CA infrastructure of one organization. 788 Chapter 16 Designing a Public Key Infrastructure Figure 15.14 Extended CA Infrastructure Creating the CA alone does not enable the new joint venture operations. To enable this sharing, before the CAs are created, administrators must configure the cross-certificates that qualify the trust relationship between the two organizations. These cross-certificates define where, in the first organization, holders of the certificates belonging to the second organization can and cannot go, and which applications they can and cannot use. For information about how to implement these namespace and application limits, see ―Using Constraints and Policy Mapping‖ later in this chapter. Defining Certificate Configuration Options After your CA infrastructure is in place, you can begin to define the certificate configuration options that you need to meet the requirements of your users, as well as the security needs of your organization. Figure 15.15 shows the steps involved in defining certificate configuration options. Defining Certificate Configuration Options 789 Figure 15.15 Defining Certificate Configuration Options Selecting Certificate Templates The certificate services that you deploy and the security requirements that are specific to your organization impact the types of certificates that you issue. You can issue multiple types of certificates to meet a variety of security requirements. The certificate templates available with an enterprise CA in Windows Server 2000 and Windows Server 2003 provide the default contents of all certificates that can be requested from a Windows enterprise CA. These certificate templates are stored in Active Directory and cannot be used with stand-alone CAs. 790 Chapter 16 Designing a Public Key Infrastructure Certificate templates can serve a single purpose or multiple purposes. Single-purpose templates generate certificates that can be used for a single application. For example, the Smart Card Logon certificate template is designed for smart card logon only. Multipurpose templates generate certificates that can be used for a number of applications, such as Secure Sockets Layer (SSL), S/MIME, and EFS. For example, a user certificate can be used for both user authentication and EFS encryption. Both Windows 2000 and Windows Server 2003 support single-purpose and multipurpose templates. However, Windows 2000 and Windows Server 2003 Standard Edition only support version 1 templates, which have read- only attributes that cannot be customized or extended. Windows Server 2003, Enterprise Edition supports version 2 templates, which allow you to create new certificate templates, clone an existing template, and replace templates that are already in use. Important If you are already using version 1 templates, you can upgrade them to version 2 templates. However, the domain admins in your top level domain must have full access control permissions on the version 1 templates in order to complete this upgrade. Domain administrators do not need to have full access control over the templates after the upgrade has been completed. Both version 1 and version 2 certificate templates include the following information: Intended user of the certificate. CA that issued the certificate. Serial number that uniquely identifies each certificate. Public key value for the user identified in the subject field. Validity period of the certificate. Extensions, if any, which apply to the certificate, including additional information that can define certificate purposes, restrictions, and management. Digital signature of the CA, which verifies the relationship of the certificate to the issuing CA. Note You can also create your own certificate templates. Defining Certificate Configuration Options 791 Before the certificates are issued, you need to determine the following critical information: Certificate key length Certificate validity period Optional certificate extensions Note Certificate templates, in conjunction with the CA policy module, allow you to define certificate policy for CA certificates. In addition, version 2 templates allow you to configure the following: Customized enrollment policies Policies related to validity periods Policies related to application usage Policies related to key usage Policies related to key archiving Certificate authorization Domain authentication Certificate administrators Signed enrollment agents Key creation Key and CSP types Certificate contents Important You must upgrade the schema in an Active Directory forest to Windows Server 2003 in order to support version 2 templates. You do not need to upgrade all domain controllers to Windows Server 2003 to perform a schema upgrade. Certificate templates can only be used when the server that is running Certificate Services is an enterprise CA. Enterprise CAs can issue a variety of certificate types based on the templates. You can configure each enterprise CA to issue only specific types of certificates. Table 15.6 lists the different types of version 1 certificate templates that are available, and the purposes for each. 792 Chapter 16 Designing a Public Key Infrastructure Table 15.6 Version 1 Certificate Templates Certificate template name Certificate purposes Issued to Administrator Code signing, Microsoft trust list Users signing, EFS, secure e-mail, client authentication Authenticated Session Client authentication Users Basic EFS Encrypting File System Users CEP Encryption Act as a registration authority Users Code Signing Code signing Users Client authentication, server Domain Controller Computers authentication EFS Recovery Agent File recovery Users Enrollment Agent Certificate request agent Computers (Computer) Exchange Enrollment Certificate request agent Users Agent (Offline Request) Secure e-mail, client Exchange User Signature Users authentication Secure e-mail, client Exchange User Users authentication IPSEC IP Security Computers IPSEC (offline request) IP Security Computers Root Certification Identify the root CA Computers Authority Computers/rou Router Client authentication ters Smartcard Logon Client authentication Users Client authentication, secure e- Smartcard User Users mail Subordinate CA All Computers Trust List Signing Microsoft trust list signing Users Authentication, secure e-mail, and User Users EFS Secure e-mail, client User Signature Users authentication WebServer Server authentication Computers Table 15.7 lists the version 2 certificate templates that are available in Windows Server 2003 Advanced Server and the purposes for each. Defining Certificate Configuration Options 793 Table 15.7 Version 2 Certificate Templates Certificate template name Certificate purposes Issued to CA Exchange CA encryption Computer Cross certification Qualified subordination Computer authority Directory E-mail Directory replication Users Replication Domain Controller Client authentication, server Users Authentication authentication Key Recovery Agent Key recovery Users Note When you select and modify templates, create function-based names for the templates, such as domainA_e-mail or legal_signing. Function-based names help users to select the appropriate certificate for the task that they need to perform. Delegating Administration of Certificate Templates Although the majority of CA-related tasks are performed by administering the CA itself, certain tasks, including the administration of certificate templates, are controlled through Active Directory. To delegate the administration of certificate templates: Right-click the Certificate Templates node in the Certification Authority snap-in and select Manage. Double click a certificate template. Under the Security tab, check the Allow boxes for the Read and Write permissions. For more information about certificate templates, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit). 794 Chapter 16 Designing a Public Key Infrastructure Selecting Certificate Security Options The security requirements for your certificates are based on the following four critical factors: Risk of attack. The security of your network, the value of the network resources protected by the CA trust chain, and the cost of initiating an attack all impact the security requirements for your certificates. The degree to which you trust your certificate users. In general, the less you trust your users, the shorter the certificate lifetimes and CRL lifetimes, and the tighter the control over renewals. For example, you might trust temporary users less than you trust normal business users, and therefore you might set shorter lifetimes on the certificates of temporary users and require stricter controls for their renewal. The amount of administrative effort that you are willing to devote to certificate renewal and CA renewal. For example, to reduce the administrative effort required to renew CAs, you can specify long, safe lifetimes for your certification trust hierarchies. The business value of the certificate. For example, you place tighter restrictions on certificates used to validate critical data such as purchase contracts than you place on certificates for routine e-mail. The standard settings for certificates issued by Microsoft Certificate Services meet most security needs. However, you might want to specify stronger security settings for certificates that are used by certain user groups. For example, you can specify longer private key lengths and shorter certificate lifetimes for certificates used to provide security for valuable information. To ensure that your certificates meet the security requirements of your organization, you need to configure the following: The cryptographic algorithms and private key lengths for CAs and issued certificates. The amount of time for which the certificates and their keys are valid. Certificate renewal and permitted renewal frequency. Selecting Cryptographic Algorithms and Key Lengths Windows 2000 and Windows Server 2003 support several well-known cryptographic algorithms that are also supported by other PKI products. When you install a Windows Server 2003 CA, you can select CA key lengths from 384 bits to 16,384 bits, depending on the CSP that you select. In a typical deployment, user certificates have 1,024-bit keys and root CAs have 4,096-bit keys. Key length is determined in part by the cryptographic algorithm that you select. Table 15.8 lists the algorithms that Windows Server 2003 supports and their minimum and maximum key lengths. Defining Certificate Configuration Options 795 Table 15.8 Windows Server 2003 Algorithms and Key Lengths Algorithm Minimum Key Length Maximum Key Length RSA 384-bit 16,384-bit DSA 512-bit 1,024-bit In most cases, the default key length provides an acceptable balance between security and CA performance. However, to provide the maximum possible protection without degrading CA performance, select the largest keys that are practical for CAs. Keys that are at least 1,024 bits long are the best choice for CA certificates. Keep in mind that generating large keys can place a high load on computer processors and might also increase the amount of time needed for signing operations to excessive levels. Note Key length has a minimal impact on the size of a certificate. However, it can be a significant consideration for smart card deployments because of the space constraints of the card. In general, public and private key lengths do not impact interoperability as long as both environments support a common range of key lengths. If one PKI supports large public keys and another does not, however, the two cannot exchange symmetric keys or sign and verify data. Note While key exchange and digital signature operations performed between PKIs do not require the same public and private key lengths, symmetric key algorithms do. In addition, if different key lengths are used, both key lengths must be supported in both environments. When PKIs do not support the same key lengths, some applications cannot decrypt data that other applications have encrypted. In addition, the PKIs might not be able to establish secure communications channels between applications if the applications cannot agree on symmetric key lengths, as required by protocols such as SSL and TLS. If a PKI uses public/private keys based on an algorithm such as RSA, all PKI operations can be accomplished with only one key pair. However, single key pairs might not meet the security requirements of your organization or its choice of algorithm. For this reason, Windows Server 2003 supports both single key pairs and dual key pairs. A good PKI is flexible enough to allow as many or as few key pairs as are required by applications. If one PKI operates according to the number of keys that applications use, it can impact interoperability with other PKIs. For example, an e-mail application could sign a message with a signature-only key and include the associated certificate in a message sent to a recipient without also sending an encryption certificate as part of the message. The recipient might then be unable to discover the encryption certificate of the sender to reply with an encrypted message back to the sender. 796 Chapter 16 Designing a Public Key Infrastructure Establishing Certificate and Key Lifetimes A number of factors impact certificate lifetimes, such as the type of certificate, the security requirements of your organization, the standard practices in your industry, and government regulations. In general, longer keys support longer certificate lifetimes and key lifetimes. When establishing certificate and key lifetimes, you must consider how vulnerable your keys are to compromise and what the potential consequences of compromise are. The following factors impact the lifetimes that you choose for certificates and keys: The length of private keys for certificates. Because longer keys are more difficult to break, they justify longer safe key lifetimes. The security of the CAs and their private keys. In general, the more secure the CA and its private key, the longer the safe certificate lifetime. CAs that are operated offline and stored in locked vaults or data centers are the most secure. The strength of the technology used for cryptographic operations. In general, stronger cryptographic technology supports longer key lifetimes. You can extend key lifetimes if you enhance private key storage by using smart cards and other hardware cryptographic service providers. Some cryptographic technologies provide stronger security, as well as support for stronger cryptographic algorithms. For example, you might use smart cards for user logon or FIPS 140-1 Crypto Cards for secure mail and secure Web browsers. The vulnerability of the CA certification chain to attack. In general, the more vulnerable your CA hierarchy is to attack, the longer the CA private keys and the shorter the key lifetimes required. The users of your certificates. Organizations typically trust their own employees more than they trust employees of other organizations. If you issue certificates to external users, you might want to shorten the lifetimes of those certificates. The number of certificates that have been signed by a dedicated CA. The more public the CA public key that is used to sign an issued certificate, the more vulnerable it becomes to attempts to break its key. An expiration date is defined for each certificate at the time that it is issued. An enterprise CA issues certificates with lifetimes that are based on the certificate template for the requested certificate type. Most certificate templates specify a lifetime of one year. However, the following version 1 certificate templates specify a lifetime of two years: CEP Encryption (offline request) Enrollment Agent Enrollment Agent (computer) Defining Certificate Configuration Options 797 Enrollment Agent (offline request) IPSec IPSec (offline request) Router (offline request) Web Server The following certificate templates specify a lifetime of five years: Domain Controller Subordinate certification authority The lifetimes of certificates issued by stand-alone CAs are determined by system registry settings for the CA. The certificates for enterprise root CAs and enterprise stand-alone root CAs have a default lifetime of two years. However, you can specify a different lifetime for the CA during installation. The parent CA that approves the certificate request and issues the certificate determines the lifetime of a subordinate CA certificate. Creating a Certificate Renewal Strategy CAs continue to issue and renew certificates until they reach the end of their established lifetimes. Certificates expire when the issuing CA reaches the end of its established lifetime, unless: They are renewed with a new key pair to extend their lifetime. They are revoked before the expiration date is reached. They are considered to have expired because an issuing CA is unavailable to verify their validity. Certificate lifetimes impact the security of your PKI for the following reasons: Over a period of time, encryption keys become more vulnerable to attack. In general, the longer the period of time that a key pair is in use, the greater the risk that the key can be compromised. To mitigate this risk, you must establish maximum allowable key lifetimes and renew certificates with new key pairs before these limits are exceeded. When a CA certificate expires, all subordinate CAs that depend upon this CA for validation also expire. When a CA certificate is renewed, all certificates that have been issued by the CA must also be renewed. All certificates issued by the CA expire when the certificate of the CA is renewed, regardless of whether or not the key pair is also renewed. 798 Chapter 16 Designing a Public Key Infrastructure To reduce the risk of a private key becoming compromised, the private key and public key sets for certificates can be renewed each time the certificates are renewed, instead of when the keys reach their maximum lifetimes. You can renew CAs by assigning them a new key pair or by using the existing key pair. If you create a new key pair and the original certificate has not yet expired, it must have a new Subject Key Identifier (SKI) and a separate CRL. Renewing certificates with new key sets is not possible for some hardware-based CSPs, either because key storage limits prohibit this or because key generation takes a long time. Note For more information about configuring certificate renewal, see ―Selecting a Certificate Enrollment and Renewal Method‖ later in this chapter. For more information about the impact of certificate renewal on the use of certificate revocation lists, see ―Establishing Certificate Revocation Policies‖ later in this chapter. Certificate lifetimes affect the number of certificate renewal requests that are transmitted across your network. For users in remote offices who are connecting to the network across slow links, you might want to lengthen certificate lifetimes to reduce the number and frequency of these requests. To create a certificate renewal strategy, determine the following: Which certificates, if any, are you allowed to renew? How often can a certificate be renewed before its key is retired? In general, certificates with stronger keys that are used less frequently and that are less available to potential hackers can justify longer lifetimes and at least one renewal. Certificates with average key lengths and shorter lifetimes can be renewed more frequently — but not beyond the validity date for the certificate that authorizes the CA that issued the certificate. This is called nested validity or nested expiration. Nesting Certificate Lifetimes In addition to defining certificate lifetimes for your Windows Server 2003 CAs, you need to confirm that certificate lifetimes and renewals do not extend beyond the lifetimes of the CAs that are above them in the hierarchy. By default, the certificate for the root CA has a longer lifetime than certificates for the other CAs in the hierarchy. This is because a Windows Server 2003 CA cannot issue certificates with a lifetime that extends beyond the validity period of its own certificate. If the lifetime specified for a requested certificate type exceeds the expiration date of the certificate of the CA, the CA truncates the lifetime of the issued certificate to match the expiration date for its own certificate. Defining Certificate Configuration Options 799 For example: If the end date of a Windows Server 2003 root CA certificate is January 2, 2012, no Windows Server 2003 child CA in the chain below the root can issue a certificate with a date that is past January 2, 2012. If a Windows Server 2003 intermediate CA has a certificate end date of January 2, 2008, no Windows Server 2003 child CA can issue certificates with an end date that is past January 2, 2008. If a Windows Server 2003 issuing CA has a certificate end date of January 2, 2004, no certificate that the CA issues can have an end date that is past January 2, 2004. If the end date of a Windows Server 2003 CA certificate is January 2, 2004, and it receives a request to issue a one-year certificate on August 1, 2002, the CA issues the one-year certificate with an end date of July 31, 2003. However, if the CA receives a request to issue a one-year certificate on August 1, 2003, the CA issues the certificate with an end date of January 2, 2004. A Windows Server 2003 CA with a certificate lifetime of five years with an end date of January 2, 2007, can issue one-year certificates until January 2, 2006, or two-year certificates until January 2, 2005. After January 2, 2005, the CA does not issue two-year certificates. It truncates the validity end date to January 2, 2007. Likewise, after January 2, 2006, the CA truncates the validity end date of both one-year and two-year certificates to January 2, 2007. The more nesting you have in your certification hierarchy, the shorter the certificate lifetimes become. Configure your certificate life cycles in such a way as to avoid short certificate lifetimes and certificate renewal cycles. If you specify long lifetimes for CAs and later discover that the CAs are not secure, you can renew CAs in the certification hierarchy with shorter lifetimes to reduce the potential security risks. Note For a worksheet to assist you in preparing your certificate life cycle plan, see ―Windows Server 2003 Certificate Life Cycle Plan‖ (DSSPKI_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Windows Server 2003 Certificate Life Cycle Plan‖ on the Web at http://www.microsoft.com/reskit). 800 Chapter 16 Designing a Public Key Infrastructure Using Qualified Subordination Many of the certificates that you issue can be used without any further customization. However, you might want to limit the scope of your certificates, whether they are intended to validate a subordinate CA, to cross-certify an external CA, or to enable an end user application. You can limit the scope of a certificate by: Defining the namespaces for which a subordinate CA will issue certificates. Specifying the acceptable uses of certificates issued by a qualified subordinate CA. Creating trust between separate certification hierarchies. Qualified subordination restricts the certificates issued by the qualified subordinate CA, or by CAs that chain through the qualified subordinate CA, that are acceptable to your organization. You accomplish this by defining the following in the Policy.inf file: Note The Policy.inf file is different from the CAPolicy.inf file. The Policy.inf file impacts qualified subordination, whereas the CAPolicy.inf file impacts the CA certificate. Basic constraints. Define the certification path length required and allowed for policy identifiers and policy mapping. Name constraints. Define the range of namespaces that are permitted or excluded by the qualified subordinate CA and its subordinates. Issuance policies. Define the extent to which your organization trusts the identity presented in a certificate. These policies are identified in a certificate by object identifiers. Application policies. Define the applications that can be used in conjunction with certain certificates. In addition, if you are attempting to connect two different PKIs, whether within your organization or with a third-party, you need to use policy mapping to achieve equivalency between the policy constraints that you have defined and the policy constraints defined in the other PKI. The use of constraint extensions and policy mapping allows you to control certificate usage more effectively, and to administer your certificates more effectively. Qualified subordination allows you to ensure that specific constraints are applied when a CA issues or an application uses a certificate. These constraints ensure that all certificates issued by the CA apply the policy restrictions that you have defined. Defining Certificate Configuration Options 801 By definition, your root CA applies all policies. You can use intermediate CAs to issue certificates that enable different levels of security, such as High Security, Medium Security, and so on. The security policies that you define are identified by means of object identifiers. When certain object identifiers are applied to a CA certificate, all certificates below that CA in the hierarchy must also have a subset of those object identifiers. If you create a certificate chain with no valid policy, any certificates that are issued are considered invalid. However, if you create a certificate chain with no policy object identifiers at all, then the certificates that you issue are considered to match the ―any policy‖ object identifier. Figure 15.16 shows how policy is applied to CAs. Figure 15.16 How Policy Is Applied to CAs The policies and constraints of each qualified subordinate CA are a subset of the policies and constraints of the parent CA. 802 Chapter 16 Designing a Public Key Infrastructure Using Basic Constraints Basic constraints allow an application to determine whether a certificate is a CA certificate, which can then be used by the certificate chain engine to build certification paths, or an end-certificate, which cannot. You can also use basic constraints to limit the maximum number of CA certificates that can be included in a CA path. For example, setting a path length of zero in the basic constraints section of the CAPolicy.inf file allows only certificates issued by that specific CA to be included in the CA path. A path length of two allows only a total of three CA certificates in a certification path. In the latter case, any certification paths that include more than three CAs are discarded. Use basic constraints if you do not want to trust additional CAs that are created lower in the CA hierarchy of your organization. You can also use basic constraints in cross-certified relationships if you trust your business partner and the certificates from all their existing CAs, but you do not want to trust certificates from any additional CAs that they authorize. Using Name Constraints Name constraints allow you to designate which namespaces are either permitted or excluded for certificates issued by a qualified subordinate CA. When the qualified subordinate CA receives a request, it compares the names present in the subject and the subject alternate name fields to the configured name constraints, to determine whether the namespace is permitted or excluded. As you design your PKI, you need to decide which individual clients and business units are able to enroll for and use certain certificates. For many organizations, the selected users, computers, and services are members of specific Active Directory domains and subdomains. You can base name constraints on any of the following types of name formats: X.500 Directory name. Distinguished names identify users and resources on the network in Active Directory. This allows you to constrain a qualified subordinate CA to permit or exclude users in Active Directory by using the distinguished names of the users. Active Directory also uses distinguished names to create and reference groups of objects in the directory, such as users and computers. The distinguished names of these object groups can also be used as name constraints, allowing you to constrain a qualified subordinate CA to permit and exclude certificate issuance for entire groups in the directory. DNS domain name. You can apply the DNS namespaces that your network uses for name resolution as name constraints for a qualified subordinate CA. When the qualified subordinate CA receives a certificate request, it compares the DNS name associated with the computer requesting the certificate to its DNS name constraints and decides whether or not to issue a certificate. You can specify a DNS name constraint as a DNS host name, such as host1.example.microsoft.com, or as a DNS namespace, wherein all DNS host names are permitted or excluded, such as .example.microsoft.com. Defining Certificate Configuration Options 803 E-mail and user principal name. You can specify e-mail and UPN name constraints for an individual subject, such as email@example.com, or you can specify constraints for all subjects whose e-mail names or UPNs end in a specific name, such as @example.contoso.com. Typically, you need to specify e-mail or UPN name constraints for all subjects whose e-mail addresses and UPNs end in a specific name. Universal Resource Identifier (URI). URIs are used to identify resources on the Internet by means of identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher. When validating the URI names in a certificate request, the qualified subordinate CA ignores the protocol element in the URI, such as http:// or ftp://, and uses the domain or host names only. IP address. IP address name constraints follow the formatting conventions specified in RFCs 791 (IPv4) and 1883 (IPv6). The IP addresses contained in the certificate requests made to a qualified subordinate CA are compared to the IP addresses in the name constraints of the qualified subordinate CA. You can configure name constraints to result in the following outcomes: Permitted. The certificate request contains all names that are listed as permitted in the CA name constraints extension of the issuer. Not permitted. The certificate request contains a name that is not listed as permitted in the name constraints extension of the issuer. Excluded. The certificate request contains a name that is listed as excluded in the name constraints extension of the issuer. A CA certificate can contain name constraints that are applied to all certificate requests made to the CA. Each request is compared to the list of permitted and excluded names to determine whether the name in the certificate is considered permitted, not permitted, excluded, or not defined. When you include name constraints in a CA certificate, the following rules are applied to the subject name and alternate subject name fields: Excluded namespaces take precedence over permitted namespaces. A qualified subordinate CA will not issue a certificate to a user within an excluded namespace even if the user is also within a permitted namespace. For example, a user might be within the permitted Active Directory namespace .xyz.com but also within the excluded DNS namespace .uvw.xyz.com. The excluded DNS namespace overrides the permitted Active Directory namespace and the certificate request of the user fails. If the name constraints extension exists in a CA certificate, all name constraints must be present in the appropriate format. Any name formats that are not included are considered to be wild cards that match all possibilities. For example, if the DNS name constraint is absent, the entry is treated as DNS=―‖. 804 Chapter 16 Designing a Public Key Infrastructure All name constraints are considered, even if they are not specified. No precedence is applied to the listed name constraints. For this reason, name constraints that are not present are treated as wildcards. For example if you only restrict the DNS name space, the Name Constraints extension sets the remaining name constraints to allow all name spaces. Name constraints are applied to the Subject Name extension and any existing Subject Alternate Name extensions. For example, if a user can be identified by a DNS domain name and an alternate e-mail name, name constraints apply to both. Name constraints apply to all names contained in a certificate request. Each name in the subject or subject alternate name extensions must match at least one of the name constraints listed for that name type. A certificate request that includes a subject name or subject alternate name that does not match a listed name type is rejected. Name constraints are not case sensitive. For example, .xyz.com is treated the same as XYZ.COM or xYz.Com. Important Name constraint validation is performed on the CA, not on the client. However, you must have Windows XP and Windows Server 2003 clients in order to use name constraints. Using Issuance Policies You can use issuance policies to define the extent to which your organization trusts the identity presented in a certificate. For example, you can set an issuance policy stipulating that you only trust certificates that were issued during a face-to-face meeting with a network administrator, such as when a smart card certificate is issued. An object identifier must describe every issuance policy that you define. The inclusion of an issuance policy object identifier in an issued certificate indicates that the certificate was issued in a manner that meets the issuance requirements associated with the issuance policy object identifier. Note Issuance policy is only available on Windows Server 2003 CAs. Windows 2000 does not provide issuance policy. Defining Certificate Configuration Options 805 You can use a specific certificate template to define one or more issuance policy object identifiers that need to be included in any certificates issued. Windows Server 2003 includes four predefined issuance policies: All Issuance (126.96.36.199.0). The all issuance policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates. Low Assurance (188.8.131.52.4.1.311.21.8.x.y.z.1.400). The low assurance object identifier is used to represent certificates that are issued with no additional security requirements. Note The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Windows Server 2003 forest. Medium Assurance (184.108.40.206.4.1.311.21.8.x.y.z.1.401). The medium assurance object identifier is used to represent certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face to face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier. High Assurance (220.127.116.11.4.1.311.21.8.x.y.z.1.402). The high assurance object identifier is used to represent certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver because a person holding this certificate can recover private key material from a Windows Server 2003, Enterprise Edition CA. In addition, you can create your own object identifiers to represent custom issuance policies. For example, two organizations involved in a purchaser/seller relationship can define custom object identifiers to represent digital signature certificates for specific purchase amounts. In such a case, an object identifier can be defined for purchase between $100,000 and $500,000 and another object identifier can be defined for purchases greater than $500,000. Applications can then use these object identifiers to recognize whether a person had the appropriate signing authority for a specific volume purchase. 806 Chapter 16 Designing a Public Key Infrastructure Applying Policy Mapping In many cases, the administrators of two PKIs define their own policies and object identifiers. In some cases these policies are identical, but in most cases there are small differences between them. For example, one organization might stipulate that one physical form of identification is sufficient to grant a certificate request, while a second organization requires three forms of physical identification to grant a similar request. In these cases, you need to negotiate with the administrators of the other PKI to define terms of equivalence before the cross-certified relationship can be established. This is called policy mapping. Policy mapping enables interoperability between two organizations that apply similar issuance and application policies, but have deployed different object identifiers. If the policy object identifier (for example, 18.104.22.168) of one company represents a specific function, and the policy object identifier of another company (for example, 22.214.171.124) represents the same function, they can be mapped, so that 126.96.36.199 and 188.8.131.52 are interchangeable. The qualified subordinate CA that contains this mapping is called the issuer CA and the subordinate CA whose policies have been mapped is called the subject CA. In mapping some or all of the policies of the subject CA to the policies of the issuer, the issuer CA effectively subordinates the subject CA. The result of this mapping is that users and computers in the issuer CA trust hierarchy can use their own certification paths to validate certificates from users and computers in the subject CA trust hierarchy. The separate trust hierarchy can be within the same intranet or in separate PKI environments over an extranet. To apply policy mapping Identify the trust hierarchy with which you want to establish a trust relationship. Establish equivalence in the assurance levels used by the two trust hierarchies involved in the trust relationship. Obtain the issuance and application policy object identifiers used in both trust hierarchies involved in the trust relationship. Map the issuance and application policy object identifiers in the separate trust hierarchies, and define their policy constraints in the CA certificate request for the qualified subordinate CA that you are installing in your trust hierarchy. Install the qualified subordinate CA with the policies, policy mappings, and policy constraints in your trust hierarchy. Defining Certificate Configuration Options 807 Constraining Policy Mapping You can refine policy mapping by setting parameters for how the issuance policy defined in qualified subordination affects other CAs below the qualified subordinate CA. These parameters can help to limit unplanned trust relationships. The following two settings define this relationship: Require explicit policy. Specifies the number of certificates that can exist in the hierarchy below a certificate before an explicit policy must exist. For example, if the explicit policy is configured with a setting of three, the defined issuance policy must exist for three layers of the hierarchy. The CA on which the qualified subordination is defined is the first level. Inhibit policy mapping. Specifies the number of additional certificates that can appear in the path before policy mapping is no longer permitted. For example, an inhibit policy mapping value of three restricts the policy mapping to only three levels of CAs below the qualified subordinate CA. Using Application Policies Certificates provide important information that is not specific to an application. However, you might need to define which applications can be used in conjunction with certain certificates. Application policy allows you to ensure that certificates are only used with the applications that you specify. An application can also be written to accept only certificates that contain specific application policies. When the application receives signed information from a user, the application reviews the certificate associated with the private key used to sign the information, and ensures that the application policy extension contains the object identifiers required by the application. Application policies are similar to the Extend Key Usage (EKU) extension in a certificate, as both use one or more object identifiers to prescribe how the public key in a certificate must be used. Windows Server 2003 supports Extend Key Usage to support PKIs that use this extension, but application policies are used in place of EKU. 808 Chapter 16 Designing a Public Key Infrastructure Application policy is Microsoft specific and is treated much like Extended Key Usage. If a certificate has an extension containing an application policy and also has an EKU extension, the EKU extension is ignored. If, however, a certificate has only an EKU extension, the EKU extension is treated like an application policy extension. If a certificate has an application policy extension and an EKU property, the effective policy for the certificate is the common policy between the EKU property object identifiers and the application policy object identifiers. Note If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers. Using Constraints and Policy Mapping The method or methods that you use to limit unplanned trust depend in large part on the security challenges that you must address in your organization. For example, use name constraints to limit unplanned domain-based trusts. If your organization has more than one domain — such as companyA.com and subdomain.companyA.com — you might only want cross- certificates to map to CAs in the companyA.com domain and not to CAs in the subdomain.companyA.com domain. On the other hand, if you have five different domains and want your cross-certificates to apply to three of them, path constraints provide a more flexible solution. Use path constraints if transitive trusts create problems for your organization — for example, if you have an environment in which users can freely install subordinate CAs and you do not have strong security guidelines governing CA creation and management. Policy constraints are the most useful of the constraint options, both internally and externally. Name and path constraints might not provide you with sufficient protection in certain cross-certified relationships if the security standards of your business partners are not as strong as yours. For example, organization A might have a policy that all user certificates must be approved manually by an administrator, while organization B approves certificate requests automatically as long as the user has an e-mail account. The security administrators for organization A must ensure that the certificates that users in organization B use to access resources meet the higher security standards that are necessary in organization A. They can accomplish this by using policy constraints. Use policy mapping if the organization that you are cross-certifying with has policies that are similar to those of your organization. Policy mapping is less useful when the policies of your organization are stricter than the policies of the other organization, or vice versa. If this is the case, use policy constraints to restrict your trust relationship instead of using policy mapping. Defining Certificate Configuration Options 809 Example: Configuring Certificates After an organization has defined its certificate requirements, internal PKI configuration, and external infrastructure, it needs to determine the certificate lifetimes, encryption key lengths, renewal policies, and other restrictions, if any, that apply to the use of each type of certificate. Figure 15.17 shows the certificate design decisions of one organization. Figure 15.17 Example of a Windows Server 2003 Certificate Lifecycle Plan Worksheet 810 Chapter 16 Designing a Public Key Infrastructure For a worksheet to assist you in documenting your certificate lifecycle plan, see ―Windows Server 2003 Certificate Lifecycle Plan‖ (DSSPKI_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Windows Server 2003 Certificate Lifecycle Plan‖ on the Web at http://www.microsoft.com/reskit). All certificates are issued by Windows Server 2003 CAs. The certificates for the people working for the business partners (for the extranet) can be issued by the Windows Server 2003 CA or by the CA of the business partner. CTLs allow the extranet domain to trust the certificates of the business partners. Where appropriate, stand-alone CAs provide flexible lifetimes for CAs. The renewal of certificates with new keys limits the amount of time that keys are in use and reduces the risk of key compromise. This organization does not have unusual security requirements that require the use of one cryptographic algorithm over another. Therefore, they chose to accept the default cryptographic algorithms that have been established for each type of certificate and CA. The certificates issued to the business partners of this organization are constrained by namespace, by path length, and to specific applications. In addition, the corporation uses policy mapping to specify the authentication procedures required of business partner users who are issued certificates to access the resources of the first organization. Creating a Certificate Management Plan After you have configured certificates for your organization, you need to create a plan for managing certificates throughout their lifetimes. Figure 15.18 shows the process for creating a certificate management plan. Creating a Certificate Management Plan 811 Figure 15.18 Creating a Certificate Management Plan 812 Chapter 16 Designing a Public Key Infrastructure Selecting a Certificate Enrollment and Renewal Method To enable enrollment, you need to specify the enrollment and renewal processes for your certificates. Enrollment involves either configuring permissions to establish which security principals have Enroll permissions for specific templates (in the case of enterprise CAs) or appointing a certificate administrator who reviews each certificate request and issues or denies the request based on the information provided. Microsoft Certificate Services supports the ability to process certificate requests manually, if administrative approval is required, or automatically, if no approval is necessary. The following enrollment and renewal methods are available: Certificate autoenrollment and renewal. Allows you to automatically issue certificates that enable PKI applications, such as smart card logon, EFS, SSL, and S/MIME, to users and computers within an Active Directory environment. Certificate autoenrollment is based on a combination of Group Policy settings and certificate templates, which allows you to enroll computers when they start up and to enroll users when they log on to their domain. Note To use autoenrollment, you need a Windows Server 2003 domain controller, a Windows XP Professional client, and a Windows Server 2003 Advanced Server enterprise CA. Certificate Request Wizard and Certificate Renewal Wizard. Available from the Certificates console, you can use the Certificate Request Wizard to request a certificate from an active enterprise CA on behalf of a user, computer, or service. Note This option can only be used for Windows 2000, Windows Server 2003, and Windows XP users, computers, and services. Creating a Certificate Management Plan 813 Web Enrollment Support pages. Contain Active Server Pages and ActiveX controls that provide a Web-based user interface to a CA. By default, the Web Enrollment Support pages are automatically installed on the computer on which the CA is installed, but you can also install the Web Enrollment Support pages on another Windows Server 2003 computer. You can also customize Web Enrollment Support pages. For example, you can limit user options or provide additional links to online user instructions and user support information. Note You can use Web Enrollment Support pages on stand-alone CAs to issue most of the same types of certificates that enterprise CAs can issue, with the exception of certificates for smart card logon and for autoenrollment, which must be issued and renewed by an enterprise CA. The Web Enrollment Support pages that are installed on stand-alone CAs do not use certificate templates, so all information about the certificate, including information about the requester (and, if asking for a specific application, a correct object identifier), must be specified in the certificate request. Smart card enrollment station. Advanced version of the Web Enrollment Support pages that allows trusted administrators or security personnel to enroll for smart card certificates on the behalf of other users. For more information about using the smart card enrollment station, see ―Planning a Smart Card Deployment‖ in this book. To select the certificate enrollment and renewal processes that are appropriate for your organization, you need to consider the following: The users, computers, and services for which you intend to provide services. Determine whether they are internal or external to the organization. Identify the operating systems they are running and determine whether or not they are connected to Active Directory. The operating system that your clients are using. Clients running Windows Server 2003 and Windows XP can use the Certificate Request Wizard, autoenrollment, or the smart card enrollment station. Windows 2000 supports the Certificate Request Wizard but does not support smart card autoenrollment. Autoenrollment and the smart card enrollment station also require Active Directory. Most other clients can use their Web browsers to access Web-based enrollment and renewal services. The policies that you establish in order to manage certificate distribution. This includes both the procedural policies that you establish for your PKI, and the Group Policy settings that you use to implement those policies. The type of CA that is issuing the certificates. For example, you must have a Windows 2000 or Windows Server 2003 enterprise CA to use the smart card enrollment station. Only Windows Server 2003 CAs support smart card autoenrollment. 814 Chapter 16 Designing a Public Key Infrastructure Selecting certificate enrollment and renewal processes involves making decisions about the following: Automatic versus manual requests Automatic versus manual approval An enrollment and renewal user interface CA certificate renewal Selecting Automatic vs. Manual Requests Whether you choose to generate certificate requests automatically or manually depends on the types of certificates that you intend to use and the number and type of clients that you enroll. For example, if you want all users or computers to use a certain type of certificate, it is not practical for you to require that each certificate be requested individually. Although rolling out a new certificate to all users or computers at one time can generate a large amount of network activity, you can control that activity by deploying the certificate requests for each organizational unit one at a time. On the other hand, you might want to have users or an administrator request certain high-security certificates, such as those used for digital signing or administrative tasks, only when needed. This can improve administrative control over these certificates — particularly if certificate use is not limited by a user or computer OU, or security group membership. You can improve control over your certificates by using one of the following options to limit user certificate requests: Restrict access to specific templates. Configure the discretionary access control list (DACL) for each template so that only the required security principals have Enroll and Read permissions for particular templates. Automate the deployment of computer certificates. Configure Group Policy to automatically assign the necessary computer certificates by adding the certificate template to the Automatic Certificate Request Settings option in Group Policy. Tip Autoenrollment is most useful for issuing and renewing computer and IPSec certificates. Creating a Certificate Management Plan 815 Selecting Automatic vs. Manual Approval Users can request a certificate from a Windows Server 2003 CA either manually or automatically. This request is held until an administrator approves it, if manual approval is required, or until the verification process is completed. When the certificate request has been approved, the autoenrollment process installs the certificate automatically, or automatically renews the certificate on behalf of the user, based on the specifications in the certificate template. Most of the time, you choose the same method for certificate approval that you choose for certificate requests — but not always. For example, if you have the appropriate Group Policy and DACL restrictions on your certificate templates, you might decide to approve automatically a certificate request that was generated manually. Conversely, in some cases, it is appropriate to manually approve certificate requests that are automatically generated. Note You can use strong authentication to enhance the security associated with autoenrollment. With strong authentication, the certificate template uses a specify policy object identifier to require an additional signature on the certificate request. For example, you can set a policy that requires the use of a smart card to provide a stronger authentication method for autoenrollment requests, or you can require approval for automatic certificate requests, so that administrators must approve pending requests. However, in general: For routine and high volume certificates, such as e-mail certificates, automatic approval is the best option for certificate approval as long as the certificate requester has already been authenticated with a valid set of domain credentials. When a high degree of administrative oversight is required, such as for software code signing certificates, consider processing certificate requests manually. By using the Certificate Request Wizard, you can evaluate every certificate request individually — or you can delegate this responsibility to another administrator. Selecting an Enrollment and Renewal User Interface The user interface that you select for certificate request and approval processing depends on whether you choose automatic or manual certificate request and approval methods. If you decide to use autoenrollment for both certificate requests and certificate approval, you must use a minimal user interface. 816 Chapter 16 Designing a Public Key Infrastructure However, if all or part of the enrollment process is manual, you must decide between using the Web Enrollment Support pages or the Certificate Request Wizard. The Web Enrollment Support pages are the easier interface for users to use. Users can perform the following tasks from the Web Enrollment Support pages: Request and obtain a basic user certificate. Request and obtain other types of certificates by using advanced options. Request a certificate by using a certificate request file. Renew certificates by using a certificate renewal request file. Save a certificate request to a file. Save the issued certificate to a file. Check on pending certificate requests. Retrieve a CA certificate. Retrieve the latest certificate revocation list from a CA. Request smart card certificates on behalf of other users (for use by trusted administrators). However, administrators might prefer to use the Certificate Request and Renewal Wizard. You can start the wizard from the Certificates snap-in. Because the wizard is linked to the Certificates snap-in, you can also create custom snap-ins that you can distribute to certification authority administrators to whom you have delegated specific roles. Unless an organization uses firewalls between one part of the organization and another, you can use the Certificates snap-in or the Web interface interchangeably. If a firewall exists between the CA and the requesting client, you must request certificates by means of the Web Enrollment Support pages or ensure that port 135 and a dynamic port above 1024 is open for MMC DCOM communication. Whether you choose to use the Web Enrollment Support Pages or the Certificate Request and Renewal Wizard, you might need to prepare documentation that describes how users can request a user certificate, what users can expect after they request the certificate (for example, automatic enrollment or a delay pending administrator approval), and how they can use the certificates after they receive them. Creating a Certificate Management Plan 817 Using CA Certificate Renewal When a CA has issued and supports a large number of certificates, the quality of service and user satisfaction can decline. However, enrollment and renewal are relatively infrequent activities that can be anticipated and therefore planned for well in advance. Many organizations fail to plan for certificate renewal because this activity does not occur until some point well into the future. When the certificate of a CA expires, the CA can no longer provide certificate services. To provide uninterrupted certificate services, use the Certificates console to renew the CA certificate before its expiration date. The interval that is required for CA renewal depends on the certificate lifetime of the CA. After you renew a CA, the CA continues to issue certificates by using the new CA certificate, and the cycle starts over. Unexpired certificates that were issued by the pre-renewal CA continue to be trusted until they expire or are revoked. You can use the standard enrollment and renewal methods that are available in Windows Server 2003 to renew your CAs and certificates. You can renew certificates with the same private key and public key set or with new private and public keys. However, if you have special needs, you can develop custom certificate enrollment and renewal applications for CAs. Caution Do not renew certificates with the same private and public key sets if the renewal period exceeds the maximum safe key lifetime. The safe key lifetime is based on your choice of key lengths. Longer keys allow for longer safe key lifetimes. The Windows Server 2003 Certificate Services Entry module supports industry-standard certificate requests by using remote procedure call (RPC) requests or HTTP requests. You can develop custom applications that make certificate requests to Certificate Services CAs. For more information about developing custom applications on Windows Server 2003 Certificate Services, see the Microsoft Platform SDK link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. 818 Chapter 16 Designing a Public Key Infrastructure Mapping Certificates to User Accounts After you have decided how you are going to distribute your certificates, you must decide how to get the certificates to the intended clients, whether they are computers, internal users, or external users. You need to use certificate mapping for many types of certificates, such as those used for smart card logons. If you have Active Directory, you can map certificates to clients based on their domain or organizational unit membership. You must decide how you define subject and issuer name information in certificates because this directly impacts applications that use PKIs. For example, if a certificate does not contain the e-mail address name as part of the Subject or Subject Alternative name, some older e-mail applications cannot accept the certificate for digitally signing or encrypting e-mail messages. Certificate mapping allows you to provide a more secure method for user authentication. With certificate mapping, you link a specific certificate to the account of a user. A server application can then use public key technology to authenticate the user by means of this certificate. When certificate mapping is enabled, users are authenticated in Active Directory on the authority of the mapped certificates, and are granted rights and permissions based on the authentication. You can map certificates to user accounts in the following ways: One-to-one mapping. This creates an association between an individual certificate and a corresponding user account in Windows 2000 or Windows Server 2003. Many-to-one mapping. This creates an association for all certificates from a specific CA to a Windows 2000 or Windows Server 2003 user account. You can also use certificate mapping to authenticate external users who do not have an account in Active Directory. Using One-to-One Mapping One-to-one mapping requires more administrative effort than many-to-one mapping. Use one-to-one mapping when you have a relatively small number of clients. If you decide to use one-to-one mapping for a large number of clients, develop custom Web enrollment pages by using Active Server Pages (ASP) technology to automate the mapping process. Creating a Certificate Management Plan 819 Using Many-to-One Mapping Many-to-one mapping is useful for authenticating large numbers of users who require access to a given resource on your network, such as an internal Web site. The CA that issues certificates to these users must be chained to a trusted root for your site, domain, organizational unit (OU), or forest. You can then set rules that map all certificates issued by that CA to a single user account in Windows Server 2003. Mapping rules check the information that is contained in the certificates of users, such as user organization and the issuing CA, to determine whether the information matches certain criteria. When the information in a user certificate matches the criteria, the user is mapped to a specified user account. The permissions set on the user account apply to all users who hold certificates issued from the trusted CA. You can use separate many-to-one certificate mappings for different groups that require access to resources on your network. You can configure user accounts that grant different sets of rights and permissions on the basis of client ownership of valid certificates that match the mapping rules. For example, you can map your employees to a user account that grants read access to the entire Web site. Then, you can map consultants and employees of business partners to other user accounts that allow access only to non-confidential information and selected proprietary information. Selecting IIS vs. Active Directory Mapping You can use either Internet Information Services (IIS) or Active Directory to create your mapping. When IIS does the mapping, the certificate is compared to a list of rules that IIS maintains in its database until it finds a rule that matches the account indicated. You can configure IIS mapping for each Web server. This type of mapping is useful if you need only a limited number of mappings or a different mapping on each Web server. In Active Directory mapping, when the IIS server receives a certificate from the user, it passes it on to Active Directory, which maps it to a Windows 2000 or Windows Server 2003 user account. The IIS server then logs on the account. You can create an Active Directory mapping in one of two ways. You can rely on UPN mapping, or, if UPN mapping is not possible, you can manually map a certificate to the account of a user. Use Active Directory mapping when the account mappings are identical on all IIS servers. Active Directory mapping is easier to maintain than IIS mapping because you only have to create the mapping in one location. For more information about creating a mapping, see ―Mapping certificates to user accounts‖ in Help and Support Center for Windows Server 2003. 820 Chapter 16 Designing a Public Key Infrastructure Establishing Certificate Revocation Policies All certificates have specified lifetimes. However, in some situations, you might need to invalidate a certificate before it has reached the end of its lifetime. Creating policies for certificate revocation involves the following tasks: Defining the conditions that warrant the revocation of a certificate. Selecting a certificate revocation list publication location. Selecting the type or types of CRLs that you intend to use. Establishing schedules for the publication of CRLs. Establishing a cached CRL validity period. Defining Conditions for Certificate Revocation Not all PKIs need to be supported by the publication of CRLs. For example, if your certificates provide only a low- or medium- level of security and are unlikely to be misused, or if they have short lifetimes, there might not be a need to create and distribute lists of revoked certificates. If, on the other hand, your certificates have a high perceived value and a lifetime that is long enough to cause potential misuse, you need to create and distribute certificate revocation lists on a regular basis. Before you create certificate revocation schedules, define all the circumstances that justify the revocation of certificates in your organization. For example, you might choose to revoke certificates for any of the following reasons: An unauthorized user has gained access to the private key of the certificate. An unauthorized user has gained access to the CA. In this case, all the certificates that the CA has published must be revoked and reissued. Certificate criteria have changed; for example, an employee has moved to a different department. The certificate has been superseded. For example, you might decide to use a different encryption protocol or a longer key. Creating a Certificate Management Plan 821 The CA that issued the certificate is no longer operating. The status of the certificate is on hold. When a certificate has been revoked, it cannot be renewed. However, if the status of a certificate is questionable, you can revoke it and then rescind the revocation if necessary, or re-revoke it for another reason. Note Use Certificate Hold sparingly because issues can develop involving the period that the certificate was on hold. For example, if a certificate was on hold for three hours but the hold is then removed, attempts to use the certificate during the hold period can yield unexpected results. Users misuse their security permissions or the private keys of users are compromised (a smart card is lost, for example). A computer is replaced or permanently removed from service, or the private key of the computer is compromised. Note A root certificate cannot be revoked by means of a CRL because a root CA is self-signed. A CRL includes only certificates that are issued by a dedicated CA. The alternative is to revoke all the certificates issued by the root CA. The CA certificate becomes obsolete if there are no more valid certificates. Selecting a CRL Publication Location Selecting a location for CRL publication involves answering the following questions: Are the certificate revocation lists needed internally, externally, or both? CRLs have to be published where they can be accessed to validate or invalidate certificates. If the PKI is within the firewall of the organization and certificates are published to Active Directory, then LDAP can be used to publish CRLs. If the certificates are used outside the organization or if there is no directory service, http can be used to publish CRLs to a Web server because HTTP traffic can travel more reliably through a firewall than LDAP traffic. Do you require multiple CRL publication locations for fault tolerance or to support greater numbers of geographically diverse clients? If the answer is yes, choose the domain controllers and Web servers that provide you with greater coverage and improved response times. This way, if one CRL publication point becomes unavailable, the information is available from other publication points. Figure 15.19 shows this decision process. 822 Chapter 16 Designing a Public Key Infrastructure Figure 15.19 Selecting a CRL Publication Location Selecting a CRL Distribution Point Because CRLs are valid only for a limited time, PKI clients need to retrieve a new CRL periodically. Windows Server 2003 PKI applications look in the CRL distribution point extension for a URL that points to a network location from which the CRL object can be retrieved. Because CRLs for enterprise CAs are stored in Active Directory, they can be accessed by means of LDAP. In comparison, because CRLs for stand-alone CAs are stored in a directory on the server, they can be accessed by means of HTTP, FTP, and so on as long as the CA is online. Therefore, you should set the CRL distribution point after the CA has been installed. The system account writes the CRL to its distribution point, whether the CRL is published manually or is published according to an established schedule. Therefore you must ensure that the system accounts for CAs have permission to write to the CRL distribution point. Because the CRL path is also included in every certificate, you must define the CRL location and its access path before deploying certificates. If an application performs revocation checking and a valid CRL is not available on the local computer, it rejects the certificate. Creating a Certificate Management Plan 823 You can modify the CRL distribution point by using the Certification Authority MMC snap-in. In this way, you can change the location where the CRL is published to meet the needs of users in your organization. You must move the CRL distribution point from the CA configuration folder to a Web server to change the location of the CRL, and you must move each new CRL to the new distribution point, or else the chain will break when the previous CRL expires. Note On root CAs, you must also modify the CRL distribution point in the CAPolicy.inf file so that the root CA certificate references the correct CDP and AIA paths, if specified. If you are using certificates on the Internet, you must have at least one HTTPs-accessible location for all certificates that are not limited to internal use. Selecting a CRL Type Windows Server 2003 includes two types of CRLs: base CRLs and delta CRLs. Base CRLs include a complete list of revoked certificates, and therefore they can grow quickly in organizations that issue a large number of certificates. Because updating base CRLs consumes a large amount of network bandwidth, you must weigh the benefits of publishing expired certificates against the costs in terms of time and network resources. Base CRLs must be published frequently to ensure that they remain current. Delta CRLs enable you to simplify CRL management. A delta CRL contains information only about the certificates that have been revoked after the last base or delta CRL was published; therefore the data in a delta CRL is accurate throughout its lifetime. Because delta CRLs are smaller than base CRLs, they require less bandwidth to replicate across the network, and they can be published more frequently, thereby enhancing the security of your PKI. By combining base and delta CRLs, you can maximize the effectiveness of the CRLs in your organization and reduce the management effort required. Whether to use delta CRLs in conjunction with your base CRLs depends on the following factors: Compatibility. Only Windows XP clients can recognize delta CRLs. Volume. If you revoke a large number of certificates, your delta CRLs can approach base CRLs in size. Therefore, it is not useful to use delta CRLs when large numbers of certificates are revoked between base CRL publication dates. Online status. It is best if delta CRLs are not used with offline CAs. Figure 15.20 shows the process for selecting a CRL type. 824 Chapter 16 Designing a Public Key Infrastructure Figure 15.20 Selecting a CRL Type Establishing a CRL Publication Schedule CAs publish CRLs listing the serial numbers of certificates that have been revoked according to an established publication schedule. The frequency of publication is based on the number of changes that take place in a given period of time, and how critical the need to maintain up-to-date revocation information is to your organization. As you create your CRL policies, you need to specify publication schedules for CRLs. By default, enterprise CAs publish CRLs weekly to Active Directory, and stand-alone and enterprise CAs publish CRLs weekly to a directory on the CA server. For example, you can specify that certain CRLs are distributed to Web pages as well as to Active Directory, and that certain CRLs are published daily instead of weekly. If you use delta CRLs, a typical publication schedule might look like this: Publish base CRLs every week. Publish delta CRLs every day. Creating a Certificate Management Plan 825 The CRL schedule for the certificates of your issuing CA must account for potential network and server downtime. In addition, it must account for latency in Active Directory replication. For these reasons, make the CRL publication schedule longer than the maximum replication latency. Make sure that your publication schedule is shorter than the validity period of the CRL. With a validity period of one week, your CRL will be up-to-date for most purposes. If you require an additional buffer to protect against interruptions in communications, you can publish the CRL every two days. Your strategy for renewing CAs also impacts your CRL publication strategy. If you choose to reuse the existing key pair when you renew a certificate for a CA, the existing CRL covers certificates issued under both the old and new CA certificates. If you choose to renew certificates by using a new key pair for the CA, you need to issue one CRL for the certificates issued with the old key pair, and another CRL for certificates issued with the new key pair. Although both old and new certificates were issued by the same CA, the validity of the older certificates will be validated against one CRL, and the validity of the newer certificates will be validated against the other CRL. Note CRLs are published for all CA keys. You cannot selectively publish a CRL for only one CA key pair. Setting the Cached CRL Validity Period To reduce the amount of network bandwidth needed to retrieve CRLs, the CRL that is specified in the CRL attribute of the certificate is cached on the client system using the certificate. You can control the schedule by which the client retrieves updated CRLs by setting the CRL lifetime. CRL publication and client use of the most recent CRL are independent. The client does not retrieve a new CRL from its distribution point unless the lifetime of a matching cached CRL has expired. Therefore, when you set the CRL validity period, be sure to balance the intended and actual CRL lifetime. The only way to force a client to retrieve the latest CRL from the CRL distribution point before the CRL cache on the client has expired is by clearing the CRL cache — a task that is difficult to perform in many networks. 826 Chapter 16 Designing a Public Key Infrastructure Planning for Data Recovery and Key Recovery If public key pairs and certificates are lost due to system failure, it can be time consuming and expensive to replace them and the data that they protect. For this reason, as part of your certificate management plan, you need to evaluate the potential consequences of loss of public keys and the data that they secure, and create a strategy for data and key recovery. Data recovery is a process by which data is encrypted in such a way that more than one person can retrieve the data in plaintext form. Data recovery does not always imply that private key recovery has occurred; however, key recovery is one method for data recovery. Use data recovery if you need to be able to recover data in your organization, but do not need to have access to individual private keys of users. The advantages of data recovery include: It does not require a certification authority or PKI infrastructure. Data recovery policies can be managed centrally by means of Active Directory. Users do not have to manage certificates or private keys for data recovery. Decryption can be limited to the user alone. The disadvantages of data recovery include: An administrative process must recover user data. Users cannot recover their own data. You cannot define the scope of what data can be recovered by a data recovery agent and what data cannot be recovered by a data recovery agent. Data recovery occurs manually on a file-by-file basis. Only data is recovered, and not the user keys. Therefore, after data recovery is completed, the user must re-enroll for new certificates. It is assumed that, when a key is lost, the certificate is compromised. Therefore, administrators must revoke old certificates. Stand-alone workstations or workstations in non-Active Directory environments cannot be centrally managed. Key recovery allows a trusted agent to gain access to user private keys. For this reason, it is best to use key recovery only if your organization permits a person other than the original requester to have access to the private key of another user. Creating a Certificate Management Plan 827 Use key recovery if organization policy permits the retrieval of user private keys and certificates. Key archiving and recovery implies that a person such as an administrator can gain access to the private keys of another user. Even when policies and procedures are in place to protect against unauthorized key recovery, issues with non- repudiation might still exist. If your organization does not permit a person other than the original requester to have access to the private keys of another user, do not implement key archival and recovery. The advantages of key recovery include: Users do not have to re-enroll for certificates, change security settings, and so on. Existing certificates do not have to be revoked. Users do not have to recover any data or e-mail due to lost private keys. All data encrypted by means of a public key in a certificate can be recovered after a private key has been recovered. Windows Server 2003 does not accept signing keys for archival and recovery. The disadvantages of key recovery include: User key recovery is a manual process that must be performed by administrators and users. Key recovery allows administrative access to the private keys of users. Non-repudiation assurance might not be available with key archival and recovery. Key recovery does not work with hardware security tokens such as smart cards. Note Only a Windows Server 2003 Enterprise Edition CA can implement Windows Server 2003 key recovery. Windows Server 2003 includes a new certificate template to support the key recovery agent role. A Windows Server 2003 CA can use only key recovery agent certificates that have been properly formatted and that have not expired. To enable key recovery, you need to complete the following tasks: Configure the key recovery agent template. Configure the CA to allow key archiving. Enroll and archive users. Do not use either data recovery or key recovery if your organization wants to protect data from all parties except for the original user. 828 Chapter 16 Designing a Public Key Infrastructure Configuring the Key Recovery Agent Certificate Before you configure a key recovery agent certificate, you must decide which users or groups can have Read and Enroll permissions on the key recovery agent certificate template. By default, only an Enterprise Administrator or a Domain Administrator can request a key recovery agent certificate. If you choose to change these defaults, you need to configure the new Read and Enroll permissions on the template itself. You must configure an enterprise CA to issue key recovery agent certificates. When you have configured permissions on the key recovery agent template and authorized an enterprise CA to issue key recovery agent certificates, a user with the appropriate permissions can request a key recovery agent certificate. You must also select an encryption key length for the key recovery agent certificate. An encryption key of 2,048 bits satisfies most security needs. Keys that are 8,192 bits or larger can take the client CSP several hours to generate and can slow down public key operations on the CA when keys are archived. You must mark the keys as exportable to enable the key recovery agent to export the private keys from the local store of the workstation to a floppy disk or other medium for safe storage. It is also best to protect the key recovery agent certificate private key with a strong password requirement. You can use a smart card as a key recovery agent. The default key recovery agent certificate template requires manual approval of requests for key recovery agent certificates. It is best if a certificate manager manually approves all key recovery agent certificate requests. The certificate manager might choose to use fewer key recovery agents than the number of available key recovery agent certificates. In this way, no individual key recovery agent can decrypt all the private keys in the CA database. The CA chooses the key recovery agent certificate randomly as a means to ensure that the key recovery agent selection is not predictable. Several cautions apply to key archiving. First, the default templates in Windows Server 2003 do not allow for key archiving. You must create new version 2 templates, which are available only in Windows Server 2003, Enterprise Edition, to support user enrollment with archiving. Second, although you can configure the cryptographic service providers that are used for the private keys that are to be archived, you can only archive keys that are generated by means of a Rivest-Shamir-Adleman (RSA)- based CSP. The Digital Signature Standard (DSS) and Diffie-Hellman CSPs are not supported for key archiving. Creating a Certificate Management Plan 829 Establishing Key Recovery Agent Policies Allowing someone other than the original user to recover keys presents a security risk. Although you trust your administrators, there are limits to how much any individual can be trusted with the ability to recover other the key pairs of other users. For example, your key recovery agent might leave the organization, taking a copy of the key. Therefore it is recommended that you monitor key recovery plans carefully. Consider limiting the time that any one individual serves as the key recovery agent, or consider dividing the responsibility between several individuals and requiring that a smart card be used to perform key recovery tasks. In addition, employ the following key recovery strategies: If you know that a key has been compromised, revoke it immediately. Do not recover keys or certificates that are used to secure high-value transactions or are associated with high-value certificates. Do not archive or recover private keys that are used for signing. This creates uncertainty in situations in which non-repudiation is the primary concern. If possible, recover encryption keys only after the original certificates have been revoked. Issue a new key at the time of recovery. Revocation ensures that the user can still decrypt data with the old key but cannot encrypt new data. Educating Users Although the process of certificate enrollment and use is nearly transparent to end users, it is important to educate users about certificates and their use. Specifically, be sure to provide end users with the following information: How to use the certificate enrollment user interface and certificate-enabled applications. The capabilities of certificates. The limitations of certificates. Inappropriate or ineffective uses for certificates. How to evaluate certificates received from others. The importance of retaining expired certificates. What to do in the event of an error message or if certificates fail to function as expected. 830 Chapter 16 Designing a Public Key Infrastructure Example: Creating a Certificate Management Plan A PKI cannot be effective and secure unless an organization implements a management plan that includes strategies for enrolling and renewing certificates, mapping certificates to user accounts, revoking certificates and distributing CRLs, and using key recovery. Many organizations base their certificate enrollment and renewal methods on the level of security associated with each type of certificate and the volume of certificate requests that they anticipate. For example, an organization makes the following decisions regarding certificate enrollment and renewal: Autoenrollment is the preferred enrollment method for e-mail and EFS certificate requests, which represent the majority of their certificate activity. Only clients who have already been authenticated by the network can request these certificates. The risks associated with the use of these certificates are relatively low. Manual approval is required for all certificates that are needed to perform network administration and software development. Manual approval is required for certificates that are issued to joint venture partners. The basic user certificates of the organization (for e-mail and EFS) are distributed according to the domain membership of a user. The distribution of high-security certificates is enforced with a one-to-one mapping. This is intended to further enforce the usage restrictions that have been placed on these certificates. Also, to improve the ability of the organization to define which file shares and other resources are available to their joint venture partners, a many- to-one mapping to a single account in Active Directory restricts their joint venture certificates. Similarly, organizations are concerned about the timeliness of CRLs associated with their high-security certificates. Therefore, they decide to distribute CRLs for these CAs once a day, with delta CRLs published every two hours, or as needed. Because network bandwidth and replication can impact the distribution of CRLs and delta CRLs to their remote offices, they choose a less stringent publication schedule for their medium security CAs — new CRLs are published once a week, and delta CRLs are published at the close of every business day. Publishing at the end of the business day ensures that the updated information is replicated overnight and is available on the next business day. Deploying the PKI After your public key design has been validated and refined by lab testing and pilot programs, you can deploy the PKI in your production environment. A disciplined approach to deploying a PKI is absolutely essential in order to establish the security of the applications that you are enabling. Figure 15.21 shows the PKI deployment process. Deploying the PKI 831 Figure 15.21 Deploying the PKI Important Advanced planning is critical to the success of your PKI. Therefore, it is strongly recommended that you complete your PKI design before you deploy your PKI. 832 Chapter 16 Designing a Public Key Infrastructure Schedule Production Rollout For large enterprise deployments, schedule the public key production rollout in stages. You can roll out different portions of the infrastructure at different times as necessary to support your security goals and business needs. For example, you might begin by deploying EFS and IPSec because you do not have to establish a large CA hierarchy to take advantage of the security benefits of these features. You might place the next highest priority on secure mail and smart card authentication. You can schedule the rollout of the secure mail infrastructure before rolling out the smart card infrastructure, or you can choose to schedule the deployment of secure mail to one group or site and simultaneously roll out the smart card infrastructure to another group or site. Important In many organizations, responsibility for the PKI deployment is transferred from a high-level design team to a more tactically focused implementation team at this time. If this is the case in your organization, be sure to provide the implementation team with all the documentation, including worksheets that you have created up to this point. Install Certification Authorities Most organizations require a CA hierarchy to provide the required certificate services to meet their security and business needs. If you plan to use a CA hierarchy, you must install the root CA first and then install each subordinate CA in the hierarchy. For example, to create a three-level CA hierarchy and trust chain, install CAs on server computers in the following order: 1. Root CA Intermediate CAs Issuing CAs For more information about installing CAs, see ―Installing and configuring a certification authority‖ in Help and Support Center for Windows Server 2003. Install Offline Root CAs In addition to the configuration options that you selected for your offline root CA, configure the following options when installing your offline root CA: Select Certificate Services Web Enrollment Support. Hosting the Web Enrollment service for an Offline Root CA on a separate system forces you to run both systems during the enrollment or renewal of subordinate CAs, which requires you to enable network connectivity between the two systems at that time. Deploying the PKI 833 In the Public and Private Key Pair dialog box, leave the default CSP selection (Microsoft Strong Cryptographic Provider) and default Hash selection (SHA-1). Increase the Key length to meet your needs — for most root CAs, use the largest interoperable key length (4,096 bits). Note For the purposes of Microsoft CAs, the Strong and Enhanced CSPs are considered equivalent. Both provide support for large key lengths (1024- bit keys or greater). Also, it is recommended that you use a hardware cryptographic service provider (CSP) or Hardware Security Module (HSM) to enhance the security of the signing keys of the certification authority. If you are installing a stand-alone CA as the root CA, the CA identification data must be entered manually. If you plan to publish the root CA certificate and CRL in your Active Directory environment, you have to enter the namespace of your Active Directory forest as the distinguished name suffix. In the CA Identifying Information dialog box, enter a customized distinguished name if you plan to publish your offline CA to a directory other than Active Directory. Use a customized distinguished name if you plan to use the offline CA as a trust anchor outside the enterprise. Note The Common name for this CA field must be filled in, but the customized field distinguished name suffix is optional. Your common name and distinguished name for the CA must reflect the organization and purpose of the CA to make the CAs easy for administrators and users to identify. The name of the CA must be unique within the organization, and possibly outside the organization as well. This information is filled in automatically if your CA is joined to an Active Directory–based domain. When you are asked to enter the Data Storage Locations, format the paths as local paths (such as C:\WINDOWS\System32\CertLog). Note Although it is generally good practice to place the Certificate Database and Certificate Database log directories on a separate volume from the system partition, you do not need to do this for a root CA. The only data that is generated and must be stored concerns the certificates that correspond to a few subordinate CAs. 834 Chapter 16 Designing a Public Key Infrastructure Install Intermediate and Subordinate CAs When installing Windows Server 2003 intermediate and issuing CAs, you can request the CA certificate from an online CA, or you can save the certificate request to a request file and make the certificate request offline. If you make an offline CA certificate request, the CA is not valid immediately upon installation. You must use the Certification Authority MMC snap-in to import the certificate of the CA and complete the installation process after the parent CA signs the CA certificate. You can also use the Certification Authority MMC snap-in to import subordinate CA certificates that are issued by third-party parent CAs. Publish the Offline CA Certificate Use secure procedures to publish the certificate and certificate revocation list (CRL) of the offline root CA. You only need to publish the certificate of the root CA one time. However, the CRL for the root CA must be published at regular intervals that correspond to the CRL publication interval value configured in the Revoked Certificates Properties of the root CA. If the root CA is maintained in a secure location, such as a data center or vault, it is best if more than one administrator or trusted person publishes the offline CRL within that location, as prescribed in the certificate policy and certificate practice statements for your organization. After the CRL is published, you must transfer it manually from the data center or vault to a location where it can be distributed to your CRL distribution points. Publish the offline CRL at least several days before the previously issued CRL is set to expire. This allows you to correct any hardware problems or publication failures in advance, ensuring that no interruption in service happens when your offline CRLs are published and replicated to all CDP locations. After the offline root CA is installed, configure the various constraint and policy options for certificates that the offline CA issues. These extensions are necessary to ensure that the applications and clients that use the certificates in the hierarchy can perform revocation and chain building as needed. Apply CA Policy If you intend to implement your certificate practice statement, you need to create and format a issuer policy statement file, and place this file in the %windir% path of the root or subordinate CA before the CA is installed. This file, named CAPolicy.inf, serves two purposes: It provides basic information about the root CA, such as distribution points for the self-signed certificate, and the object identifier (also known as OID) information. It includes information for certificate renewal, such as the certificate lifetime of the self-signed certificate. Deploying the PKI 835 CAPolicy.inf is processed for root CA and subordinate CA installations and renewals. The CDP and AIA extensions in CAPolicy.inf are used for root CA installations and renewals only. Subordinate CA certificates inherit the CDP and AIA extensions of the issuing parent CA. The CPS statement extension is applied when root CA certificates and subordinate CA certificates are requested. The CAPolicy.inf mechanism can only be used to include a CPS statement extension in a CA certificate and not an end-client certificate. Important When CAPolicy.inf is used to install a CA, it must also be used for renewal; otherwise, the settings that have been defined might not be retained when the CA keys are renewed. For more information about creating and using CAPolicy.inf files, see ―Installing and configuring a certification authority‖ in Help and Support Center for Windows Server 2003. Configure CDP and AIA Extensions After a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) and CRL distribution point (CDP) extensions before the CA issues any certificates. The AIA extension specifies where to find up-to-date certificates for the CA. The CDP extension specifies where to find up-to-date CRLs that are signed by the CA. These extensions apply to all certificates that are issued by that CA. Configuring these extensions ensures that this information is included in each certificate that the CA issues so that it is available to all clients. This ensures that PKI clients experience the least possible number of failures due to unverified certificate chains or certificate revocations that can result in unsuccessful VPN connections, failed smart card logons, or unverified e-mail signatures. Follow these guidelines when configuring CDP extension URLs: Avoid publishing delta CRLs on offline root CAs. Because you do not revoke many certificates on an offline root CA, a delta CRL is probably not needed. Adjust the default LDAP:/// and HTTP:// URL locations on the Extensions tab of the certification authority Properties page according to your needs. Do not remove the local CDP location, however. The CA requires the local CDP location in order to publish the CRL to itself. The CA uses the local CRL to validate all certificates before they are issued to users. The local path does not show in the CDP extension of issued certificates. Enable the publication of delta CRLs, regardless of whether delta CRLs are going to be published, to allow for the potential use of delta CRLs in the future. Enable delta CRL publication by selecting the Publish Delta CRLs to this location check box. 836 Chapter 16 Designing a Public Key Infrastructure Publish both the LDAP and HTTP URLs for CDP locations to enable clients to retrieve CRL data with HTTP and LDAP. If required, publish a CRL on an HTTP Internet or extranet location so that users and applications outside the organization can perform certificate validation. Consider using Active Directory–based publication. An LDAP certificate revocation list URL distributed by means of Active Directory is replicated in a fault-tolerant, distributed, highly available manner. However, replication of CRL data among Active Directory domain controllers introduces some latency. For certificates that are to be validated by clients that use Active Directory, place the LDAP CDP location first in the list to optimize client revocation checking. Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved. Provide an additional HTTP CDP location or an alternative LDAP path to CRLs for clients that cannot use Active Directory or LDAP. Follow these guidelines when publishing HTTP-based CRLs: If you are providing an HTTP CDP location, use round robin DNS or Web server virtual names to provide redundancy in the HTTP URL. Use HTTP CDP locations to provide accessible CRL locations for non-Windows brand operating system clients. Place HTTP CDP URLs second in the list of the URLs in the CDP extension if the CRL is distributed with Active Directory as well. Configure Certificate Templates By default, Windows Server 2003 enterprise CAs are enabled upon installation to issue a variety of types of certificates. You can use the Certification Authority MMC snap-in to make the following modifications to this default configuration: Specify the certificate types that are to be issued by each CA. Delete any default certificate templates that you do not want the CA to issue from the certificate templates container. Add additional certificate templates that the CA can issue. You can configure CAs to support one or multiple security functions by: Configuring root or intermediate CAs to issue subordinate certification authority certificates only. Configuring an issuing CA that supports secure Web communication services to issue authenticated session, computer, and Web server certificates only. Deploying the PKI 837 Configuring an issuing CA that supports general business users to issue user certificates only, or configuring a CA that supports administrators to issue administrator certificates only. Configuring an issuing CA that supports smart card enrollment to issue smart card logon and smart card user certificates only. The access control lists (ACLs) for each certificate template control the permissions needed to request certificate types. An enterprise CA grants certificate requests only for users, computers, or services that have the Enroll permission selected in the ACLs for that certificate template. The ACLs for certificate templates are preconfigured to enable various default user accounts and security groups to enroll for certificate types. You can use the Certificate Templates MMC snap-in to modify the ACLs for each certificate template. For example, by default, only members of the Domain Administrators security group can request and obtain enrollment agent certificates. However, to specify that only certain members of your security department can request and obtain enrollment agent certificates, you can change the ACLs for the enrollment agent certificate template. You can remove domain admins from the ACL and add the appropriate user accounts or security groups. For Windows Server 2003 stand-alone CAs, information about the certificate type must be included in the certificate request because stand-alone CAs do not use certificate templates. You can use stand-alone CAs with custom policy modules and custom certificate request applications to control the types of certificates that are issued. For more information about creating custom policy modules, see the MSDN Online and Microsoft Platform SDK links on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Configure Public Key Group Policy You can use the Group Policy MMC snap-in to configure the following optional categories of public key Group Policy for sites, domains, and organizational units: EFS Recovery Agents. By default, the local Administrator user account for the first domain controller installed in the domain is the EFS recovery account for that domain. You can specify alternate encrypted data recovery agents for EFS by importing into the policy the EFS recovery agent certificate for the appropriate alternate agent. You must first issue EFS recovery agent certificates to the user accounts on the local computers that you want to use as alternate recovery agents. Automatic Certificate Enrollment. You can specify automatic enrollment and renewal for computer certificates. When automatic enrollment is configured, the specified certificate types are issued to all computers within the scope of the public key Group Policy. Computer certificates issued by means of automatic enrollment are renewed from the issuing CA. Automatic enrollment does not function unless at least one enterprise CA is on line to process certificate requests. 838 Chapter 16 Designing a Public Key Infrastructure In addition, you can use Group Policy to configure a number of CA trust options. Group Policy trust is configured and enforced within a single domain only. This allows different users in different domains to trust different root CAs. When possible, manage trust of third-party root certification authorities by using Group Policy, and limit their scope by using qualified subordination. Third-party root CAs can be constrained by namespace and purpose to prevent unwanted trust and namespace violations within the organization. Group Policy trust configuration is found in the computer policy for \Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities. Users inherit policy from the computer policy. You can enable all computers and users to trust a root CA by adding the root CA certificate to Group Policy. You can configure the following alternate trust options by selecting the Trusted Root Certification Authorities node in the Domain Security Policy MMC snap-in: Enable or disable the ability for users to trust root CAs on a per-user basis. Use this option to disable users from trusting a root CA outside the Enterprise root trust, Group Policy, the default computer store root CA list, and the list of root CA certificates provided by Windows Update. Allow both Enterprise CA trust and third-party CA trust or only Enterprise root trust. You can disable trust of third-party root CAs in the domain outside the enterprise root CA trust, including root certificates downloaded from the Windows Update. This disables user installation of root CA certificates. Note Disabling third-party CAs can impact user access to applications such as SSL-secured Web sites. Configure CRL Publication When you have updated the CDP extensions on the CA, you need to publish a new CRL so that all clients can access the new CRL data. For more information about configuring CRL publication, see ―Manage certificate revocation‖ in Help and Support Center for Windows Server 2003. Deploying the PKI 839 Modifying the Default Certificate Publication Period Certificates that are revoked prior to expiration remain in a published base CRL for one full base CRL period (defined by the CA) after they expire. Certificates that expire are no longer included in published CRLs after one additional base CRL expires. Although applications do not check CRLs for certificates that have expired, you might in some cases want to maintain a public list of signing certificates that have been revoked. You can enable a registry setting on a CA to ensure that revoked certificates that have expired are not removed from the CRL. To modify the default CRL publication period for revoked and expired certificates on a CA At the command prompt, type: certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS Ensuring Application Reliability Many applications rely on CRL availability and fail if the CRL is inaccessible or out-of-date. Follow these guidelines when publishing CRLs to ensure the reliability of your applications: Configure the CRL to be valid for a long enough period of time to allow for the recovery of the CA if there is a hardware or software failure. Set a reasonable CRL overlap period to protect against CRL publication or replication failures. Keep the private key of the CA and a copy of the CRL in a secure offline location so that you can sign and publish a valid CRL manually by using Certutil.exe when a catastrophic failure occurs. Use Active Directory to publish CRLs whenever possible. This maximizes availability and network performance. However, always consider the amount of time needed to replicate Active Directory data between domain controllers. Do not publish CRLs to Active Directory when the CRL publication period is shorter than the replication convergence time for the Active Directory forest. To prevent the use of a logon certificate, disable the account in Active Directory. 840 Chapter 16 Designing a Public Key Infrastructure Controlling CRL Size You can partition a base CRL to control its size. In this way, you can control the amount of data that is replicated to Active Directory and the size of the data object that clients download when they perform revocation checks on certificates. You partition base CRLs by renewing the CA key. This creates a partitioned CRL for all certificates that are issued after the key is renewed. The CRL increases by about 29 bytes for every certificate that is revoked, depending on the reasons that you specify for the revocation. You might want to use a new key to renew the CA every time it reaches 100- 125 kilobytes (KB) in size, to minimize download times. This strategy is based on the assumption that approximately 10 percent of the certificates that you issue are revoked before their natural expiration date. If your actual or planned revocation rate is higher or lower than this, adjust your key renewal strategy as needed. Removing Expired CRLs By default, a CA maintains an expired CRL in the database and keeps it in the directory at the last known CDP publication point. As soon as the key for a CA expires, the CRL is published a final time and no additional changes are made to that CRL. It is recommended that you maintain this CRL in the CA database to allow for long-term validation and auditing. You can, however, remove the CRL to clean out the database. To remove a CRL after a CA key expires At the command prompt, type: certutil –setreg ca\CRLFlags + CRLF_DELETE_EXPIRED_CRLS Delegate CA Administration Before you begin to issue certificates, you need to delegate CA administrator roles. For information about defining CA administrator roles, see ―Defining PKI Management and Delegation‖ earlier in this chapter. You can assign CA Administrator and Certificate Manager permissions by using the Certification Authority MMC snap-in. Other roles, users, and groups are specified in the consoles used to perform particular tasks, such as Certificate Templates and Certificates. To change the roles of a user, you must change the security permissions, group membership, or rights of the user. Deploying the PKI 841 Configure Certificate Enrollment and Renewal Microsoft Certificate Services supports a variety of enrollment and renewal methods, such as the Certificate Request Wizard or the Microsoft Certificate Services Web pages. However, if you deploy third-party certificate services or custom certificate enrollment and renewal applications, you must perform any configuration required for those services and applications. Issue Certificates You can issue certificates to users, computers, and services after the required certificate services are installed and configured. Keep the following considerations in mind when you start to issue certificates: Certificates are issued for computers within the scope of the Automatic Certificate Request settings of the Group Policy. Domain Administrators can also manually request certificates for local computers by using the Certificate Request Wizard or the Microsoft Certificate Services Web pages. Consider scheduling manual enrollment in stages to help distribute the administrative workload for computer enrollment. Smart card administrators can start issuing smart card certificates by using the Smart Card Enrollment Station available on the Microsoft Certificate Services Web pages. Consider scheduling smart card enrollment in stages to help distribute the administrative workload for smart card enrollment. During the transition to smart cards, both smart card authentication and interactive logon with domain credentials should be enabled. Because this weakens network security, configure user account policy to require smart cards for interactive logon as soon as smart card users are trained and are using their cards. Monitor the performance of certificate services closely as you start issuing certificates to ensure that CAs handle the certificate load. To correct excessive load conditions, consider adding more issuing CAs or scheduling certificate enrollment in smaller stages. Certificate renewal might also produce excessive load conditions. Adding more CAs and scheduling certificate enrollment in smaller stages can also help distribute peak renewal loads. 842 Chapter 16 Designing a Public Key Infrastructure Additional Resources These resources contain additional information and tools related to this chapter. Related Information The Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit) for more information about public key features in Windows Server 2003 and using certificates in conjunction with Encrypting File System. ―Deploying Smart Cards‖ in this book for more information about deploying smart cards. The Software Development Kit (SDK) information in the MSDN Library link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources for more information about developing CAPICOM and other public key–enabled applications. The Common Criteria link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources for information about the Common Criteria for Information Technology Security Evaluation. The National Institute of Standards and Technology (NIST) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources for information about public standards that apply to public key infrastructures. Related Help Topics For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox. ―Mapping certificates to user accounts‖ in Help and Support Center for Windows Server 2003 for information about creating a mapping. ―Manage certificate revocation‖ in Help and Support Center for Windows Server 2003 for information about configuring CRL publication. ―Installing and configuring a certification authority‖ in Help and Support Center for Windows Server 2003 for more information about creating and using CAPolicy.inf files. Related Job Aids ―Summary of User Certificate Requirements‖ (DSSPKI_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Summary of User Certificate Requirements‖ on the Web at http://www.microsoft.com/reskit). ―Certificate Practice Statement Outline‖ (DSSPKI_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Certificate Practice Statement Outline‖ on the Web at http://www.microsoft.com/reskit). ―Windows Server 2003 Certificate Lifecycle Plan‖ (DSSPKI_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see ―Windows Server 2003 Certificate Lifecycle Plan‖ on the Web at http://www.microsoft.com/reskit).