Planning and Designing a Public Key Infrastructure : Creating a Certificate Management Plan

Selecting a Certificate Enrollment Method

To enable enrollment, you need to specify the enrollment and renewal processes for your certificates. Enrollment involves either configuring permissions to establish which security principals have Enroll permissions for specific templates (in the case of enterprise CAs) or appointing a certificate administrator who reviews each certificate request and issues or denies the request based on the information provided.

AD CS supports the ability to process certificate requests manually, if administrative approval is required, or automatically, if no approval is necessary. The following enrollment and renewal methods are available:

• Certificate autoenrollment and renewal Allows you to automatically issue certificates that enable PKI applications, such as smart card logon, EFS, SSL, and S/MIME, to users and computers within an AD DS environment. Certificate autoenrollment is based on a combination of Group Policy settings and certificate templates, which allows you to enroll computers when they start up and to enroll users when they log on to their domain.

  To use autoenrollment, you need a Windows Server 2003 or Windows Server 2008 domain controller; a Windows Vista Business, Windows Vista Enterprise, Windows Vista Ultimate, or Windows XP Professional client; and a Windows Server 2003 Advanced Server enterprise CA or a Windows Server 2008 enterprise CA.

• Certificate Request Wizard and Certificate Renewal Wizard Available from the Certificates console, you can use the Certificate Request Wizard to request a certificate from an active enterprise CA on behalf of a user, computer, or service. You can then use the Certificate Renewal Wizard to renew the certificate.

• Web Enrollment Support pages Certificate Web enrollment has been available since its inclusion in the Windows 2000 Server operating system. It is designed to provide an enrollment mechanism for organizations that need to issue and renew certificates for users and computers that are not joined to the domain or that are not connected directly to the network and for users of non-Microsoft operating systems. Instead of relying on the autoenrollment mechanism of a CA or using the Certificate Request Wizard, the Web enrollment support provided by a Windows-based CA allows these users to request and obtain new and renewed certificates through a Web-based user interface over an Internet or intranet connection.

• Network Device Enrollment Service The Network Device Enrollment Service (NDES) is the Microsoft implementation of the SCEP. SCEP is a PKI communication protocol that enables software running on network devices such as routers and switches, which cannot otherwise be authenticated on the network, to enroll for X.509 certificates from a CA.

To select the certificate enrollment and renewal processes that are appropriate for your organization, you need to consider the following:

• The users, computers, devices, and services for which you intend to provide services Determine whether they are internal or external to the organization. Identify the operating systems they are running and determine whether they are connected to Active Directory Domain Services.

• The policies that you establish to manage certificate distribution This includes both the procedural policies that you establish for your PKI and the Group Policy settings that you use to implement those policies.

Selecting certificate enrollment and renewal processes involves making decisions about the following:

• Automatic versus manual requests

• Automatic versus manual approval

• An enrollment and renewal user interface

• CA certificate renewal

Selecting Automatic vs. Manual Requests

Whether you choose to generate certificate requests automatically or manually depends on the types of certificates that you intend to use and the number and type of clients that you enroll. For example, if you want all users or computers to use a certain type of certificate, it is not practical for you to require that each certificate be requested individually. Although rolling out a new certificate to all users or computers at one time can generate a large amount of network activity, you can control that activity by deploying the certificate requests for each organizational unit one at a time.

On the other hand, you might want to have users or an administrator request certain high-security certificates, such as those used for digital signing or administrative tasks, only when needed. This can improve administrative control over these certificates—particularly if certificate use is not limited by a user or computer OU or security group membership.

You can improve control over your certificates by using one of the following options to limit user certificate requests:

• Restricted enrollment agent In Windows Server 2008 Enterprise and Windows Server 2008 Datacenter, organizations can permit an enrollment agent to enroll only a certain group of users. The restricted enrollment agent features allow an enrollment agent to be used for one or many certificate templates. For each certificate template, you can choose which users or security groups the enrollment agent can enroll on behalf of. The restricted enrollment agent is not available on a Windows Server 2008 Standard–based CA.

• Restrict access to specific templates Configure the discretionary access control list (DACL) for each template so that only the required security principals have Enroll and Read permissions for particular templates.

• Automate the deployment of computer certificates Configure Group Policy to automatically assign the necessary computer certificates by adding the certificate template to the Automatic Certificate Request Settings option in Group Policy.

