This chapter discusses Microsoft’s Public Key Infrastructure (PKI) solution that is included with Windows Server 2008: Active Directory Certificate Services (AD CS). AD CS acts as a certificate authority (CA) in a PKI by responding to requests for certificate enrollment and the status of existing certificates. Presumably you are already familiar with public key cryptography, PKI, CA, and digital certificates; if you do not understand these concepts then you may want to study them online before diving into this chapter. Wikipedia has a pretty good introductory article with links to more detailed publications available online: http://en.wikipedia.org/wiki/Public_key_infrastructure. Topics covered in this chapter include:

·         Install Active Directory Certificate Services.

·         Configure CA server settings.

·         Manage certificate templates.

·         Manage enrollments.

·         Manage certificate revocations.

Installing Active Directory Certificate Services

A new CA can be the root CA of a new PKI or subordinate to another in an existing PKI. Also, a CA can be integrated with Active Directory Domain Services (AD DS), referred to as an Enterprise CA by Microsoft; or a Standalone CA that is not tied to AD DS. For the purposes of installing a new CA in your lab you can use the default values in the installation wizard to create a new root Enterprise CA. To install an enterprise CA you must log on with a domain administrator account, to install a standalone CA you can log on with any account that has local administrator privileges. To install the CA do the following:

1.       From Server Manager, click Add roles.

2.       Enable the Active Directory Certificate Services check box then click Next twice.

3.       Enable the checkboxes for the Certification Authority, Certification Authority Web Enrollment, and Online Responder role services then click Next. Allow the wizard to install additional required components if prompted.

4.       Enable the Certification Authority check box, then click Next.

5.       Select  Enterprise (or Standalone for a standalone CA), then click Next.

6.       Select Root CA, then click Next.

7.       Now you can configure optional configuration settings but you can accept the defaults for your test lab, click Next twice.

8.       Enter a name for the CA, then click Next.

9.       Accept the default values for the remainder of the wizard an complete the installation

Caution: While installing AD CS is straightforward, creating a solid design for an enterprise PKI is more complex for a variety of reasons. A PKI is the foundation for user, machine, and application authentication and encryption for many different purposes; an inadequate design will lead to all sorts of frustrating problems. A PKI is likely to interact with operating systems, applications, and devices from multiple vendors, the capabilities of each need to be considered. Finally, a PKI is more than a technical solution, it has to meet the business requirements of the organization, these often include political challenges as the needs of some stakeholders may conflict with those of others. PKI design is beyond the scope of the examination and this chapter. There are many other excellent resources available, for example, Microsoft’s Designing a Public Key Infrastructure, is a good place to start.

Before moving on, this quick installation using default values should not imply that the options available in the installation wizard are unimportant. Normally you would choose to create a new key on the Set Up Private Key page, unless you are reinstalling a CA. When creating a new key it is important that you specify an appropriate cryptographic service provider (CSP) with a suitably long key length and a signing algorithm that is strong enough to protect against anticipated threats. For a production deployment you need to understand what the differences are between elliptic curve cryptography, signing algorithms, and the other choices available on the Configure Cryptography for CA page of the wizard, but for the exam I do not think you need that level of expertise. The validity period for the certificate for the CA is important, the proper length will vary from situation to situation, a topic to explore when learning to design a new PKI. The location of the database and database log files can impact performance, for a busy CA you might want to locate them on a storage volume separate from the system volume. Using a RAID array can improve performance and reliability.

Comparing Standalone and Enterprise Certificate Authorities

The obvious difference between an Enterprise CA and a Standalone CA is that only the former is integrated with AD DS. An Enterprise CA has some important advantages: it uses group policy to deliver its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain; user certificates and certificate revocation lists (CRLs) are published to AD DS; certificate templates are used to issue certificates, and autoenrollment is possible. There are scenarios where it may be preferable to not have to deploy AD DS, for example you may not want to tie a publicly available CA to your organization’s internal AD DS domains.

Understanding Certificate Authority Hierarchies

All of the individual CAs in a PKI form a hierarchy. The first server stands at the top of the hierarchy and is referred to as the root CA. Subsequent CAs added to the same PKI are subordinate to the root CA. The root CA is critical to the integrity of the entire PKI, should it be compromised then no certificates created by any CA in the PKI can be trusted. For this reason many organizations will establish their root CA and use it to issue certificates to the second tier of CA servers before taking it offline and storing it, or at least its hard drives, in a vault or some other physically secure location. The second tier servers are then used to enforce policies and procedures and to issue certificates to the third tier CAs. The CAs in this third tier actually issue certificates for use by computers, applications, and users. This approach is even common when Enterprise CAs are planned, typically the root CA will be installed as a Standalone CA, only the second and third tier servers are deployed as Enterprise CAs, as shown in Figure 1.

