Module 14: Designing a Public Key Infrastructure Overview Introducing a Public Key Infrastructure Using Certificates Examining the Certificate Life Cycle Choosing a Certification Authority Planning a Certification.
Download ReportTranscript Module 14: Designing a Public Key Infrastructure Overview Introducing a Public Key Infrastructure Using Certificates Examining the Certificate Life Cycle Choosing a Certification Authority Planning a Certification.
Module 14: Designing a Public Key Infrastructure Overview Introducing a Public Key Infrastructure Using Certificates Examining the Certificate Life Cycle Choosing a Certification Authority Planning a Certification Authority Hierarchy Mapping Certificates to User Accounts Managing CA Maintenance Strategies A Public Key Infrastructure (PKI) is the combination of software, encryption technologies, and services that enables organizations to protect the security of their communications and business transactions. A PKI relies on the exchange of digital certificates between authenticated users and trusted resources. You can use certificates in a PKI to secure data and manage identification credentials from users both within and outside your organization. At the end of this module, you will be able to: Describe the basic components of a PKI. Define how certificates can be used in a PKI to certify applications and services. Define the basic functions of certificates within a certificate life cycle. Choose between public and private certification authorities (CAs). Plan a hierarchy for organizing CAs in a network. Use certificate mapping to apply user permissions to users who are not included in your organization's Active Directory™ directory service. Plan recovery and maintenance strategies for CAs. Introducing a Public Key Infrastructure Key and Certificate Management Tools Certificate Publication Point Certification Authority Digital Certificate Certificate Revocation List Public Key–Enabled Applications and Services A PKI provides a framework of services, technologies, protocols, and standards that you can use to deploy and manage a strong and scalable security system. The PKI of a network consists of the following basic components: Digital Certificate Key and Certificate Management Tools Certification Authority Certificate Publication Point Public Key–Enabled Applications and Services Certificate Revocation List (CRL) Digital Certificate An electronic credential, consisting of a public key and a private key, used to authenticate users. Certificates provide the foundation of a PKI. Key and Certificate Management Tools Tools for administering and auditing digital certificates. The certificates snap-in is used to manage certificates on Microsoft® Windows® 2000-based CA. Certification Authority A trusted entity or service that issues digital certificates. CAs can be configured< as either enterprise or standalone CAs. Enterprise CAs rely on Active Directory to authenticate users, whereas stand-alone CAs do not. To configure a Windows 2000-based computer as a CA, you must install Certificate Services. Certificate Publication Point A directory service or other location where certificates are stored and published. Active Directory is the publication point for certificates for a Windows 2000based CA. Public Key–Enabled Applications and Services Applications and system services that require the secure transfer of information. Applications that are enabled for certificate-based security include Microsoft Outlook® and Microsoft Internet Explorer. System services that can be secured by using certificates include Encrypting File System (EFS) and Internet Protocol Security (IPSec). Certificate Revocation List (CRL) A list of certificates that have been revoked before reaching the scheduled expiration date. Using Certificates Identifying Uses for Certificates Determining Certificate Requirements Using Certificate Templates Before implementing certificate-based authentication, you must determine which network resources, such as data, applications, and services, must be secured. You must also identify which users will need access to these secured resources and the type of access rights that will be required. To simplify administration of certificates, you can use templates to predefine the basic content of a certificate. In this lesson you will learn about the following topics: Identifying uses for certificates Determining certificate requirements Using certificate templates Identifying Uses for Certificates Applications Secure Mail Software Code Signing Secure Web Communications Secure Web Sites Custom Security Solutions Services Smart Card Logon Process IPSec Client Authentication Encrypting File System Applications Secure Mail Software Code Signing Secure Web Communications Secure Web Sites Custom Security Solutions Certificates can be used with a variety of applications and security services to provide authentication, data integrity, and security. After you have identified the uses for certificates in your organization, you can design an appropriate public key security solution. Applications Certificates can provide a secure solution for: Secure mail. Configure the Secure Multipurpose Internet Mail Extension (S/MIME) protocol to ensure the integrity, origin, and confidentiality of e mail messages. Software code signing. Configure digital signatures to ensure the integrity of software that is distributed over a network. Secure Web communications. Use certificates with Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols for authenticating and encrypting communications between servers and clients. Secure Web sites. Use certificates to authenticate access to secure Web sites. Custom security solutions. Use certificates to provide confidentiality, integrity, authentication, and non-repudiation for custom applications. Services Services Certificates can provide a secure solution for: Smart Card Logon Process IPSec Client Authentication Encrypting File System Smart card logon process. Use certificates to authenticate users with smart card devices attached to their computers. IPSec client authentication. Use certificates to authenticate transmissions between two computers by using IPSec. EFS. Use certificates to distribute public and private keys that protect the EFS file encryption key. Determining Certificate Requirements Identify applications that require certificates Determine the required level of security Identify users, computers, and services requiring certificates Determine how to protect private keys When planning certificate use, you must determine the certificate requirements of your network. The requirements will be based on applications, security levels, and services running on the network. To determine the certificate requirements of your network, you must do the following: Identify applications that require certificates. Determine the required level of security. Identify users, computers, and services requiring certificates. Determine how to protect private keys. Identify applications that require certificates. Within your organization, determine the risks associated with exposing information to unauthorized users. For example, a concern may be protecting e-mail messages between business partners when exchanging confidential data. Determine the required level of security. Select the level of security needed to protect the integrity or privacy of information. Factors to consider are length of the private key, cryptography algorithm, certificate lifetime, and renewal cycle. For example, use a longer private key length and a shorter certificate lifetime to provide security for highly valuable information Identify users, computers, and services requiring certificates. Identify the users, computers, and services that will participate in the secure exchange of information. For example, determine which users from external partners will have access to an internal inventory database. Determine how to protect private keys. Select the level of security required to protect the private key. Options include storing the private keys in the user's profiles or, for improved security, requiring the use of smart cards to store private keys. Using Certificate Templates Single-purpose Templates E-mail EFS Multi-purpose Templates EFS E-mail SSL Using Certificate Templates A certificate template defines the format and content of a certificate. Certificate templates relieve users from making decisions about the types of certificates that they need. Instead, for the certificates that the user receives, users can rely on the judgment of the certificate administrator. Certificate templates are only used when the server that is running Certificate Services is an enterprise CA. Tip: When creating custom templates, select functionbased names for the templates. Function-based names allow users to easily select the proper certificates based on the tasks that the user is performing at that time. When creating a certificate by using templates, you can choose from the following: Single-purpose template. Generates certificates that can be used only for a single application. For example, the Smart Card Logon certificate template is designed for only smart card logon. Other single-purpose templates include templates for EFS or S/MIME. Multipurpose template. Generates certificates that can be used for a number of applications, such as SSL, S/MIME, and EFS. For example, a user certificate can be used for both user authentication and EFS encryption. Certificate templates are secured by modifying the discretionary access control list (DACL) of each certificate template. Only users or groups that are given the Enroll permission in the DACL will be allowed to request a specific certificate template. Note: Certificate templates are only installed and used when you configure Windows 2000 Certificate Services as an enterprise CA. Examining the Certificate Life Cycle Certificate Enrollment Certificate Distribution Certificate Revocation Certificate Renewal Certificate Auditing The certificate life cycle defines the processes by which a CA requests, issues, revokes, renews, and audits certificates. A CA is an entity that has been entrusted to issue certificates to individuals, computers, or organizations to confirm their identities for current and future transactions. You define a certificate life cycle to meet your organization's security requirements. The management and configuration choices that you make for each stage in the certificate life cycle will depend on the security needs of your organization. The Life Cycle of a Digital Certificate In this lesson you will learn about the following topics: Certificate enrollment Certificate distribution Certificate revocation Certificate renewal Certificate auditing Certificate Enrollment 1 4 Verify Information 5 Create Certificate 6 Send or Post Certificate Public Enrollment Information Private 2 3 Certificate Request Client Computer Certification Authority To participate in a PKI, users and computers must request and receive certificates from a CA. The process of requesting and receiving a certificate is known as enrollment. Typically, a user initiates enrollment by providing unique information and a newly generated public key. The CA uses the information provided to authenticate the identity of the user before issuing a certificate. The process of requesting and issuing a certificate varies with the CA and its policies, but can generally be broken down into the following six steps. Certificate Distribution Certificate Approved Active Directory Web page Web page Stand-alone Requests Web page or Wizard Web page CA Wizard Enterprise Requests Certificates can be used with a variety of applications and security services to provide authentication, data integrity, and security. After you have identified the uses for certificates in your organization, you can design an appropriate public key security solution. Processing Stand-alone CA Requests When a user submits a certificate request to a Windows 2000 stand-alone CA, the request is considered pending until the CA administrator approves or rejects the request based on the submitted credentials of the user. The certificate requester can view the Certificate Services Web page to check the status of pending certificates. Processing Enterprise CA Requests When a user submits a certificate request to a Windows 2000 enterprise CA, the request is immediately processed because an enterprise CA uses Active Directory to verify users. The certificate request will either immediately fail or immediately be granted. If it is granted, the certificate is issued, and the user will be prompted to install it. From an enterprise CA, a user can request a certificate by using the Certificate Request wizard. The Certificate Request wizard is launched from the Certificates console and allows a user to select from different certificate types, depending on the user's access rights. Alternatively, certificates can be requested by connecting to http://servername/certsrv, where servername is a server with Certificate Services installed. Note: The CA administrator can use Group Policy to configure the CA so that computers can automatically request certificates without user intervention. Automatic certificate requests free the administrator from explicitly enrolling each computer-related certificate. Certificate Revocation Active Directory CRL CRL CA Compromised Employment Status Changes Private Key Compromised Certificate Obtained Fraudulently Certificate Status Changes Certificate Server Client Computer Revoking a certificate may be necessary when some security-related event, such as the dissolution of a partnership with another company, creates a situation in which it is no longer appropriate to consider a certificate valid. Certificates may need to be revoked if: The security of the CA that issued the certificates is compromised. The recipient of certificate leaves an organization, or if the recipient's employee status changes in any significant way. The private key of the certificate is compromised (for example, a lost smart card). A certificate was obtained fraudulently. A certificate was issued to an individual who is no longer a trusted partner. Windows 2000 Certificate Services supports the use of industrystandard CRLs to distribute information about revoked certificates. You publish a CRL by using the Certification Authority snap-in. When you publish a CRL, it is stored in Active Directory, where users and computers can retrieve it. The users and computers will then store the CRL in their local caches. You must establish a balance between the need to publish CRL information as frequently as possible and the impact that publication has on network traffic and server load. Frequent CRL publication causes the change in the status of the certificate to be known more quickly but also increases server load. Network traffic is also affected because clients need to download the CRL each time it expires and is republished. Important: If the CRL is not available, a certificate cannot be verified and access will be denied. Certificate Renewal 1/1/2000 1/1/2000 Root CA 1/1/2000 Issuing CAs Planning CA Certificate Lifetime Planning Certificate Renewal 1/1/2000 1/1/2000 All certificates, including those issued to CAs and users, have a finite lifetime. When a certificate reaches its expiration date, it automatically becomes invalid and can no longer be used. An expired certificate can be reissued or renewed with valid dates. Planning CA Certificate Lifetime When a CA issues a certificate to a user or computer, the CA ensures that the validity period of the new certificate falls within the validity period of the CA's own certificate. This means that if the CA's certificate is valid for only an additional six months, the longest validity period that the CA will issue for a new certificate is six months. You need to ensure that a CA certificate has a sufficient lifetime so that issued certificates do not need to be renewed too frequently. Excessive renewal of certificates may add an additional burden to users. Whenever a certificate expires, the user needs to contact the CA to request a new certificate because they will need to acquire updated certificates. Planning Certificate Renewal An issuing CA issues certificates directly to users, rather than to other CAs. Issuing CAs are responsible for managing a much larger number of certificates than a CA that issues certificates only to CAs. Frequently renewing a CA's certificate with a new key makes an attack on any one key less valuable to the attacker and less damaging to your PKI. Certificate Auditing Certificate Services Log and Database Certificate Server 01ea812… 1f21911… Revoked Certificates Issued Certificates Pending Requests Failed Requests 6b323e1… Each CA maintains an audit trail that can be viewed in the Certification Authorities Microsoft Management Console (MMC). The audit trail records all of the certificate requests and the issued certificates that are still active. The audit trail records all transactions, including failed requests, and includes all of the information contained in each issued certificate. The Certification Authorities MMC console provides the ability to revoke a certificate and add it to the revocation list. An audit trail may be required to meet the security obligations of the CA and your organization. You can query the audit trail to locate and view information about any certificate request or any certificate that the CA has issued. For example, if an issued certificate was used for an illegal activity or for a fraudulent transaction, you might be asked to provide records to security or law-enforcement personnel. In addition, you may need audit trail records to monitor the network for security breaches. For example, you can view the audit trail to detect failed certificate requests or to determine whether someone has improperly obtained certificates. Note: You can view the contents of the Windows 2000 Certificate Services log and database by using the Certification Authority snap-in. Choosing a Certification Authority Choosing a Commercial CA Choosing a Private CA Selecting a CA Policy Discussion: Choosing a CA There are two types of CAs that can provide certificates for an organization: a commercial CA maintained by a certificate-issuing company, or a private (internal) CA. Private CAs require an administrative model for issuing certificates and providing security for the root CA. If you select a private CA, you will need to choose what type of certificate policy (not to be confused with Group Policy) you will implement for your organization's certificate deployment. In this lesson you will learn about the following topics: Choosing a commercial CA Choosing a private CA Selecting a CA policy Discussion: Choosing a CA Choosing a Commercial CA Request External Customers Issue Commercial CA Secure Access External Customers and Clients Outsourced Certificate Management Internal Web Server Commercial CAs are created and managed by a thirdparty company. Choose a commercial CA when you conduct most of your business with external customers and clients, and you want to outsource the management and issuance of certificates. The following table outlines some of the advantages and disadvantages of choosing a commercial CA. Advantages Disadvantages Creates a greater level of confidence for customers to conduct secure transactions with the organization Takes advantage of the expertise of a professional service provider. Potentially provides less flexibility in managing certificates Allows an organization to immediately use certificate-based security while developing an internally managed PKI Takes advantafe of the provider's understanding of teh technical,legal, and business issues associated with certificate use. May require two different management standards, one for internally issued certificates and one for commercially issued certificates. Typically involves per-certificate costs. Access to the CA must always be available to access the CRL at the commercial CA. Choosing a Private CA Request External Partners Issue Private CA Secure Access External Partners Internal Certificate Management Web Server Private CAs are created and managed internally within the organization. Choose a private CA when you conduct most of your business with partner organizations and you want to maintain control of how certificates are issued. The table outlines some of the advantages and disadvantages of choosing a private CA. Advantages Disadvantages Allows a company to tightly control its security policies. Companies must manage their own certificates. Allows a company to manage its certificate policy to match its overall security policy. Deployment schedule may take longer than with a commercial service provider. Selecting a CA Policy Active Directory Enterprise Policy Administrator Stand-Alone Policy When installing Certificate Services to create a private CA, you must select one of two different CA policy models. The CA policy that you choose will determine the characteristics and behavior of the CA. Choose the policy model based on the role that the CA will play in your organization's PKI deployment. Enterprise Policy A Windows 2000 enterprise CA uses Active Directory as the user registration database. An enterprise CA has the simplest administration model with the lowest overhead per certificate. Choose an enterprise CA if you will issue certificates to users and computers within your organization. Enterprise CAs have the following characteristics: Enterprise CAs are dependent on the presence of Active Directory. If a requestor does not have an account in Active Directory, the requestor cannot acquire a certificate from an enterprise CA. Enterprise CAs use domain user accounts to authenticate a certificate requestor. Users who have appropriate permissions can request a certificate from any enterprise CA. Enterprise CAs use certificate templates to define certificates that meet a particular purpose, and as a means of defining an enrollment policy for the forest. Note: Only members of the Enterprise Admins group can create an enterprise CA. Stand-Alone Policy A stand-alone CA can function independently of Active Directory. Choose a stand-alone CA if you will issue certificates to users and computers outside of your organization. Stand-alone CAs have the following characteristics: Stand-alone CAs require certificate requestors to explicitly supply all identifying information about themselves and the type of certificates desired (unlike a request to an enterprise CA, in which the user's information is already in Active Directory and a certificate template describes the certificate type). Using stand-alone CAs also allows an organization to customize the information that may be required from a user. Stand-alone CAs regard all CA requests as pending until the administrator of the stand-alone CA (by using the Certification Authority console) verifies the identity of the requestor and allows the request. Stand-alone CAs cannot issue certificates for smart card authentication to a Windows 2000 domain. However, other types of certificates, such as a Web client certificate, can be issued and stored on a smart card. Stand-alone CAs do not use certificate templates. Only enterprise CAs use certificate templates. Discussion: Choosing a CA CA Solution Must: Provide Secure Online Ordering for Customers. Manage User Accounts Internally. Require Customers to Apply for and Receive Approval to Enter Web Site. When implementing Certificate Services, you must choose between a private and a commercial CA. This scenario shows how both types of CAs can be integrated to provide a secure PKI solution. Scenario As the security architect, you are designing a PKI for your organization. Your organization has just entered into a partnership with a large retailer. Your organization will provide online ordering for customers, and will manage user accounts internally. Customers must apply for and gain approval before they can access the Web site. You need to provide a secure method for customers to conduct sales transactions over the Internet. Your answers must: Provide secure online ordering for customers Manage user accounts internally Require customers to apply for and receive approval to enter Web site Planning a Certification Authority Hierarchy Examining a CA Hierarchy Securing a CA Planning a CA Hierarchy Based on Usage Planning a CA Hierarchy Based on Organizational Structure Planning a CA Hierarchy Based on Location The Windows 2000 PKI is based on a hierarchical CA model, with a root CA and a hierarchy of subordinate CAs beneath it. A certification hierarchy composed of secure CAs provides scalability, ease of administration, and compatibility with a growing number of commercial and other third-party CAs. You can design a hierarchy on the basis of usage, organization, or geography. In this lesson you will learn about the following topics: Examining a CA hierarchy Securing a CA Planning a CA hierarchy based on usage Planning a CA hierarchy based on organizational structure Planning a CA hierarchy based on location Examining a CA Hierarchy Root CA Subordinate CAs CA Database Capacity Administrative Delegation Enterprise Reorganization Service Availability Certificate Publication Issuing CAs In its simplest form, a certification hierarchy consists of a single CA. Large organizations typically require multiple CAs due to the large number of services and applications requiring certificates. Multiple CAs are arranged in a hierarchy with clearly defined parent/child relationships. In a CA hierarchy, each parent CA certifies the child CAs below it. The CA at the top of a hierarchy is called the root authority or root CA. The child CAs of the root CAs are called subordinate CAs. The root CA is used only to sign subordinate CA certificates and the CA certificate for the root CA itself. Below the subordinate CAs are issuing CAs that issue certificates directly to users and computers. A certificate trust list (CTL) is a set of certificates that the administrator determines to be trustworthy. The CTL defines the certification path from the issuing CA up to the root CA. For a client authentication certificate to be used successfully, a CA listed in the CTL must issue the certificate. Some guidelines and considerations for designing a CA hierarchy include: CA Database capacity. As a recommendation, a single Windows 2000 CA is designed to support up to 250,000 users. Note: Microsoft has tested individual servers running Windows 2000 Certificate Services that have managed more than one million certificates. Administrative delegation. CA hierarchies can span multiple Active Directory forests. A subordinate CA can be in the same domain as the parent, in a child domain under the parent domain, or in a domain in a separate forest. After you create a subordinate CA, you can delegate management of that CA to a group of administrators by using Group Policy. Enterprise reorganization. You can reorganize a CA hierarchy 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. Service availability. You can install multiple CAs in a forest to ensure that at least one CA is always available to process certificate enrollment requests. Certificate publication. For an enterprise CA to publish a user certificate to the user object in Active Directory, the enterprise CA must have network connectivity to a domain controller. Note: CA policies can be mixed in a network. For example, a network might have a stand-alone root CA with enterprise subordinate CAs. Securing a CA Manually Issued Certificates Offline Root CA Subordinate CAs Securing the root CA is fundamental to the security of a PKI. In Windows 2000, if a user or computer trusts the root CA (by having its certificate in the user's or computer's Trusted Root CAs certificate store), the user or computer trusts every subordinate CA in the hierarchy. The only exception is when a subordinate CA has had its certificate revoked by the issuing CA or has an expired certificate. Securing the Offline Root CA Securing an offline root CA is generally accomplished by removing the root CA from the network and storing it in a vault or other secure location. Establishing complex procedures for creating new subordinate CAs, such as requiring multiple operators to confirm actions simultaneously, can also enhance physical security. Issuing Certificates from an Offline CA Offline CAs issue certificates to subordinate CAs manually. This configuration, although more secure, does add to administrative overhead. During installation of a subordinate CA, a signed certificate request is created, and this certificate request must be manually delivered to the offline CA by using removable media. When the offline CA receives the request, it creates a message that contains the CA certificate from the original request. The CA certificate must then be physically carried back to the subordinate CA, and only then is the installation of the subordinate CA complete. In addition, administrators must manually publish certificates to Active Directory. Planning a CA Hierarchy Based on Usage Root CA Corporate CA Subordinate CAs Projects Issuing CAs SSL Client SSL Server E-Mail Extranet A usage hierarchy is based on the types of services and applications that require certificates. As shown in the preceding illustration, the root CA is at the top of the hierarchy and has a self-signed certificate. The CAs directly subordinate to the root CA are organized based on the function of the certificates that the CA serves. The subordinate CAs use certificates signed by the root CA. Below the subordinate CAs are a series of issuing CAs. Issuing CAs issue certificates directly to users and computers. The issuing CAs are organized by the type of service or application requiring certificates. For example, you may want to create a CA solely to issue certificates for secure e-mail. Planning a CA Hierarchy Based on Organizational Structure Root CA Certificate Chain Subordinate CAs Customers CA Permanent Employees CA Partners CA Employees CA Contractors CA Issuing CAs Issuing CA An organizational hierarchy is based on the administrative structure of the organization. In the organizational hierarchy model, the CAs directly subordinate to the root CA are organized by the type of business relationship-such as customers, partners, or employees-that users have with the organization. The issuing CAs may be organized along such organizational boundaries as permanent employees and contractors. The issuing policy might be based on the organization of user accounts, so that stronger security methods are applied to independent contractors, temporary employees, or external business partners. Planning a CA Hierarchy Based on Location Root CA Subordinate CAs Asia Europe Sales Marketing Issuing CAs USA Engineering Configuring a CA hierarchy by location allows you to issue certificates according to the location of external users or business partners. Issuing certificates based on location may be a requirement due to legal limitations (such as encryption key lengths imposed by a country) or some other security export regulations. The issuing CAs can be based on departments located in each geographic location. Mapping Certificates to User Accounts One-to-One Mapping Many-to-One Mappings Your organization may need to support authentication of external users who do not have an account in Active Directory. Certificate mapping allows an organization to provide access to a user based on the user's ownership of a valid authentication certificate obtained from outside the organization. When certificate mapping is enabled, users are authenticated in Active Directory on the authority of these mapped certificates, and are granted rights and permissions based on the authentication. Certificate mapping can be configured in the following ways: One-to-one. Creates an association from an individual certificate to a corresponding user account in Windows 2000. Many-to-one. Creates an association for all certificates from a specific CA to a Windows 2000 user account. One-to-One Mapping User Certificate Mapping User Account 1. Single Certificate Is Mapped to a Single User Account 2. User Is Authenticated Using the Mapped User Account 3. User Receives Rights and Permissions Permitted by the User Account Resources In one-to-one certificate mapping, you create an association between an individual certificate held by a user and a corresponding user account in Windows 2000. After a certificate has been mapped to the user account in Windows 2000, the holder of the certificate is authenticated based on the mapped Windows 2000 user account. Following authentication, the user is granted the rights and permissions permitted by the mapped user account. Manually administering one-to-one mapping requires more administrative effort than administering many-toone mapping. Use one-to-one mapping when you have a relatively small number of clients. Tip: If you use one-to-one mapping for large numbers of clients, consider developing custom Web enrollment pages by using Active Server Pages (ASP) technology to automate the mapping process. Many–to–One Mappings User Certificates Mappings User Account 1. All Certificates Issued by a CA Are Mapped to a Single User Account 2. User Is Authenticated Using the Mapped User Account 3. User Receives Rights and Permissions Permitted by the User Account Resources Many-to-one Certificate mappings map all certificates from a single CA to a single Windows 2000 user account. Many-to-one mapping allows any user who has received a certificate from the CA to be granted the access rights that are assigned to the Windows 2000 user account. Many-to-one mapping is useful for authenticating large numbers of users who may 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 installed as 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 2000. Mapping rules are set that check the information that is contained in users' certificates, such as the users' organization and the issuing CA, to determine whether the information matches the criteria in the rules. When the information in users' certificates matches the rules, users are mapped to a specified user account. The permissions set on the user account will 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 may require access to resources on your network. You can configure user accounts that grant different sets of rights and permissions on the basis of the clients' 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 nonconfidential information and selected proprietary information. Managing CA Maintenance Strategies Planning a CA Recovery Strategy Transferring Certificates Between Computers A failed CA can result in requiring the reissue of all certificates issued by that CA. If the failed certification authority has subordinate CAs, all certificates issued by the subordinate CAs must also be reissued. CAs must be protected to ensure that a failed CA and its Certificate Services database can be restored. Protecting CAs includes planning a CA recovery strategy and backing up or transferring certificates between computers. In this lesson you will learn about the following topics: Planning a CA recovery strategy Transferring certificates between computers Planning a CA Recovery Strategy Recovering from a Hardware Failure Recovering from a Security Compromise Minimizing Risk of CA Failure A recovery plan must be developed to ensure that CAs can be restored if Certificate Services fails or if a CA is compromised. A failed or compromised CA can result in valid certificate holders being denied access to resources. Recovering from a Hardware Failure CAs can fail for a variety of reasons, such as failure of a server hard drive, failure of a network adapter, failure of a server, or corruption of the certification authority's database. If you cannot recover from a hardware failure, configure a replacement server with the same computer name and Internet Protocol (IP) address. After replacing the server, use Windows 2000 Backup or the Certification Authority Restore wizard to restore the CA from the most recent backup. Important: The restoration of a failed CA requires that IIS also be restored, because the Web Enrollment Support pages included with Certificate Services update the IIS metabase. Recovering from a Security Compromise When a CA has been compromised, you must revoke the CA's certificate. Revoking a CA's certificate invalidates the CA and its subordinate CAs, in addition to invalidating all certificates issued by the CA and its subordinate CAs. If you discover a compromised CA, perform the following tasks as soon as possible: 1. Revoke the compromised CA's certificate. 2. Publish a new CRL containing the revoked CA certificate. Caution: Client applications will store the previous CRL until it expires. The updated CRL will not be downloaded until the outdated CRL expires. 3. Remove compromised CA certificates from Trusted Root Certification Authorities stores and the CTL. 4. Notify all affected users and administrators of the compromise. All certificates issued by the affected CAs will be revoked. 5. Deploy new certificates to replace the affected certificates. Minimizing Risk of CA Failure You can use the following preventive practices to reduce the risk of CA failures and to minimize the disruption of CA services: Provide duplicate CA services so that if one server is offline, another server can still issue the appropriate certificates. Back up CAs frequently so that they can be restored with a minimal loss of data. Install Certificate Services on hard disks by using disk arrays that use redundant array of independent disks level 5 (RAID-5) protection. Prepare recovery plans and train administrative staff on recovery plans. Maintain records of all server and CA configuration information so that exact configurations can be easily restored. Maintain replacement servers for immediate recovery. In some cases, you may want to transfer a certificate from one computer to another. For example, if a CA is being restored or a certificate holder is setting up a new computer, you will export the certificate to the new or repaired computer. You can use the import and export capabilities in the Certificates MMC console to save and restore certificates. Exporting a Certificate You might want to export a certificate to: Back up a certificate and its associated private key Copy a certificate for use on another computer. Remove a certificate and its private key from the certificate holder's current computer for installation on another computer. When you export a certificate, you copy the certificate from its certificate store to a file that uses a standard certificate storage format. Importing a Certificate You might want to import a certificate to: Restore a damaged or lost certificate that you previously backed up. Install a certificate and its associated private key from a computer that the certificate holder was previously using. Install a certificate that another user, computer, or CA sent to you in a file. When you import a certificate, you copy the certificate from a file that uses a standard certificate storage format to either your user account certificate store, or your computer account certificate store. Transferring Certificates Between Computers Exporting a Certificate Backup Certificate and Private Key Copy a Certificate from Computer to Computer Uninstall the Initial Certificate Restore from Damage or Loss Transfer from a Previous User’s Computer to a New Computer Install the Initial Certificate Importing a Certificate Lab A: Using Certificate-based Authentication Lab A: Using Certificate-based Authentication After completing this lab, you will be able to: Create a CA hierarchy. Load a user certificate. Configure a Web server to use certificates. Configure a Web server to require certificates for authentication. Revoke an issued certificate. Prerequisites Before working on this lab, you must have: Knowledge of designing CA hierarchies. Knowledge of deploying server certificates. Knowledge of how to design certificate mapping to user accounts. Lab Setup This lab environment includes the following resources: The London computer configured as an enterprise root CA for the nwtraders.msft forest. Two computers, with one computer acting as the enterprise subordinate CA. Exercise 1: Configuring an Enterprise Subordinate CA Scenario Northwind Traders needs to secure its PKI. Northwind Traders currently has a single enterprise root CA at its London office. A failure of the London server would require a PKI redeployment. Northwind Traders needs to mitigate the risk of redeployment. Goal In this exercise, one of the two computers in your child domain is configured to function as an enterprise subordinate CA for the Northwind Traders forest. Online Demo Exercise 2: Installing a User Certificate Using MMC Scenario User accounts and passwords are vulnerable to interception by a network monitor, known as a network sniffer, capturing them on the network. To prevent this risk, a decision has been made to use certificate-based authentication when accessing the Security Web site located on the company's Web server. Goal In this exercise, a user certificate will be requested by using the Certificates console in MMC. Online Demo Exercise 3: Configuring the Web Server to Use Certificatebased Authentication Scenario User accounts and passwords are vulnerable to capture by a network sniffer. To prevent this risk, a decision has been made to use certificate-based authentication when accessing the security subsite located on the division's Web server. Goal In this exercise, you will configure a Web server to require certificate-based authentication. User certificates will be mapped to Active Directory accounts within IIS. Online Simulation Exercise 4: Accessing a Web Site Using Certificate Authentication Scenario User accounts and passwords are vulnerable to capture by a network sniffer. To prevent this risk, a decision has been made to use certificate-based authentication when accessing the security subsite located on the division's Web server. Goal In this exercise, certificate-based authentication is verified to ensure it is functional for the security subsite on the division's Web server. Online Demo Exercise 5: Revoking a Certificate Scenario Two users have resigned from Northwind Traders. Due to their positions in the company, their user accounts were immediately terminated, and you have been asked to revoke their certificates that grant them access to the Security Web site. Goal In this exercise, the certification authority console is used to revoke both certificates and to publish the CRL. Online Demo Exercise 6: Testing the Certificate Revocation List Scenario One of the former employees is attempting to access the Security Web site by using their revoked certificate for authentication. Goal In this exercise, the successful revocation of the former employees' certificates is verified. Online Demo Review Introducing a Public Key Infrastructure Using Certificates Examining the Certificate Life Cycle Choosing a Certification Authority Planning a Certification Authority Hierarchy Mapping Certificates to User Accounts Managing CA Maintenance Strategies