1. Create an account to be used for key recovery. 2. Create a new template to issue to that account. 3. Request a key recovery certificate from the CA. 4. Have the CA issue the certificate. 5. Configure the CA to archive certificates by using the Recovery Agents tab of the CA property sheet (shown in Figure 24.5). 6. Create an archive template for the CA. Each of these steps requires many substeps, but can be well worth the time and effort. It is worth noting again that key recovery is not possible on a stand-alone CA, because a standalone cannot use templates. It is also worth noting that only encryption keys can be recovered – private keys used for digital signatures cannot be. Planning CA Security As we have already discussed, configuring the root CA as a standalone is probably the most impor- tant measure you can take to prevent accidental or intentional tampering. With no network connec- tivity, attacks become virtually impossible, as a user would have to log on while sitting at the physical location of the server. Other security considerations are really more a function of general server security – things such as requiring complex passwords, implementing file encryption and physically limiting access to the server. In guarding the hierarchy, you cannot solely concentrate on the root CA. After all, if a subordi- nate CA is tampered with, every entity below it in the PKI hierarchy becomes compromised. Most 836 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Figure 24.5 Recovery Agents Tab of the CA Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 836 subordinate CAs are attached to the network.This obviously increases their vulnerability. Beyond securing the network itself (by using IPSec and group policies, for example), there is another part of a standard PKI that helps maintain CA integrity.That part is certificate revocation, which we will go into in greater detail shortly. Certificate revocation enables an administrator to warn PKI clients about certificates that might not be authentic or that might have been issued by a rogue CA. Disaster recovery applies to every CA in the hierarchy, but especially at the root.That being said, the importance of performing proper backups cannot be overstated. Certificate Revocation A CA’s primary duty is to issue certificates, either to subordinate CAs or to PKI clients. However, each CA also has the capability to revoke those certificates when necessary.The tool that the CA uses for revocation is the certificate revocation list, or CRL.The act of revoking a certificate is simple: from the Certification Authority console, simply highlight the Issued Certificates container, right-click the certificate and choose All | Revoke Certificate.The certificate will then be located in the Revoked Certificates container. When a PKI entity verifies a certificate’s validity, that entity checks the CRL before giving approval.The question is: how does a client know where to check for the list? The answer is the CDPs, or CRL Distribution Points. CDPs are locations on the network to which a CA publishes the CRL; in the case of an enterprise CA under Windows Server 2003,Active Directory holds the CRL and for a standalone, the CRL is located in the certsrv\certenroll directory. Each certificate has a location listed for the CDP, and when the client views the certificate, it then understands where to go for the latest CRL. Figure 24.6 shows the Extensions tab of the CA property sheet, where you can modify the location of the CDP. For a CA to publish a CRL, use the Certification Authority console to right-click the Revoked Certificates container and choose All Tasks | Publish. From there, you can choose to publish either a complete CRL or a Delta CRL. Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 837 Figure 24.6 Extensions Tab of the CA Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 837 Whether you select a New CRL or a Delta CRL, you are next prompted to enter a publication interval (the most frequent intervals chosen are one week for full CRLs and one day for Delta CRLs). Clients cache the CRL for this period of time and then check the CDP again when the period expires. If an updated CDP does not exist or cannot be located, the client automatically assumes that all certificates are invalid. Planning Enrollment and Distribution of Certificates For a PKI client to use a certificate, two basic things must happen. First, a CA has to make the cer- tificate available and second, the client has to request the certificate. Only after these first steps can the CA issue the certificate or deny the request. Making the certificate available is done through the use of certificate templates and is a topic that we discuss in detail below. As for the client, there are three methods of requesting certificates – all three of which are essential to a thorough under- standing of PKI: auto-enrollment, the Certificates snap-in, and the Certificates web page. We will discuss each in more detail in the section titled Certificate Requests. Certificate Templates A certificate template defines the policies and rules that a CA uses when a request for a certificate is received. Many built-in templates can be viewed using the Certificate Templates snap-in (see Figure 24.7).The snap-in can be run by right-clicking the Certificate Templates container located in the Certification Authority console and clicking Manage.You can use one of the built-in templates or create your own. When creating your own template, you have multiple options that will guide the CA in how to handle incoming requests.The first step in the creation process is to duplicate an existing template. 838 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Figure 24.7 Certificate Templates Snap-In 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 838 You do this by using the Certificate Templates snap-in, then right-clicking the template you wish to copy and selecting Duplicate Template. On the General tab that appears by default, there are time- sensitive options such as validity period and renewal period. Note the default validity period of one year and the default renewal period of six weeks.There are also general options such as the template display name and a check box for publishing the certificate in Active Directory. The Request Handling tab, shown in Figure 24.8, has options including minimum key size and certificate purpose.The certificate purpose can be encryption, signature, or signature and encryption.There is also an option to allow the export of the private key. Finally, you can instruct the CA how to act when the subject’s request is received and which CSPs to use. The Subject Name tab seen in Figure 24.9 gives you the choice of obtaining subject name information from Active Directory or from the certificate request itself. In the latter case, auto- enrollment (which we’ll discuss later in the chapter) is not available. Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 839 Figure 24.8 Request Handling Tab of the New Template Property Sheet Figure 24.9 Subject Name Tab of the New Template Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 839 The Issuance Requirements tab enables you to suspend automatic certificate issuance by selecting the CA certificate manager approval check box. The Superseded Templates tab is used to define which certificates the current template supersedes. Usually, this tab is used to configure a template that serves several functions; e.g., IPSec and EFS. In this case, a template used only for IPSec or a template used only for EFS would be placed on the superseded templates list. The Extensions tab, as seen in Figure 24.10, can be used to add such things as the Application Policies extension, which defines the purposes for which a generated certificate can be used.The Issuance Policies extension is also worth mentioning, because it defines when a certificate may be issued. The Security tab is similar to the Security tab that we saw in an earlier example, except that this tab is used to control who may edit the template and who may request certificates using the template. Figure 24.11 shows the default permission level for the Authenticated Users group. For a user to request a certificate, however, the user must have at least the Enroll permission assigned to him or her for manual requests and the Autoenroll permission for automatic requests. 840 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Figure 24.10 Extensions Tab of the New Template Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 840 After you have configured a particular template, the CA still cannot use it to issue certificates until it is made available.To enable a template, use the Certification Authority console and right- click the Certificate Templates container. Selecting New | Certificate Template to Issue completes the process. Certificate Requests A client has three ways to request a certificate from a CA.The most common is auto-enrollment, and we’ll discuss its deployment shortly. A client can also request a certificate by use of the Certificates snap-in. Clicking Start | Run and typing in certmgr.msc and pressing Enter can launch the snap-in. Note that the Certificates snap-in does not appear in the Administrative Tools folder as the Certification Authority snap-in does after installing certificate services. Next, by expanding the Personal container and right-clicking the Certificates container beneath it, you can start the Certificate Request Wizard by choosing All Tasks | Request New Certificate. After the welcome screen, the first screen of the wizard enables you to choose the cer- tificate type.You can only choose a type for which the receiving CA has a template. If you select the Advanced check box, the next screen (Figure 24.12) enables you to choose the Cryptographic Service Provider (CSP) and key length.You can also mark the key as exportable and/or enable strong private key encryption. Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 841 Figure 24.11 Security Tab of the New Template Property Sheet 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 841 Continuing with the advanced options, you can choose Browse the domain to choose a CA to which you want to send the request. Finally, the wizard finishes by prompting you for a friendly name and description for the certificate.The last method for requesting a certificate is to use a Web browser on the client machine. Note that if you use this option, IIS must be installed on the CA. Auto-Enrollment Deployment Perhaps the most exciting new feature of the Windows Server 2003 PKI is the capability to use auto- enrollment for user certificates as well as for computer certificates.The request and issuance of these certificates may proceed without user intervention.There are, however, some strict requirements: ■ Only Windows Server 2003 clients or Windows XP clients can use auto-enrollment. ■ Windows Server 2003 Enterprise Edition or Datacenter Edition is required to configure auto-enrollment for version 2 templates. Group policies are used in Active Directory to configure auto-enrollment. In Computer Configuration | Windows Settings | Security Settings | Public Key Policies, there is a group policy entitled Automatic Certificate Request Settings.The property sheet for this policy enables you to choose to either Enroll certificates automatically or not. Also, you will need to ensure that Enroll subject without requiring any user input option is selected on the Request Handling tab of the certificate template property sheet. Finally, be aware that doing either of the following will cause auto-enrollment to fail: ■ Setting the This number of authorized signatures option on the Issuance Requirements tab to higher than one. ■ Selecting the Supply in the request option on the Subject Name tab. 842 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure Figure 24.12 Cryptographic Service Provider Screen of the Certificate Request Wizard 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 842 Role-Based Administration PKI administration, which can be as daunting as general network administration, can be divided among various groups or individuals. Microsoft defines five different roles that can be used within a PKI to facilitate administration: ■ CA Administrator ■ Certificate Manager ■ Backup Operator ■ Auditor ■ Enrollee At the top of the hierarchy is the CA administrator.The role is defined by the Manage CA per- mission and has the authority to assign other CA roles and to renew the CA’s certificate. Underneath the CA administrator is the certificate manager.The certificate manager role is defined by the Issue and Manage Certificates permission and has the authority to approve enrollment and revocation requests. The Backup Operator and the Auditor roles are actually operating system roles and are not CA specific.The Backup Operator has the authority to back up the CA and the Auditor has the authority to configure and view audit logs of the CA.The final role is that of the Enrollees. All authenticated users are placed in this role and are able to request certificates from the CA. Implementing Smart Card Authentication in the PKI If security is a primary concern for your organization, you might want to consider the use of smart cards for both local and remote authentication.This adds a second level of security to the authenti- cation process. Whereas traditional authentication via password requires only “something you know” (the password), smart card authentication also requires “something you have” (the card). Along with biometric devices such as fingerprint readers and retinal scanners, smart cards repre- sent a more secure way for users to gain access to the network. Smart cards are not as secure as most biometric devices, but they are more widely implemented and have a longer history of use (more than 11 years). In fact, there are many companies that issue smart cards and smart card readers, along with Windows Server 2003-compliant drivers and software. Primarily because of several competing standards, smart card adoption has been slow, but their popularity continues to grow and although they might not replace the standard log-on password anytime soon, smart card technology is full of potential. How Smart Card Authentication Works After setting up an enrollment station (described below), any user with the enrollment agent certifi- cate can issue smart cards to users. Enrollment is the process by which a CA grants a certificate to the card.The card itself generates a public/private key pair, and the certificate is used to protect the Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 843 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 843 public key during transport. After enrollment, the user can insert the card at any workstation on the network, including terminal services clients and remote access clients, as long as a smart card reader is present. If possible, clients logging on to a Windows Server 2003 network will be authenticated with the Kerberos protocol. In traditional authentication, a username and password typed in via the keyboard are used to encrypt communication between the client and the Key Distribution Center (KDC). With smart cards, however, the private key stored in the card digitally automatically signs the timestamp that is sent to the KDC, eliminating the need for a password. In addition to the encrypted timestamp, the card’s certificate (including of course the card’s public key) is sent as well. When the KDC receives the package, known as a ticket-granting ticket (TGT) request, it verifies the public key and then uses the public key to verify the digital signature on the request. If everything checks out, the server authenti- cates the client by returning a ticket that is also encrypted with the card’s public key. Finally, the ticket is decrypted at the client’s workstation by the private key stored in the smart card. Deploying Smart Card Logon Even though smart cards have been around for some time, many different standards still exist.This can complicate the deployment of a smart card solution, especially if Windows Server 2003 does not natively support the hardware you’ve chosen; in that case, several extra steps are required. Windows Server 2003, out of the box, contains drivers for two companies that manufacture smart cards and readers – Schlumberger and Gemplus. For any other vendor’s equipment, you’ll need to install drivers and the CSP that the vendor uses. The first step in deployment is to prepare the appropriate certificate templates.These templates include the following: ■ Enrollment agent ■ Smart card logon ■ Smart card user certificates The templates are not enabled by default and require some configuration. The second step is to issue the enrollment agent certificate. Finally, the smart cards need to be enrolled at the enrollment station. We’ll guide you through the step-by-step deployment process later in this chapter. Smart Card Readers Most smart card readers in today’s market attach to the computer’s USB or serial port. USB equip- ment is strongly recommended if your clients have USB ports. Readers are available in external or internal models, and many cost less than fifty dollars at retail. Readers that are built into a keyboard are also gaining in popularity. Make certain that the readers you choose will read the kind of smart card you plan on issuing. 844 Chapter 24 • Planning, Implementing, and Maintaining a Public Key Infrastructure 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 844 Smart Card Enrollment Station The enrollment station you choose should be a secure system and must be running Windows 2000 or higher. Of course a smart card reader must be installed, and appropriate drivers and CSPs loaded if necessary. Finally, you should install any vendor-supplied utility software. Using Smart Cards To Log On to Windows Smart cards can be used for more than secure authentication. In fact, there are two different tem- plates in Windows Server 2003 that are both used for smart card certificates.The first is the smart card log-on certificate, which, as the name implies, is used only for logons.The second is the smart card user certificate, which, in addition to logons, provides secure e-mail services. For the following example, you’ll use the more common of the two, which is the smart card logon certificate.You will have to have a PKI implemented with at least one CA already running before beginning.You will also need a smart card reader and a smart card to complete this example. Implement and Use Smart Cards 1. On the system acting as the CA, log on as an administrator and open the Certification Authority console by clicking Start | Programs | Administrative Tools | Certification Authority. 2. Expand the appropriate CA container, right-click Certificate Templates, and choose New | Certificate Template to Issue. 3. Select Smartcard Logon and click OK. Repeat step 2 and select Enrollment Agent and then click OK. 4. Right-click Certificate Templates and choose Manage.This displays the Certificate Template snap-in. 5. Right-click the Smartcard Logon template and choose Properties. Click the Security tab. 6. For this example, assign the administrator the role of enrollment agent. Add the Administrator by clicking the Add button. After selecting the Administrator, select the Read and Enroll check boxes. Click OK to finish. Close the console. 7. Log on to the enrollment station system as an administrator. Click Start | Run, type certmgr.msc, and then click OK.This launches the Certificates snap-in. 8. Expand the Personal container, right-click Certificates, and choose All Tasks | Request New Certificate. Proceed past the Certificate Request Wizard’s opening screen by click Next. 9. The next screen shows the Certificate Types screen. Choose Enrollment Agent and click Next. On the next screen, do not type anything in for the Certificate Friendly Name and Description fields.These fields are optional, and you will not use friendly names or their descriptions in this example. Click Next, and then click Finish. A message appears when the certificate has been issued. Close the console. Planning, Implementing, and Maintaining a Public Key Infrastructure • Chapter 24 845 301_BD_W2k3_24.qxd 5/13/04 2:12 PM Page 845 . for the list? The answer is the CDPs, or CRL Distribution Points. CDPs are locations on the network to which a CA publishes the CRL; in the case of an enterprise CA under Windows Server 2003, Active. the top of the hierarchy is the CA administrator .The role is defined by the Manage CA per- mission and has the authority to assign other CA roles and to renew the CA’s certificate. Underneath the. (TGT) request, it verifies the public key and then uses the public key to verify the digital signature on the request. If everything checks out, the server authenti- cates the client by returning