Figure 1: Simple PKI Design.

Sometimes its necessary to establish trust between two separate PKIs, this is known as a cross-certification hierarchy. A CA in each PKI, sometimes referred to as a bridge CA, issues a subordinate CA certificate to a CA in the other, as shown in Figure 2. This may be necessary when one firm acquires or merges with another. This situation is also likely to arise if different parts of a large organization deploy PKIs independently because it may be easier to establish trust between the two CAs than to try to remove one and issue replacement certificates. Another possible scenario where cross-certification may be desirable is when two organizations wish to partner closely, however the fact that each PKI will accept the certificates from the other requires a that a very high level of trust exist between the organizations.

Figure 2: Cross Certification Between Bridge Certificate Authorities.

 Creating a Certificate Practice Statement

A Certificate Practice Statement (CPS) is a formal document that details the processes and controls for issuing, renewing, revoking, and using certificates for a CA. A CPS is not a technical requirement for deploying AD CS, and it may not be necessary for a PKI that will only be used internally, but they are common, especially for publicly facing CAs. To implement a CPS on a AD CS CA you must use a CAPolicy.inf file. This file is located in the %windir% folder and it is read during the installation and renewal of a CA. The CPS is visible in the CA certificate. Due to legal considerations a CPS may be many pages long, due to space limitations you may wish to specify a URL in the CAPolicy.inf file and publish the complete CPS online. For example, a CAPolicy.inf file may look like this:

For more details on using CAPolicy.inf files refer to Microsoft’s CAPolicy Syntax article available at: http://technet2.microsoft.com/WindowsServer/en/library/25127c1f-4880-4764-85e8-226ce41588881033.mspx?mfr=true. If you have already installed AD CS you can implement a new CAPolicy.inf file by renewing the certificate with the same key used for the orginal CA certificate. To do so enter  the following commands at a command prompt:

You can also renew the certificate and restart the CA within the Certification Authority console by right-clicking on the CA and choosing the appropriate commands from the All Tasks menu.

Configuring CA Server Settings

Although changing some configuration parameters require editing CAPolicy.inf and renewing the CA certificate as described in the previous section most management tasks can be performed using the Certification Authority console, the Certificates Templates console, the Online Responder Management console, or certutil command prompt utility. Specific examples of how to use certutil are presented throughout this chapter, to see the full range of parameters available enter certutil /? at a command prompt.

Archiving Certificate Authority Keys

You should consider archiving private keys to facilitate data recovery in case a user loses theirs. Keys can be manually archived by the owner of the corresponding certificate using the Certificates Microsoft Management Console (MMC) snap-in. There is no shortcut to this snap-in on the Start menu by default, to access it open mmc.exe and manually add the snap-in. You need administrator privileges to access the keys for service and computer accounts. To export the private key for a certificate navigate to the certificate in the console tree (usually Certificates > Personal > Certificates), right-click on it, and select Export. Follow the wizard to complete the process. It is important that you protect the exported copy of the private key by specifying a strong password and then physically protecting the media where the file is stored.

The version of AD CS available in the Windows Server 2008 Enterprise and Datacenter editions can automatically archive private keys and assign a key recovery agent (KRA) who will help users with recovery operations. To enable this feature from Certification Authority assign one or more key recovery agents by right-clicking on the CA, selecting Properties, and then clicking the Recovery Agents tab. Click Archive the Key to enable this feature, then specify the number of agents, and finally click Add to specify each KRA certificate. If the number of agents specified matches the number of KRA certificates then all agents can recover all keys; if the number of agents specified is less than the number of KRA certificates then a round-robin process is used to select which can recover each key.

Now you have to enable key recovery for specify certificate templates, to do so do the following:

1.       Open the Certificate Templates console from the Start menu.

2.       Right-click on the template you want to use and click Duplicate Template.

3.       Enter a display name for the new template and modify any other optional properties you wish on the General tab.

4.       Click the Request Handling tab and enable Archive subject’s encryption private key as shown in figure 3.

Figure 3: Configuring a Certificate Template for Key Recovery.

5.       Click the Security tab and ensure that each group you want to be able to use the template has Read and Enroll permissions. Grant Autoenroll permissions too if you want them to be able to automatically enroll using the template.

6.       If user in your domain do not have email addresses specified in their account information click on the Subject Name tab and deselect the checkboxes for Include e-mail name in subject name and E-mail name.

7.       Click OK

8.       Open the Certification Authority console from the Start menu.

9.       Right-click on the Certificate Templates folder for the CA, select New, then select Certificate Template to Issue.