Selecting Automatic vs. Manual Approval

Users can request a certificate from a Windows Server 2008 CA either manually or automatically. This request is held until an administrator approves it, if manual approval is required, or until the verification process is completed. When the certificate request has been approved, the autoenrollment process installs the certificate automatically or automatically renews the certificate on behalf of the user, based on the specifications in the certificate template.

Most of the time, you choose the same method for certificate approval that you choose for certificate requests. However, there are exceptions. For example, if you have the appropriate Group Policy and DACL restrictions on your certificate templates, you might decide to approve automatically a certificate request that was generated manually. Conversely, in some cases it is appropriate to manually approve certificate requests that are automatically generated.

However, in general:

• For routine and high-volume certificates, such as e-mail certificates, automatic approval is the best option for certificate approval as long as the certificate requester has already been authenticated with a valid set of domain credentials.

• When a high degree of administrative oversight is required, such as for software code signing certificates, consider processing certificate requests manually. By using the Certificate Request Wizard, you can evaluate every certificate request individually—or you can delegate this responsibility to another administrator.

Selecting an Enrollment and Renewal User Interface

The user interface that you select for certificate request and approval processing depends on whether you choose automatic or manual certificate request and approval methods. If you decide to use autoenrollment for both certificate requests and certificate approval, you must use a minimal user interface.

However, if all or part of the enrollment process is manual, you must decide between using the Web Enrollment Support pages or the Certificate Request Wizard. The Web Enrollment Support pages are the easier interface for users to use. Users can perform the following tasks from the Web Enrollment Support pages:

• Request and obtain a basic user certificate

• Request and obtain other types of certificates by using advanced options

• Request a certificate by using a certificate request file

• Renew certificates by using a certificate renewal request file

• Save a certificate request to a file

• Save the issued certificate to a file

• Check on pending certificate requests

• Retrieve a CA certificate

• Retrieve the latest certificate revocation list from a CA

• Request smart card certificates on behalf of other users (for use by trusted administrators)

However, administrators might prefer to use the Certificate Request Wizard and the Certificate Renewal Wizard. You can start the wizard from the Certificates snap-in. Because the wizard is linked to the Certificates snap-in, you can also create custom snap-ins that you can distribute to CA administrators to whom you have delegated specific roles.

Unless an organization uses firewalls between one part of the organization and another, you can use the Certificates snap-in or the Web interface interchangeably. If a firewall exists between the CA and the requesting client, you must request certificates by means of the Web Enrollment Support pages or ensure that port 135 and a dynamic port above 1024 are open for Microsoft Management Console (MMC)-based DCOM communication.

Whether you choose to use the Web Enrollment Support Pages or the Certificate Request Wizard and Certificate Renewal Wizard, you might need to prepare documentation that describes how users can request a user certificate, what users can expect after they request the certificate (for example, automatic enrollment or a delay pending administrator approval), and how they can use the certificates after they receive them.

Using CA Certificate Renewal

When the certificate of a CA expires, the CA can no longer provide certificate services. To provide uninterrupted certificate services, use the Certificates console to renew the CA certificate before its expiration date. The interval that is required for CA renewal depends on the certificate lifetime of the CA.

After you renew a CA, the CA continues to issue certificates by using the new CA certificate, and the cycle starts over. Unexpired certificates that were issued by the prerenewal CA continue to be trusted until they expire or are revoked.

You can use the standard enrollment and renewal methods that are available in Windows Server 2008 to renew your CAs and certificates. You can renew certificates with the same private key and public key set or with new private and public keys. However, if you have special needs, you can develop custom certificate enrollment and renewal applications for CAs.

Creating a CA Renewal Strategy

Certificate lifetimes can have an impact on the security of your PKI for the following reasons:

• Over time, encryption keys become more vulnerable to attack. In general, the longer that a key pair is in use, the greater the risk that the key can be compromised. To mitigate this risk, you must establish the maximum allowable key lifetimes and renew certificates with new key pairs before these limits are exceeded.

• When a CA certificate expires, all subordinate certificates that are issued by this CA for validation also expire. This is known as time nesting. When a CA certificate is revoked, all certificates that have been issued by the CA must also be reissued.

• End entity certificates expire when the issuing CA certificate reaches the end of its lifetime unless the end entity certificate is renewed with a new key pair that chains to a CA certificate with a longer lifetime.

