Implementing Certification Authorities

EXAM 70-293 OBJECTIVE 6, 6.1, 6.2.1

Planning a PKI structure that includes multiple CAs in a hierarchy with proper security can be a test in patience and fortitude. The actual implementation, however, is relatively simple. In Exercise 12.01, you installed certificate services and chose to create an enterprise root CA. That’s pretty much it for the implementation of a CA, but there is much more involved in the configuration of process. Before we talk about the differences between enterprise and stand-alone CAs, and the security concerns involved, we’ll go over the many options you have control over in the following exercise.

Exercise 12.02: Configuring a Certification Authority

In this exercise, we’ll explore the different properties you have control over when configuring a CA. We won’t go over all the options now, but we will cover them all in this chapter.

1. Click Start | Administrative Tools | Certification Authority (note that certificate services must be installed before this step – see Exercise 12.01; otherwise, this choice will not appear in the Administrative Tools menu).

2. In the left pane of the Certification Authority snap-in, click My Root CA (or whichever CA name you have listed) and expand it. As Figure 12.7 shows, this is where you can view revoked and issued certificates, pending and failed certificates, and certificate templates (discussed later in this chapter).

   
   Figure 12.7: The Certification Authority Snap-In

3. Highlight My Root CA and right-click it. Click Properties. Figure 12.8 shows the General tab. Here, all installed CA certificates are listed as well as the CSP and hash algorithms used. Click View Certificate if you want to see the certificate itself.

   
   Figure 12.8: General Tab of the CA Property Sheet

4. Click the Policy Module tab. A policy module defines how the CA handles incoming certificate requests. Notice in Figure 12.9 that the Windows default policy is listed. The Select button is used to choose a different policy module, usually a customized version. Click the Properties button (see Figure 12.10). The default setting tells the CA to follow the settings in the certificate template if applicable and to automatically issue the certificate otherwise. The other setting tags all incoming requests to pending status, forcing the administrator to manually approve or deny each certificate request. Keep the default setting and click OK to return to the CA property sheet.

   
   Figure 12.9: Policy Module Tab of the CA Property Sheet

   
   Figure 12.10: Request Handling Tab of the Default Policy Module

5. Click the Exit Module tab. Whereas a policy module defines how a CA handles incoming certificate requests, an exit module defines what a CA does with certificates that it issues. Figure 12.11 shows that the Windows default policy is listed. In addition to the Add and Remove buttons, there is a Properties button. Click the Properties button. Figure 12.12 shows that the only setting is to allow certificates to be published to the file system if a certificate template dictates, which the default policy does not allow. Again, keep the default setting and click OK to return to the CA properties sheet. Skip the Extensions tab for now; we’ll discuss it when we talk about certificate revocations later in the chapter.

   
   Figure 12.11: Exit Module Tab of the CA Property Sheet

   
   Figure 12.12: Publication Settings Tab of the Default Exit Module

6. Click the Storage tab. Note that the default settings cannot be changed because Active Directory is being used. We’ll discuss more about the relationship between Active Directory and enterprise CAs later in this chapter.

7. Click the Certificate Managers Restrictions tab. The default setting here tells the CA to not restrict certificate managers. As an administrator, you can designate certificate managers by giving them the Issue and Manage Certificates permission. By changing the default, you can specifically restrict the users, groups, and computers over which a certificate manager has control.

8. Click the Auditing tab. As seen in Figure 12.13, there are many events that you can monitor – each concerned with a different aspect of security. Especially important are the Change CA configuration, Change CA security settings, and Issue and manage certificate requests events. Skip the Recovery Agents tab; we’ll cover it during our discussion of key archival and recovery.

   
   Figure 12.13: Auditing Tab of the CA Property Sheet

9. Click the Security tab. The Security tab, shown in Figure 12.14, enables you to grant or deny access to users over several key areas of the CA. Note that the Issue and Manage Certificates permission denotes a certificate manager, whereas the Manage CA permission gives authoritative access to the entire CA. Click Cancel to return to the CA snap-in.

   
   Figure 12.14: Security Tab of the CA Property Sheet

Analyzing Certificate Needs within the Organization

You’ve just concluded a tour of most of the properties associated with a CA, but knowing what you can do does not mean that you know what you should do. To find out more about what you should do, you need to analyze the certificate needs of your organization and then move on to create an appropriate CA structure.

