9.8 Maintaining Your Hierarchy

     

Now that the PKI is operational, maintenance functions must be put in place. Good security starts with a solid and well- analyzed plan and continues with a secure deployment that meets that plan. However, no deployment is secure forever. As the PKI continues to function, the environment will change. These changes may not change the security provided, but you must perform tasks to ensure that appropriate security is maintained . These are the ongoing tasks that ensure that each CA is functioning properly and providing the services it is designed to provide.

9.8.1 Certificate Issuance

The CA's primary job is to issue certificates. In many cases, the CA will issue certificates automatically without any administrative intervention, which is accomplished by configuring the CA and certificate templates with proper security permissions. On many CAs and with many high-value certificate types, however, manual administrative verification may be important. In those cases, the certificate request will be set to Pending when it is received by the CA. Only manual issuance by one or more parties can issue those certificates. For details on configuring certificate templates to require multiple signatures, see the Certificate Templates topic in Windows Server 2003 Enterprise Edition Online Help.

Let's assume you have configured your CA to place all requests in a Pending state. To issue a certificate that's been placed in a Pending state, perform the following simple procedure:

1. In the Certification Authority console, double-click the name of the CA to expand the CA containers.

2. Double-click Pending Requests.

3. Find the certificate request you want to issue in the righthand pane. Right-click that request, click All Tasks, then click Issue. Conversely, if the request is illegitimate or undesired , you can click Deny to remove it from the Pending Requests queue.

Once issued, the client will need to retrieve the certificate. This can be accomplished in many ways, such as autoenrollment , web enrollment, or SCEP enrollment. Most clients will automatically retrieve the request or be instructed on how to later retrieve the certificate during their request submission.

9.8.2 Configuring CA Auditing

As I stress throughout this book, you must audit critical systems to ensure they are not being misused. The CA is no exception to this advice. Auditing CA activity is a new feature in the Windows Server 2003 family CA. It is available on all versions of the Windows Server 2003 family operating system to help ensure the best security possible.

Configuring auditing for the CA is a simple procedure, which can be done during CA postinstallation configuration or at any time after. To configure auditing on a CA, follow these steps:

1. Configure Group Policy for the CA to enable Audit object access. For information about configuring Group Policy, see Chapter 5.

2. In the Certification Authority console, right-click the name of the CA and click Properties.

3. Click the Auditing tab.

4. Check each type of event you want to audit. The descriptions are fairly detailed and should clearly define what is being audited . Only one of these options is likely to generate large numbers of entries: Issue and Manage Certificate Requests.

Whenever an event of the type selected occurs, the CA will create an event in the Event Log. This can be manually retrieved and reviewed at any time. Many great tools are available to combine event logs from disparate computers and automate some of the log reviewing tasks. While I won't specifically recommend any of these tools, they are a good idea to consider when deploying your PKI. Reviewing detailed events from numerous issuing CAs can become time-consuming without automation tools. However, the consequences for not doing these reviews can be devastating.

9.8.3 Renewing CA Certificates

As I discussed earlier, a CA's certificate has a finite lifetime. It is limited by the configuration of its own certificate and the certificate of all its parents up to the root CA. Because of this and other reasons, issuing CAs normally have a shorter lifetime for their certificate than the root CA. This means that the CA's certificate must be periodically renewed.

The first and probably most difficult part of renewing any CA is knowing when its certificate is going to expire. You've documented this well during your earlier process, but years may go by before renewal needs to occur. Personnel turnover , lax process conformity , and so on may cause the security staff to simply forget to do this. Luckily the CA will begin to remind you with Event Log entries when the certificate is about to expire. However, you should manage your own process to ensure nothing is overlooked. Many PKI administrators use calendar or planning software such as Microsoft Outlook. They place an event in the future and set a reminder for days or weeks in advance of the event. In this way, they ensure that they'll be reminded of this task by at least two independent processes.

Renewing a CA's certificate is a simple process. It's similar to initial certificate enrollment in that the root CA can sign its own certificate, but subordinate CAs must submit their requests to the parent for issuance. To start the process of renewal:

1. In the Certification Authority console, right-click the name of the CA, click All Tasks, then click Renew CA certificate.

2. If prompted, click Yes to stop Certificate Services.

3. Choose New or Existing Key Renewal. The decision on whether to use the current key or obtain a new one is based on whether the key has expired (as I've discussed) or whether the key has been compromised. The wizard provides this information, as is shown in Figure 9-15.

Figure 9-15. Renewing a CA certificate requires a simple decision based on the reason for renewal

The remainder of the tasks will be familiar to you from the CA installation process. If the parent CA is offline, you'll need to manually submit the request and retrieve the issued certificate. If the CA certificate template is set to manual issue, you'll need to issue it as described in the previous section.

9.8.4 Revoking Issued Certificates

I've discussed the CRL and CDP extensively in this chapter and earlier in the book. I've not yet detailed how a certificate gets on the "bad list." This is a fairly anticlimactic event, given the knowledge you now have of the CA process and operation. When you know that a certificate has been compromised or should no longer be honored, you should immediately revoke it. To revoke any issued certificate:

1. In the Certification Authority console for the CA that issued the certificate, double-click the name of the CA to expand the CA containers.

2. Double-click Issued Certificates.

3. Find the certificate you want to revoke in the righthand pane. Right-click that request, then click Revoke Certificate.

4. Provide a Reason code from the drop-down list. Providing a reason code is optional and will default to Unspecified. A certificate that is revoked for a reason of Certificate Hold can be unrevoked later. All other reason codes provide permanent revocation.

Remember that certificates do not appear on the CRL until the CRL is issued or a new delta CRL is published. For high-value certificates or CA certificates that are compromised, you may want to immediately publish a new CRL or delta CRL. To do that, follow the instructions provided earlier in this chapter.

9.8.5 Publishing CRL for Offline Root CA

All CRLs have a specific validity period, configured during CA installation, to ensure that clients do not continue to rely on outdated information. The root CA's CRL usually issues a CRL with a longer validity period than its subordinates , since it issues far fewer certificates and is therefore less likely to revoke any. Even if the CRL is blank, it must be published for clients to locate it when building chains. The procedure to periodically publish the offline root CA's CRL is no different than the procedure we used while setting up the root CA. While a simple process, it must be done periodically to ensure clients do not experience broken trust chains.

9.8.6 Backing Up Your CA

The common principle on backing up data is simple. You back up any data you cannot afford to lose. I've been preaching that for years. So the CA's database is information you cannot afford to lose and you must back it up regularly. Right? Maybe.

The CA's database contains some critical information. The most important thing it contains is the CA's certificate. However, you've already backed that up separately, either manually or using an HSM.

The database also contains configuration information about the CA, such as permissions, issuance templates, and so forth. You've already got that information in your deployment plans and it is easily recreated. Your CA's database also contains the list of certificates you've issued, denied , or set to pending. Do you actually need that data?

There is only one type of unique information in the CA database that cannot be re-created or obtained from another CA: archived private keys issued by this CA. Although the client has its copy of the private key, the client cannot resubmit it to the CA. If the CA's database is lost and a client wants its private key recovered, it's simply not possible.

You can decide for yourself whether to back up each CA's database. If kept in a secure location and access is properly restricted and audited, it doesn't present a security risk. However, there may be little benefit to backing it up. This depends on whether you're archiving private keys on that CA.