10.   Select the desired certificate template from the list and click OK. Users should now be able to create requests based on the new certificate template and their private keys should be automatically archived.

The recovery process for automatically archived keys is a little complex because it involves three interdependent procedures: determine the certificate’s serial number; recover the key; restore the key to the client's computer. At a minimum, performing these tasks requires membership in the Domain Admins group, if delegation of administration has been implemented then it may require two separate administrators. To obtain the serial number of an archived certificate from the Certification Authority console do the following:

1.       Navigate to the CA name and click Issued Certificates.

2.       Select Add/Remove Columns on the View menu, click Archived Key, and then click Add.

3.       Click OK.

4.       Scroll to the right in the details pane to verify that there is a Yes value in the Archived Key column for the last certificate issued to the user, as shown in figure 4.

Figure 4: Verifying That the Private Key is Archived for a User Certificate.

5.       Double-click the certificate and select the Details tab.

6.       Record the serial number of the certificate, without spaces. This is a 20 character hexadecimal string, as shown in figure 5.

Figure 5: Retrieving the Serial Number for a User Certificate.

7.       Click OK.

8.       Open a command prompt and enter Certutil -getkey serialnumber filename where serialnumber is the number you recorded in step 6 and filename is the name of the file where the Binary Large Object (BLOB) will be stored. Note that the output of this command specifies the serial numbers of the KRA certificates whose private keys are needed to decrypt the blob and recover the key at Recipient Info.

9.       Forward the file containing the recovery BLOB to the KRA.

10.   The KRA enters the following command at a command prompt on the CA: certutil –recoverkey filename keyfilename.pfx where filename is the name of the file with the BLOB and keyfilename is the name of the file where the private key is to be saved.

11.   When prompted enter a strong password two times.

12.   Copy the saved .pfx file to the end user’s computer where the data is stored.

Now the end user or someone with administrative privileges must log onto their computer to complete the process:

13.   Open the Certificates snap-in for the user.

14.   Navigate to the Personal folder and right click on it, select All Tasks, then click Import.

15.   The Certificate Import Wizard starts, click Next.

16.   Specify the path and name for the .pfx file and click Next.

17.   Enter the password specified in step 11 and click Next.

18.   Select Automatically select the certificate store based on the type of certificate, and then click Next.

19.   Click Finish.

Important: You may want to block the exporting of private keys for the most sensitive keys in your organization, however the risk of never being able to access critical data due to a lost key versus the added security must be carefully weighed.

Backing Up and Restoring the Certificate Authority Database

You can safely backup the AD CS database by backing up the entire server using Windows Server Backup, as described in Maintaining the Active Directory Environment. However, there may be situations when you only want to backup the database, you can do this using the Certification Authority console by right-clicking on the name of the CA, clicking All Tasks, and selecting Back Up CA; follow the instructions presented in the wizard. You can also backup the CA from a command prompt by entering certutil –backup backupfile where backupfile is the name of the file to store the backup data.

 Delegating Certificate Authority Administration

You can implement role-based administration in AD CS, however there are only a few pre-defined roles, others you have to establish by creating groups and assigning them suitable permissions. By default the local Administrators, Enterprise Admins, and Domain Admins groups have full control of all aspects of management on an Enterprise CA but only local Administrators have full control on Standalone CAs. The KRA role was described earlier in this chapter, holders of this role participate in the recovery of private keys. Members of the local Backup Operators group and  users who have the Backup files and directories user right are able to backup the CA database. Members of the local Backup Operators group and  users who have the Restore files and directories user right are able to restore the CA database. Users who have the Manage auditing and security log user right are able to configure auditing and the security event log and to examine events related to the CA.

Another role you could easily establish is that of certificate manager, a user who can manage certificate enrollment requests. In figure 6 you can see that I created a new local group called Cert Managers and gave that group permission to manage certificates. The Security tab is available on the properties dialog box for the CA, which you access in the Certificate Authorities console by right-clicking the CA, selecting Properties, and then clicking the Security tab. Members of this group can manage certificate enrollment requests yet they do not have to have full administrative privileges on the server to do so. You can also create a new group and assign in the Manage CA permission which allows them to manage all aspects of the CA without requiring local administrative privileges.

Figure 6: Configuring CA Permissions.

You can further refine what a group of certificate managers can do by clicking the Certificate Managers tab in the properties dialog box, as shown in figure 7. The way this tab works may be different then what you are used to. Select a group to configure in the Certificate Managers box; then click the Add button next to the Certificate Templates box to select a template. Now you configure what groups the certificate managers group will control for this particular template by clicking Add next to the Permissions box. You can specify that the certificate managers can manage enrollment requests based on the template specified when they are created by the groups in this list, you can also prevent them from managing requests from a group by assigning the deny permission.