According to Microsoft’s TechNet, the analysis of certificate needs springs primarily from “the analysis of business requirements and the analysis of applications that benefit from PKI-based security.” In other words, when designing a PKI/CA structure, you need to understand the different uses for certificates and whether your organization needs to use certificates for each of these purposes. Examples include SSL for a secure Web server, EFS for encryption of files, and S/MIME for encryption of e-mail messages. The use of S/MIME might dictate that your CA hierarchy has a trust relationship with external CAs, and the use of SSL might lead you to implement a stand-alone CA instead of an enterprise CA. Thus, analyzing these needs before you implement your PKI can save you a lot of time and trouble.

Determining Appropriate CA Type(s)

For most administrators, the most significant factor in designing a CA structure is the amount of PKI-related traffic on the network. If you run a small organization without an Internet presence, for example, a single-root CA that issues certificates directly to users will probably fit the bill. However, in a larger organization, a CA hierarchy is likely to be more appropriate.

The first choice when determining appropriate CA types for your PKI is how many subordination levels to use. One level, the root, is required. Two, three, and even four subordination levels are relatively common, but the three-tier model is the one most referenced and most-frequently used. So how does the three-tier model work? We’ve discussed previously the differences between a root CA and a subordinate CA, and that a root CA issues certificates to the second-tier subordinates. In the standard three-tier model, the root CA has the job of issuing certificates to the second-tier. That’s all it really does. Certainly it has the capability of doing more – it could even issue certificates to users. However in a large company, the amount of traffic generated by even a few PKI-aware applications could easily overwhelm a single CA. Also, if you shift the responsibility of issuing certificates to subordinate CAs, you can take the root CA offline – meaning that you detach it from the network entirely. This provides a very high level of security, because attackers have no way of getting to the machine. When a subordinate CA requires a certificate from the root, you can either briefly connect the root CA to the network and then remove it again, or you can literally use a floppy disk.

The intermediate level of CAs, the one just below the root, has the responsibility for controlling certificate policy and issuing certificates to the bottom-level CAs. These bottom-level CAs are the ones that actually issue certificates to users, machines, and applications. The question then becomes: why don’t the intermediate CAs just issue the user certificates directly? The answer is that although they can, it just isn’t as scalable as the three-tier model. It is easier to add CAs to the hierarchy that are concerned only with issuing certificates and not involved with policies such as key length and CSP choice.

After you have determined the hierarchical structure of your CAs, you will need to determine which CAs are set up as enterprise CAs and which ones are set up as stand-alone CAs before implementing them. You may recall that in Exercise 12.01 you installed certificate services and chose an enterprise root CA. The choice in your network will depend on several different factors, such as your needed level of security. Both enterprise and stand-alone CAs have advantages and disadvantages. We’ll explore some of them in the following sections.

Enterprise CAs

An enterprise CA is tied into Active Directory (AD) and is required to use it. In fact, a copy of its own CA certificate itself is stored in Active Directory. Perhaps the biggest difference between an enterprise CA and a stand-alone CA is that enterprise CAs use Kerberos or NTLM authentication to validate users and computers before certificates are issued. This provides additional security to the PKI because the validation process relies on the strength of the Kerberos protocol and not a human administrator. Enterprise CAs also use templates, which are described later in this chapter, and they can issue every type of certificate.

There are also several downsides to an enterprise CA. In comparison to a stand-alone CA, enterprise CAs are more difficult to maintain and require a much more in-depth knowledge about Active Directory and authentication. Also, because an enterprise CA requires Active Directory, it is nearly impossible to remove it from the network. If you were to do so, the Directory itself would quickly become outdated – making it difficult to resynchronize with the rest of the network when brought back online. This forces an enterprise CA to remain attached to the network, leaving it vulnerable to attackers.

Stand-Alone CAs

Stand-alone CAs do not require Active Directory (although they can use AD information if it is available), and are usually used as either secure root CAs or as an issuer to such applications as stand-alone Web servers. Stand-alone CAs are generally not suitable for enterprise-type applications. Because certificate templates are not used on a stand-alone CA, a standalone is more basic and easier to maintain than an enterprise CA. A stand-alone CA keeps a copy of its CA certificate in a shared folder and if Active Directory is not used, users that need to request certificates need to know the location of the CA. Finally, stand-alone servers can be secured by removing them from the network.

The disadvantages to a stand-alone CA are that an administrator must manually approve or deny every certificate request individually, a stand-alone CA cannot issue log-on certificates, and templates cannot be used with a stand-alone CA, so a key recovery agent cannot be established (we discuss the key recovery agent template below).

Exam Warning

