9.3 What Is a Certification Authority?

     

Public key certificates are the answer to many authentication issues, as you've just seen. The next question is: where does the server get its certificate? From a CA. This is the crux of what I'll be discussing in this section. The web server certificate can come from either a public or private CA, but either way, a CA must provide that certificate by signing the requested certificate with its private key.

Certification authorities primarily provide three functions:

Issue public key certificates

The heart of any CA is the ability to receive a request from a client for a public key certificate and issue a certificate in response. This process can take many different forms and be governed by both technology-based and administration-based rules. The certificate requests are often governed by certificate templates, which define what information is required for a request and what type of certificate can be issued based on each request.

Publish certificate revocation lists

When certificates are compromised, there must be a way to notify clients that the certificate is invalid. The CA creates a list of invalid (or revoked ) certificates and then distributes (publishes) the list. This list is called a certificate revocation list (CRL). It is similar to the old lists of lost or stolen credit cards that were distributed to merchants . A merchant who accepted a credit card would hopefully check the list to ensure the card number was not listed. Similarly, whenever an application makes use of a public key certificate, it would hopefully check the CRL before considering it valid.

Archive private keys

A relatively recent advancement in public key technology is the ability of the CA to request a copy of the client's private key during the certificate request and issuance process. This key is normally kept in an encrypted fashion on the CA in case the user ever needs her key restored. This feature is available in Windows Server 2003 Enterprise Edition and will be discussed later in this chapter.

9.3.1 How a Certification Authority Works

A certification authority can be thought of as a simple database with an enormous set of complex rules. I'll examine the different conditions that a certification authority will encounter and the rules that apply to each condition. This section applies to Windows Server 2003 Enterprise Edition acting as a certification authority, although most of these terms and concepts apply to any manufacturer's certification authority, including Windows Server 2003 Standard Edition.

9.3.1.1 Server configuration

Each certification authority must be installed and configured by an administrator, as there is no automatic or default installation. It is absolutely critical to design and plan the deployment of a certification hierarchy well before any certification authorities are deployed. Certification authority planning is discussed later in this chapter.

9.3.1.2 Subject requesting a certificate

When a subject requests a certificate, some information is always required by the CA. Although some essential information is required for any certificate issued (such as the public key), other information may vary. For example, some certificates might require user principle names from Active Directory, while others may require the IP address of the computer requesting the certificate.

The client must ensure that the right information is provided in the request, in the right format for the CA to interpret. This information will vary based on the issuing CA and the type of certificate requested. For example, a client certificate used for authentication is different from a subordinate CA certificate, because they have very different intended uses and often require different security levels (for example, different cryptographic key lengths). These usage differences often require that their certificate requests contain different data. For example, a request for a passport probably requires different proof of identification than a request for a check cashing card at a grocery store.

Because there are several different ways to request a certificate from a Windows Server 2003 CA, there must be a way for the client to learn the specific type and format of request that the CA can understand as well as the information that must accompany the request. This is accomplished by configuring certificate templates on the server.

Certificate templates are containers for the certificate configuration and allow both the server and client to mutually understand the required format for successfully obtaining a certificate. Typically, certificate templates are designed as part of the certificate authority infrastructure and created during the initial configuration. But because these templates are independent of one another and highly configurable, they can be modified, supplemented, or removed whenever a business or security need must be met. But a template is always required so the client and server both know what information is required for enrollment.

9.3.1.3 Processing the request

A subject requests a certificate from a certification authority by obtaining the certificate template (either directly from the CA or from Active Directory, depending on the type of CA), preparing the proper information in the correct format, and presenting that information to the certification authority. The certification authority is then responsible for either issuing or denying the request. This decision is based on a fairly basic rule: the template either stipulates that requests for a certificate be issued automatically or put into a "pending" state.

Contrary to popular belief, a certification authority does not generate the public-private key pair used in a certificate. The subject generates the key pair when creating the certificate request (in Windows Server 2003, this is done by the built-in Cryptographic API (CAPI). The public key portion is then included with the certificate request that is sent to the certification authority. The private key never leaves the subject's computer unless exported or for server-based key archival.

9.3.1.4 Publishing a certificate

The specific processes to be followed before issuing a pending certificate vary greatly. In some cases, an email confirmation that the request is authentic may be all that is required. In other cases, such as with high-value certificates, physical confirmation of the subject or extensive background investigations may be necessary. From the perspective of the administrator, the more valuable the certificate, the more rigorous and comprehensive the verification of the subject must be. From the certification authority's perspective, all pending certificate requests are the same. A certificate manager for that certification authority must manually issue the certificate to complete the request.

Once a certificate is issued by the certification authority (with approval from the certificate manager), the certificate request is signed with the private key of the certification authority. This creates the certificate. The certification authority then stores a copy of the certificate for itself and distributes a copy to the requester, by any method desired. This distribution does not need to be protected, as the certificate does not contain any secret information and its security does not rely on restricted distribution.

In many configurations, the certificate is also sent to a directory service to provide the certificate to any requester who wants to securely communicate with the subject. This provides centralized distribution of certificates and provides an additional layer of assurance that the certificate is unadulterated. However, the client could just provide the certificate to any requester through any desired means. Although this distribution mechanism is less trustworthy and more inconvenient, the digital signature on the certificate is considered sufficient to prove its own authenticity.

Most certification authorities have the ability to perform one or more additional tasks when a certificate is issued or denied . The Microsoft Windows Server 2003 CA, for example, has the built-in ability to send email or publish the certificate to Active Directory. The Windows Server 2003 CA is built in a modular fashion that allows an administrator to install code that can do anything when a certificate is issued, providing for great customizability of the CA. For more information on customizing the Windows Server 2003 CA, see the MSDN article "Writing Custom Exit Modules" at http://msdn.microsoft.com/library/en-us/security/Security/writing_custom_exit_modules.asp.

9.3.1.5 Server publishing a certificate revocation list

Over time, certificates may become invalid. RFC 3280 defines another common data structure used with certificates, the certificate revocation list (CRL). A CRL is a much simpler structure than the certificate. It is simply a list of serial numbers of certificates that are no longer valid, such as certificates that have had the private key compromised or been replaced . This list is signed and published by the certification authority that issued the invalid certificates. The CRL can be distributed to any URI reachable by the certification authority and the certificate users. The CRL distribution point (CDP) must be established in advance to ensure that all clients that will use certificates from the certification authority can reach the CDP and download the CRL. The CDP is simply the location that stores the CRL. The CDP is often implemented as a location on a web server, but it can be any other URI you want, such as an FTP location, a UNC location, and so forth.