Figure 7: Restricting Certificate Managers

Managing Certificate Templates

The term certificate templates has already been mentioned several times, however its important that you understand precisely what they are and how they are managed. A certificate template defines what characteristics and capabilities are present in certificates based on it. When a certificate is requested the request is based on one of the templates available on the CA that the user or computer has permission to access. Windows Server 2008 supports three versions of certificate templates: Version 1 are available with the Standard Edition of Windows Server 2008 and they can only be used for manual enrollment, they are compatible with Windows 2000 an later versions of Windows. Versions 2 and 3 are supported in Windows Server 2008 Enterprise or Datacenter edition. Version 2 allows you to configure autoenrollment, they are compatible with Windows XP and later versions of Windows. Version 3 are only supported by Windows Vista and Windows Server 2008, when they are used you can specify cryptographic settings not available in earlier versions of Windows such as the Elliptic-Curve Digital Signature Algorithm.

Many certificate templates are built into AD CS including those for web servers, domain controllers, EFS, KRA, code signing, and IPsec. As explained earlier, you can create new templates with customized settings by copying an existing one using the Certificate Templates console. You can make new templates available to users of the CA by right-clicking the Certificate Templates folder for the CA in the Certification Authority console, selecting New, and then selecting Certificate Template to Issue. You can remove a template from the list by right-clicking on it and selecting Delete.

 Configuring Certificate Template Security

Which certificate templates a user or computer can access is controlled by the permissions on the templates. You configure the permissions using the Certificate Templates console, right-click on a template, select Properties, and then click the Security tab to do so. To be able to request certificates based on a template the user or computer needs Read and Enroll permissions, Autoenroll permissions enable to automatically enroll using the template. Write permissions should only be assigned to the users who you want to allow to modify the template.

 Managing Multiple Certificate Template Versions

To create a new certificate template you should duplicate the one that is closest in function to what you wish for the new one. After duplicating a template you can customize to fit your requirements. When you want to modify certificates that have already been deployed you have to create a new certificate template with the desired settings and configure it to supersede the older one. To do so right-click on the new template, select Properties, and click the Superseded Templates tab. Click Add and select one or more templates to supersede and then click OK. Clients will receive an updated certificate based on the new template when they renew their existing one. You can force them to reenroll immediately by right-clicking on the new template and selecting Reenroll All Certificate Holders, however this can only be done with version 2 and 3 templates.

 Managing Certificate Enrollment

The process of users and computers requesting and receiving certificates is referred to as enrollment. This section discusses the tasks relating to enrollment including manually responding to requests and configuring autoenrollment.

Processing Certificate Requests

Enrollment requests that must be processed manually are queued, you can view and manage this list in the Certification Authority console by navigating to the Pending Requests folder for the CA. To act on a request right-click on it, select All Tasks, and then click on Issue or Deny as shown in figure 8. You can see more details for a request by selecting View Attributes/Extensions instead.

Figure 8: Issuing a Requested Certificate.

 Configuring Autoenrollment

Autoenrollment eases the burden of issuing large numbers of certificates because the CA automatically issues certificates when the request is based on a certificate template that allows autoenrollment. Group policy can be configured so that requests are issued without the user needing to do anything, the location in the Group Policy Editor is \Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client – Auto-Enrollment, under both User Configuration and Computer Configuration. After enabling the setting you can also enable Renew expired certificates, update pending certificates, and remove revoked certificates, Update certificates that use certificate templates, and Expiration notification. You then enable Enroll subject without requiring any user input on the Request Handling tab of the certificate template’s properties, as shown in figure 3. You can adjust the level of user input using either of the next two options on that tab: Prompt the user during enrollment or Prompt the user during enrollment and require user input when the private key is used.

Figure 9 illustrates the Issuance Requirements tab for a certificate template. This is where you can specify that a certificate can be approved automatically, or that it will require approval by a CA manager.

Figure 9: Configuring Issuance Requirements for a Certificate Template.

Configuring Web Enrollment

To configure your CA to support web enrollment you must install the optional role service called Certification Authority Web Enrollment. This role service also requires the Web Server (IIS) server role and the Windows Process Activation Service feature. To protect communications between the CA and clients submitting requests network traffic must be protected with Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Open Internet Information services (IIS) Manager, click the server in the navigation pane and double-click Server Certificates in the middle pane. For your lab you can click Create Self-Signed Certificate, but this means that users will be presented with a warning that the certificate may be invalid and the website dangerous when the visit it. For production systems you should install a certificate that will be recognized and trusted by clients by clicking Import to add a certificate that is already complete or by clicking Create Certificate Request to generate a request and then Complete Certificate Request when the request has been approved.