A stand-alone CA does not need Active Directory as an enterprise CA does. For test day, remember that without Active Directory, all certificate requests made to a stand-alone CA are automatically tagged as pending. This means that automatic fulfillment is not available and an administrator must manually approve or deny each incoming request. Under Windows Server 2003, stand-alone CAs can be configured to accept requests automatically, but that is not the default setting.

Planning the CA Hierarchy

There is more than meets the eye when planning a CA hierarchy. We’ve already discussed choices you will need to make between root and subordinate and between enterprise and standalone. You will also need to consider possible cross-trust hierarchies and the establishment of the key recovery agent.

Cross-Trust Hierarchies

For a PKI entity to use a certificate provided by a CA, the entity must trust that CA. This trust is established when the entity has a copy of the CA’s certificate located in its local certificate store. Using the public key contained in the certificate, the entity can verify the CA’s digital signature. How, then, does the certificate get from the CA to the entity’s local store? Unfortunately, there is not just one answer. Group policies under Active Directory, preloaded certificates in Windows Server 2003, and downloads from the Windows Update Web site are the most common ways.

The chain of trust from an issuing CA all the way up to the root CA must be verified by an entity requesting a certificate for the certificate to be accepted. In a small, local network operation this is easy to accomplish. However, when your organization must exchange data with external parties, there needs to be a way to recognize and trust a third-party CA as if it were a part of your local chain of trust. There are two ways to do this:

• You can use a certificate trust list, or CTL.

• You can create a cross-trust hierarchy, which enables an external CA to be viewed as a subordinate CA in your local trust chain.

Using a CTL or a cross-trust hierarchy under previous versions of Windows presented a central problem. When an external CA gained trust status, every certificate issued by it and all of its subordinate CAs were automatically trusted. New to Windows Server 2003 is a feature called qualified subordination. Qualified subordination enables you to specify how many subordinates can be trusted, and it also enables you to specify the purposes of certificates that can be accepted from the external CAs.

Key Recovery Agent

As when a person has locked his or her keys inside the car, lost encryption keys in a PKI can be troublesome. Luckily, Windows Server 2003 provides a locksmith of sorts (called a Registration Authority, or RA) that earlier versions of Windows did not have. A key recovery solution, however, is not easy to implement and requires several steps. The basic method follows:

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 12.15).

   
   Figure 12.15: Recovery Agents Tab of the CA Property Sheet

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.

Test Day Tip

Key archival and recovery rely on a version 2 template, which is only available in Windows Server 2003 Enterprise or datacenter Editions. If you’re using Windows Server 2003 Standard Edition, the Recovery Agents tab won’t even be visible because the Standard Edition only supports version 1 templates.

Planning CA Security

The two fundamentals of CA security are to guard the CA hierarchy from attackers and to configure the hierarchy for disaster recovery. The first of these requires a good deal of planning. For starters, you need to know the physical and logical location of the root CA. For extreme security, the CA can be physically located in a locked closet with a lights-out configuration (“lights out” refers to a server that has neither a monitor nor a keyboard attached). In most cases, however, lights out would be appropriate only after the entire PKI is set up. Remember that you will need to use the root CA every time a subordinate CA needs to request a certificate.

As we have already discussed, configuring the root CA as a standalone is probably the most important measure you can take to prevent accidental or intentional tampering. With no network connectivity, attacks become virtually impossible, since 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 and implementing file encryption.

In guarding the hierarchy, you cannot solely concentrate on the root CA. After all, if a subordinate CA is tampered with, every entity below it in the PKI hierarchy becomes compromised. Most 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. A periodic full backup (for example, weekly) with more frequent incremental backups (for example, daily) is recommended. For your organization, configuring the hierarchy for a disaster may also include installing additional CAs that are responsible for more narrow responsibilities. For example, you might want one CA to issue smart card certificates and nothing more. That way, if the CA is lost, it is not as difficult to replace. Finally, remember Windows Server 2003’s capability to archive and recover keys.

Test Day Tip

As mentioned above, the first concern of PKI security is keeping the root CA secure. Because Microsoft recommends that you configure the root CA as offline and standalone, the machine should not be a domain controller. Domain controllers need to be available for replication and cannot be offline a majority of the time.

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, when the client views the certificate, it then understands where to go for the latest CRL. Figure 12.16 shows the Extensions tab of the CA property sheet, where you can modify the location of the CDP.

Figure 12.16: Extensions Tab of the CA Property Sheet

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.

Note

Delta CRLs are new to Windows Server 2003. They enable a CA to publish only changes made to the original CRL. Since they are much smaller than the entire CRL, network traffic is minimized.

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.