• You must plan the CA certificate renewal precisely during the PKI deployment phase. If this important planning step is missed, the entire PKI might stop working when the CA certificate expires because all of the certificates that depend on the CA’s certificate are then no longer usable for either encryption or signing operations. Remember, however, that a certificate is capable of decrypting data, even if it has expired or been revoked.

Defining a Revocation Policy

You should draw a revocation policy to define the circumstances under which certificates should be revoked. This revocation policy should describe the circumstances under which certificates are revoked, the individuals who perform revocation, the method by which certificates are revoked, and the manner in which revocation information is distributed to PKI clients.

The most common means of communicating certificate status is by distributing CRLs. In Windows Server 2008 PKIs where the use of conventional CRLs is not an optimal solution, an online responder based on OCSP can be used to manage and distribute revocation status information.

Certificate Revocation Lists

In some cases a CA must revoke a certificate before the certificate’s validity period expires. When a certificate is revoked, the CA includes the serial number of the certificate and the reason for the revocation in the CRL.

Windows Server 2008 supports the issuance of two types of CRLs: base CRLs and delta CRLs.

A base CRL contains a list of all the revoked certificates associated with a CA, along with the reason(s) for revocation. All time-valid revoked certificates are signed by a CA’s specific private key. If a CA’s certificate is renewed with a new key pair, a new base CRL is generated that includes only revoked certificates signed with the CA’s new private key.

A delta CRL contains only the serial numbers and revocation reasons for certificates revoked since the last base CRL was published. A delta CRL is implemented to provide more timely revocation information from a CA and to decrease the amount of data downloaded when retrieving a CRL. When a new base CRL is published, the revoked certificates in the delta CRL are added to the new base CRL. The next delta CRL will contain only certificates revoked since the new base CRL was published.

The delta CRL is much smaller than a base CRL because only the most recent revocations are included. The base CRL, which contains all revoked certificates, can be downloaded less frequently.

Problems with CRLs

CRLs have historically been the primary method for determining the revocation status of a specific certificate. Although CRLs are widely supported, there are some known issues with using only CRLs to determine a certificate’s revocation status.

• Latency The primary issue with CRLs is that there is latency in identifying that a certificate has been revoked. After you have revoked a certificate, relying parties do not recognize the revocation until the next publication of a CRL. The availability is defined by the CRL publication schedule. For example, if you publish an updated base CRL at 7:00 A.M. daily, a certificate revoked at 8:00 A.M. will not be recognized as a revoked certificate until the next day’s publication takes place.

• Caching of CRLs When a client computer checks the revocation status of a certificate, it first checks for the desired base CRL or delta CRL in the CryptoAPI cache. If it finds the base CRL or delta CRL, the client computer checks the CRL to determine if the CRL is time-valid. Like certificates, a CRL has a validity period defined by the CRL publication interval. If a time-valid CRL is found in the CryptoAPI cache, that version of the CRL is used for revocation checking, even if an updated version of the CRL has been published manually. The use of the cached version of the CRL is done for performance reasons to prevent excess network traffic. In addition, the use of a cached CRL follows the recommendations in RFC 3280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” to acquire an updated CRL only when the previous CRL expires.

Online Certificate Status Protocol (OCSP)

Windows Server 2008 introduces an alternative to CRLs that allows PKI clients to determine in real time whether a certificate has been revoked. Rather than a client downloading a base CRL or delta CRL, the client (OCSP client) sends an HTTP-based certificate status request to a server (referred to as an OCSP responder). The client determines the OCSP responder’s URL by inspecting the certificate’s Authority Information Access extension. If the extension contains an OCSP responder URL and the client supports OCSP, the client can proceed with sending an OCSP request to the OCSP responder.

Unlike CRLs, which are distributed periodically and contain information about all certificates that have been revoked or suspended, an online responder receives and responds only to requests from clients for information about the status of a single certificate. The responder communicates with the CA that issued the queried certificate to determine the revocation status and returns a digitally signed response indicating the certificate’s status. The OCSP responder can communicate directly with the CA or inspect the CRLs issued by the CA to determine the revocation status of the requested certificate.

The advantage of OCSP is that the OCSP responder typically provides more up-to-date revocation information to the OCSP client than a CRL does.