By default a virtual folder called CertEnroll is added to the default web site, users connect to https://servername/CertEnroll to manually request a certificate, where servername is the name of the CA. If the virtual directory is accidentally deleted you can recreate it by entering certutil –vroot at a command prompt.

Configuring Smart Card Enrollment

To distribute smartcards for user authentication you configure the appropriate certificate templates, set up a smart card enrollment station, configure smart card clients with the necessary hardware and software, and then issue the smart cards to users. The person configuring smart cards for end users needs to obtain an Enrollment Agent certificate by doing the following:

1.       Open the Certificates snap-in as described in the Archiving Certificate Authority Keys section earlier in this chapter.

2.       Expand  Personal, right-click on Certificates, select All Tasks, select Request New Certificate.

3.       The Certificate Enrollment wizard will launch, click Next.

4.       Select Enrollment Agent and click Enroll. If this type of certificate is not visible in the list then you must add it to the list of available certificate templates as described in the Managing Certificate Templates section of this chapter.

Now you can request certificates for other users, to request a certificate for someone else do the following from the Certificates snap-in:

1.       Right-click on Certificates, select All Tasks, select Advanced Options, and select Enroll on Behalf of.

2.       The Certificate Enrollment wizard will launch, click Next.

3.       Click Browse and navigate to the Enrollment Agent certificate that you will use, click Next.

4.       Select which kind of certificate you wish to be able to request on the behalf of other users, as shown in figure 10.

Figure 10: Selecting a Certificate Template.

5.       Specify which user you are enrolling for, then click Enroll.

6.       Click Next User to continue enrolling for additional users, or click Cancel to finish.

 Configuring Enrollment Agents

Prior to Windows Server 2008 an enrollment agent could not be restricted, now they can be limited to specific version 3 certificate template. Version 1 and version 2 templates do not support this feature. From the Certification Authority console, right-click on the CA and select Properties, then click the Enrollment Agents tab. This tab functions similarly to the Certification Managers tab discussed previously.

1.       First you add and remove enrollment agents by clicking the appropriate button next to the Enrollment agents box.

2.       Then you select an enrollment agent from the list and select a template by clicking the Add button next to the Certificate Templates box.

3.       Now you assign permissions, either allow or deny, for different groups by clicking the Add button next to the Permissions box. You toggle the permission by selecting the group and clicking the Deny/Allow button.

Figure 11: Configuring Enrollment Agent Restrictions.

 Configuring the Network Device Enrollment Service

The Simple Certificate Enrollment Protocol (SCEP) was created to support issuing digital certificates to network devices. Windows Server 2008 supports SCEP via the Network Device Enrollment Service (NDES) role service. This is an optional role service that must be installed on a computer separate from the CA. It requires the Web Server (IIS) role and the Windows Process Activation Service feature, you should install these before NDES so that you can create a new domain user and add it to the local IIS_IUSR group before installing NDES. This account will be used for issuing certificate requests. To request and enroll a certificate via NDES do the following:

1.       Generate the RSA public/private key pair on the network device following the manufacturer’s directions.

2.       Forward the key pair to the server hosting NDES.

3.       Use Internet Explorer on that server to navigate to http://localhost/certsrv/mscep_admin.

4.       Note the password provided, use it with the network device’s software to submit a certificate request through NDES.

5.       If successful NDES will forward the request to the CA, the CA will issue the certificate to NDES which then returns the certificate to the network device.

Note: By default NDES will cache up to 5 passwords, each is good for up to 60 minutes and can only be used one time. If the cache is full you must wait for a password to expire and a replacement added or stop and start IIS to delete all passwords.

 Managing Certificate Revocation

Several scenarios can arise where you can no longer trust a digital certificate. If an employee leaves the firm you would not want that person to be able to continue accessing business data. If a server is compromised you cannot allow it to access the network because you have no way of being certain that you are able to control the attacker’s actions on it. If an employee’s account is exploited you have to change their password and replace their digital certificates to keep the attacker from expanding their beachhead into your network. In all of these situations you need to revoke the certificate and communicate its changed status to anyone who would normally trust that certificate as quickly as possible. AD CS includes two technologies to support this behavior: certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP).

 Managing the Certificate Revocation List

A CRL is the list of a CA’s certificates that have been revoked, applications that use PKI technology can examine the CRL Distribution Points field in the certificate to identify the URL where the CA that created the certificate publishes its CRL, as shown in figure 12. One of the problems with using a CRL is that they continuously grow, more and more certificates are added to the list but normally few are ever removed. I know of a government agency who has a CRL over 100 megabytes, they have had a PKI running for over a decade and have issued millions of certificates so such a large list of revoked certificates is not surprising. There are several problems with such a large CRL. First, clients have to download it which puts a tremendous strain on the server and network where the CRL is hosted and clients have to wait. Another issue is that the clients have to load the list into memory and compare the public certificate with the CRL, which means more waiting.

Figure 12: Viewing the CRL for a Certificate.

Microsoft introduced delta CRLs in Windows XP to try to address these problems. Every version of Windows since Windows XP supports delta CRLs and Microsoft published a hotfix in 2004, MS04-011, which adds the capability to Windows 2000. Delta CRLs reduce the amount of data that must be downloaded by clients when they want to verify that a certificate has not been revoked because the delta CRL only includes certificates revoked since the last base CRL. You revoke a certificate using the Certification Authority console by right-clicking on it, selecting All Tasks, and then selecting Revoke Certificate. You can specify a reason for revoking the certificate as well as a date and time for revocation to occur, as shown in figure 13.

Figure 13: Revoking a Certificate.

Configuring a CRL Distribution Point

A CRL distribution point (CDP) is a location where clients can download the CRL. Obviously you want to make sure the CDP is located on a network where clients that will be accepting certificates can access it. If the CA is publicly accessible then the CDP should also be publicly accessible. The CDP can be on the same server as the CA, or hosted on an entirely different one. By default AD CS publishes base CRLs weekly and delta CRLs daily. You can modify this behavior by right-clicking on the Revoked Certificates folder for the CA in the Certification Authority console and selecting Properties. You can also force the immediate update of either the CRL or the delta CRL by right-clicking on the Revoked Certificates folder, selecting All Tasks, then selecting Publish CRL. You can publish either a new base CRL or delta CRL.

Information: There is another flaw with PKI technology related to CRLs that does not get as much attention as you might expect once you fully understand it. Windows includes several certificates for third-party root CAs, Windows Server 2008 includes a handful while Windows Vista has a few more, earlier editions of Windows had many more. These certificates are necessary because they establish the base level trust that makes it possible for people to use SSL and TLS while visiting public websites such as financial institutions. The publishers of these certificates usually do not include a CRL Distribution Points field. The logic is simple: hundreds of millions of people visiting websites protected by SSL and TLS several times a day would generate a gargantuan amount of network traffic should they all try to download the CRL and delta CRL periodically.

This is a problem though, a pretty bad one. What happens if one of those root CAs is compromised? If you cannot revoke the certificate yet you know the CA can no longer be trusted what risks are those hundreds of millions of web surfers facing? A similar problem came up a few years ago when Verisign issued a pair of code-signing certs to someone pretending to work at Microsoft. The only way to fix it was for Microsoft to issue a hotfix which informed the operating system that these certificates could no longer be trusted: http://www.microsoft.com/technet/security/bulletin/MS01-017.asp. You can investigate the trusted root certificates yourself; take a look at the details of each certificate in your personal store located under the Third-Party Root Certification Authorities folder in the Certificates snap-in. I suspect that non-Microsoft operating systems and browsers include similar lists of built-in certificates that also do not include a CRL.

The firms that created these certificates would probably assert one of two things: One, the certificates signed by the CA include a CRL, that is good but we still cannot verify that the root cert has not been revoked. Two, they have a well-known address where anyone can download their CRL, that would help a little but it would mean that everyone who develops security products would have to hardcode the address in their applications, some may do that but I doubt that all would.

 Configuring Online Responders

Delta CRLs do not completely resolve the challenge of dealing with huge lists of revoked certificates. The base CRL still has to be updated periodically, and clients have to download the base CRL each time it is updated. The Online Certificate Status Protocol (OCSP) is a better solution, OCSP clients can check the validity of an individual certificate rather than having to download the entire list and check it themselves. This moves the workload to the OCSP server, but it dramatically reduces the amount of network traffic. Windows Server 2008 implements support for OCSP in the Online Responder Service role service, typically its installed on subordinate CAs but not the root CA. It relies on the Web Server (IIS) server role and the Windows Process Activation service feature. During installation a virtual directory called ocsp is installed that points to %systemroot%\SystemData\ocsp, OCSP clients connect to virtual directory to utilize the service.

Open Online Responder Management from the Administrative Tools folder to configure OCSP. You can right-click the online responder to configure its properties or retarget it to point to a remote CA. You must right-click Revocation Configuration in the navigation tree and select Add Revocation Configuration before the responder will start answering OCSP queries. The wizard will prompt you to name the configuration, to specify a CA certificate for the configuration, to select a signing certificate, and to select a revocation provider, e.g. the CRL for the CA. For the online responder to be able to autoenroll for its OCSP signing certificate you have to make sure that the OCSP Response Signing certificate template is available in the Certificate Template folder of the Certification Authority console. You also need to ensure that the Online Responder Service’s service account has read, enroll, and autoenroll permissions to the template using the Certificate Templates console. For fault tolerance you can create arrays of online responders, however requests are not automatically distributed amongst them.