OCSP, however, has disadvantages, as well. One drawback of OCSP is that, for deployments servicing many clients, the OCSP responder can be overwhelmed with requests. For this reason, it is important to deploy your OCSP responder in a Network Load Balancing cluster or other load balancing solution. A second drawback of OCSP is that it is more difficult to implement than CRLs are. A final limitation of OCSP is that it is supported only in Windows Vista and Windows Server 2008.

When planning for certificate validity checking and revocation, OCSP is preferable to CRLs when the timeliness of revocation information is a high priority and minimizing processing workload is a low priority. For large deployments used to support many PKI clients across the Internet, CRLs are a more practical solution.

Determining Publication Points

The final technical requirement that must be met in your design is determining publication points, either for both CRLs and CA certificates (if you implement CRL checking) or for an OCSP responder (if you implement OCSP).

A PKI client can use the URLs stored in the CRL Distribution Point (CDP) (if CRL checking is being used) and Authority Information Access (AIA) extensions (if OCSP is being used) to determine a certificate’s revocation status.

At each CA in the hierarchy, you must define publication points for certificates issued by that CA. These publication points allow access to that CA’s certificate and CRL. You can use the following protocols when defining publication points:

• Hypertext Transfer Protocol (HTTP) URLs HTTP URLs are used for both internal and external publication points. The advantage of HTTP URLs is that there is little lag time between publication and availability. After you publish an updated CRL or CA certificate to an HTTP URL, it is immediately available for download by PKI-enabled applications. In addition, HTTP URLs can typically be downloaded by clients behind firewalls and those who are not full Active Directory clients, including those running an operating system earlier than Microsoft Windows 2000 and non-Microsoft clients.

• Lightweight Directory Access Protocol (LDAP) URL A CA certificate or CRL that is published to an LDAP URL is, by default, published into the configuration naming context of Active Directory. This means that the CRL or CA certificate is available at all domain controllers in the forest.

There are two disadvantages to using the default LDAP URL location:

• It can take some time for CRLs or CA certificates to fully replicate to all domain controllers in the forest. The actual time depends on your network’s replication latency, especially when the replication must take place between sites and not just between domain controllers in the same site.

• Nonsupport of the Active Directory–related LDAP URLs can lead to delays in CRL or CA certificate retrieval. If the default LDAP URL is the first URL in the URL listing, a non–Active Directory enabled client will time out for 10 seconds before it moves on to the next available URL.

The decision on which protocols to implement for CRL or CA certificate publication points depends on the frequency at which you publish CRLs, the protocols allowed to traverse network firewalls, and your network’s operating systems. To ensure maximum availability, the URLs should be ordered so that the most common protocol used for CRL or CA certificate retrieval is listed first in the CDP extension. Other protocols are then listed in their order of use.

After you choose the publication protocols, you must choose where to publish the CA certificates and CRLs. The location decision includes the physical servers where you publish the files and the location of the servers on the corporate network: intranet or extranet.

Use the following guidelines when choosing publication points:

• If most computers are running Windows 2000 or later and are members of the forest, you should include an LDAP URL that references the Active Directory configuration naming context. This location is published to all domain controllers in the forest and ensures availability and fault tolerance.

• If you have several nonforest computers or third-party operating systems, such as UNIX, you should include Web server publication points for HTTP URLs.

• If certificates are to be evaluated from the external network, the CA certificate and CDP must be published to an externally accessible location, such as a Web server or LDAP server in a perimeter subnet of the network.

• File publication points typically are not used for CA certificate and CRL retrieval. File publication points are more common for publishing CA certificates and CRL information to remote servers.

• The URL order is determined by the types of network clients. The order should be set so that the majority of clients can retrieve the CA certificate or CRL from the first URL in the listing. If a client cannot retrieve the CA certificate or CRL from the first URL, the client times out in an attempt to connect and then proceeds through the next URLs in the listing.

• Delta CRLs are published more frequently than base CRLs. You might not want to publish delta CRLs to LDAP locations because of Active Directory replication latency. Instead, publish delta CRLs to HTTP locations. The Active Directory replication interval must allow the delta CRL to be replicated before the prior delta CRL expires if you plan to publish the delta CRL to Active Directory.

  Note: Publishing to AD LDS

  Delta CRLs can be published to a standalone LDAP server, such as AD LDS, because replication is not an issue with this form of LDAP server.

  
  

• OCSP URLs must be hosted on highly available resources. If the OCSP responder is unavailable when an OCSP client submits a query, revocation checking will fail.