After installing and configuring the Online Responder you need to configure the Authority Information Access (AIA) extension of the CA to include the OCSP URL. You can do this using the Certification Authority console, right-click on the CA and select Properties. Navigate to the Extensions tab and select Authority Information Access (AIA) from the Select extension dropdown list. Click Add and enter the URL for the online responder, then enable both Include in the AIA extension of issued certificates and Include in the online certificate status protocol (OCSP) extension, as shown in figure 14.

Figure 14: Configuring the Authority Information Access Extension.

Summary

This chapter showed you how to install and configure a Windows-based CA and optional role services such as Certificate Authority Web Enrollment and Online Responder. Information about configuring certificate enrollment, autoenrollment, and revocation was presented. Additionally, instructions on delegating CA administration, defining key recovery agents, and setting up enrollment agents were all provided. To repeat the caveat mentioned at the beginning of this chapter, the information provided is really focused on configuring and managing AD CS, very little guidance on designing a sound PKI was included, for that type of information please review the resources noted previously and in the References section at the end of the chapter.

Chapter Review

This section presents a list of review questions designed to help reinforce the knowledge presented earlier in the chapter. To persuade you to explore the management tools more deeply a few questions may require you to examine those tools further rather than rereading the chapter.

Questions

1. What is the advantage of OCSP over CRLs?
   1. OCSP reduces the load on the servers by moving some of the workload to the clients.
   2. OCSP provides information that is more up-to-date than a CRL.
   3. OCSP reduces network traffic.
   4. OCSP reduces the size of the list of revoked certificates.
2. Which AD CS role service cannot be installed on the same server as the CA?
   1. Certification Authority Web Enrollment.
   2. Network Device Enrollment Service.
   3. Certificate Revocation List Host.
   4. Online Responder.
   5. Online Certificates Status Protocol Service.
3. Which of the following terms is used to describe the relationship between two distinct PKIs that trust one another?
   1. Domain trust.
   2. Cross realm trust.
   3. Public key chaining.
   4. Third-party certification.
   5. Cross-certification hierarchy.
4. The first phase of your organization’s PKI deployment is complete when the legal department and executive team explain that they have completed writing the certificate practices statement (CPS), a four page document that they may want to modify further after the external legal advisors review it. Which of the following would be the most efficient way to ensure that all of the CAs provide information in the CPS?
   1. Configure the CPS using the Certification Authority console, then stop and restart the Active Directory Certificate Services service, repeat for each CA.
   2. Publish the CPS on a web server, add the URL for the CPS to the CAPolicy.inf file on the root CA, renew the certificate for the root CA using certutil, then stop and restart the Active Directory Certificate Services service. The URL will automatically be propagated to all subordinate CAs.
   3. Add the CPS to the CAPolicy.inf file on each CA, renew the certificate for each CA using certutil, then stop and restart the Active Directory Certificate Services service.
   4.  Publish the CPS on a web server, add the URL for the CPS to the CAPolicy.inf file on each CA, renew the certificate for each CA using certutil, then stop and restart the Active Directory Certificate Services service on each.
5. Which of the following management tools is used to export a private key?
   1. Certification Authority console.
   2. Certificates snap-in.
   3. Certificates Templates console.
   4. Online Responder Management console.
6. Which tool do you use to manage permissions on a certificate template?
   1. Certification Authority console.
   2. Active Directory Users and Computers
   3. Certificates snap-in.
   4. Certificates Templates console.
   5. Windows Explorer.
7. Using the correct management tool you have created a new certificate template based on a built-in one and name it EFS User. You have configured security on the new template so that Authenticated Users have Read, Enroll, and Autoenroll permissions. When you try to test the certificate template by requesting a new certificate with the Certificates snap-in the certificates are not visible, as shown in figure 15. You then try to request the certification with Internet Explorer and once again, the certificate template is not available from the list, as shown in figure 16. What is the most likely cause of this problem?

Figure 15: Viewing Available Certificate Templates.

Figure 16: Viewing Available Certificate Templates with a Web Browser.

1. The certificate template has not been added to the list of available ones on the CA.
2. The permissions need to be manually adjusted using Windows Explorer or a command prompt tool for managing file permissions like cacls.
3. The Active Directory Certificate Services service needs to be restarted so that the CA will recognize that the new template is available.
4. The Internet Information Services (IIS) service needs to be restarted so that the new template can be seen by clients because it is not yet present the web server’s content cache.
7. Which version or versions of certificate templates support restriction of enrollment agents?
   1. Versions 1, 2, and 3.
   2. Version 2.
   3. Version 3.
   4. Versions 2 and 3.
8. Which applications can be used to submit a request for a new digital certificate or to renew an existing one?
   1. Certification Authority console.
   2. Certificates snap-in.
   3. Internet Explorer.
   4. Certutil.
   5. All of the above.
9.  What is the Simple Certificate Enrollment Protocol (SCEP) designed to do?
   1. To support autoenrollment of user and computer certificates.
   2. To support web-based enrollment of user and computer certificates.
   3. To support issuing certificates to network devices.
   4. To support enrollment of certificates via the Lightweight Directory Access Protocol (LDAP).
10. Look at figure 17, which object would you click on in the navigation tree of the Certification Authority console to revoke certificates?
    1. Certification Authority (Local).
    2. Dillard-DC2-CA.
    3. Revoked Certificates.
    4. Issued Certificates.
    5. Pending Requests.
    6. Failed Requests.

Figure 17: Configuring the CA.

12. Look at figure 17, which object would you click on in the navigation tree of the Certification Authority console to publish an updated CRL?
    1. Certification Authority (Local).
    2. Dillard-DC2-CA.
    3. Revoked Certificates.
    4. Issued Certificates.
    5. Pending Requests.
    6. Failed Requests.
13. Which versions of Windows support delta CRLs?
    1. Windows 2000 and later.
    2. Windows XP and later.
    3. Windows Server 2003 and later.
    4. Windows Vista and Windows Server 2008.
    5. Windows Server 2008.
14. The Online Responder Service must be installed on the same physical server as the CA.
    1. True.
    2. False.
15. Look at figure 18, which tab would you click on to configure the OCSP URL?
    1. Extensions
    2. Storage
    3. Auditing
    4. Security
    5. Policy Module
    6. Exit Module

Figure 18: Managing CA Properties.

 Answers

1. C is correct. A has it backwards, the load is moved to the server hosting OCSP. B is incorrect because the OCSP data is based on the CRL. C is completely made up!
2. B is correct, both the Network Device Enrollment Service and Online Responder roles can be combined with the CA role. C and E are incorrect because they are fictional role services.
3. E is correct.
4. D is correct, by publishing the full CPS on a web server updates can be posted in that single location. A is false, there is no way to modify the CPS using the Certification Authority console. B is incorrect because the URL will not be automatically copied to the subordinate CAs. C would work if the CPS were very short, but its four pages long, and even if it were short future updates would require touching all of the CAs again rather than simply updating a single document on the web server.
5. B is correct, there is no shortcut to this snap-in by default, to view it you have to manually create a new console using MMC, as described in the Archiving Certificate Authority Keys section of this chapter.
6. D is correct.
7. A is correct, you never need to manage certificate template permissions in the file system so B is false. C and D are incorrect because new templates are available immediately after they are added to the CA’s list.
8. C is correct, version 3 certificate templates are only supported in Windows Vista and Windows Server 2008 and they are the only version with this feature.
9. E is correct. Examples of using the Certificates snap-in and Internet Explorer to request new certificates were presented in the chapter. Using certutil and the Certification Authority console to renew the CA’s certificate was also discussed. Using Certification Authority console to request a new certificate was not demonstrated, you can use it to submit requests that have been forwarded as request files (.req, .cmc, .der, .cer, .crt, etc.) by right-clicking on the CA in the Certification Authority console, selecting All Tasks, and then selecting Submit new request.
10. C is correct, SCEP is supported in the Network Device Enrollment Service (NDES) role service.
11. D is correct, you click Issued Certificates, then right-click on a specific certificate, select All Tasks, and then select Revoke Certificate.
12. C is correct, you right-click on Revoked Certificates, select All Tasks, and then select Publish.
13. B is correct, however Windows 2000 does if you install the appropriate hotfix, MS04-11. This is an annoying question, be certain to carefully read the entire question to figure out whether or not they assume the hotfix is included on Windows 2000 if you encounter something like this on the exam.
14. B is correct, this optional service role can be installed with the CA or separately from it. There are advantages in separating them, you can increase performance of both systems and you can deploy an array of online responders to provide redundancy.
15. A is correct, from the Extensions tab you would select Authority Information Access (AIA) from the Select extension dropdown list. Click Add and enter the URL for the online responder. You should also enable both Include in the AIA extension of issued certificates and Include in the online certificate status protocol (OCSP) extension.

References

Microsoft’s PKI Blog.

Active Directory Certificate Services page.

Public Key Infrastructure for Windows Server 2003.