Building a 3-Tier CA Hierarchy

Digital certificates are a valuable validation tool that you can use to authenticate users during logon, secure Web communications, and determine a piece of software's origin. One of digital certificates' major uses is to encrypt or digitally sign email messages so that recipients are assured of the sender's and message's authenticity. When you understand certificate technology, you can decide what type of Certificate Authority (CA) hierarchy best suits your needs and whether to use an external or internal CA. In case you decide to host your own CA, I discuss inherent challenges and the steps for setting up a certificate server that you can use to issue your own digital certificates. Let me start with a short explanation of how the various parts of a Public Key Infrastructure (PKI) work together.

PKI Structure
A CA is an entity that issues digital certificates. A CA organization validates the identity of individuals and organizations, then issues digital certificates to represent them. A CA server, or certificate server, is the machine that issues certificates. (In this article, I generally use the generic term CA to refer to CA servers.) A Certificate Revocation List (CRL) is a list of certificates that should no longer be trusted—usually because the private keys have been lost, damaged, or compromised. CA organizations host CRL Distribution Point (CDP) servers, which store CRLs. You can access your CA's CDP server through a file share, Lightweight Directory Access Protocol (LDAP), FTP, or HTTP.

Each system that uses certificate technology needs a certificate store, which is a database that holds digital certificates. When a certificate-aware application needs to use or validate a certificate, it first accesses the certificate store. On Windows systems, the easiest way to see the contents of the certificate store is to open Microsoft Internet Explorer (IE); select Tools, Internet Options from the menu bar; and click the Content tab. On Windows 2000 or later systems, you can use the Microsoft Management Console (MMC) Certificates snap-in to access the certificate store.

CA servers are usually organized in a two- or three-tier hierarchy and come in three types: root, intermediate, and issuing. For details about why a three-tiered hierarchy is usually your best choice, see the Web-exclusive sidebar "3 Tiers for Your CA Hierarchy" (http://www.secadministrator.com, InstantDoc ID 39244). A CA hierarchy typically has a root CA at the top level under which you have one or more intermediate CAs. (Intermediate CAs are also referred to as policy or subordinate CAs.) Beneath each intermediate CA is one or more issuing CAs. Assuming you explicitly trust the entity serving as the root CA, the root CA validates the intermediate level. The intermediate level validates the issuing level. And, the issuing level validates the individuals to whom the CA issues certificates. Each level provides a certificate to the level below it and defines policies or rules that govern things such as certificate use and lifetimes. This hierarchy of certificate relationships forms a certificate chain.

To better understand the concept of a certificate chain and how it relates to the process of issuing a certificate, let's look at the process of issuing a driver's license, which Figure 1 shows. At the top level, you have the country (root CA) that binds together all the states and provides the validation that lets a driver's license (digital certificate) issued in one state be used in other states. The next level consists of the states (intermediate CAs), which specify the organizations that can issue the licenses and define a period of time for which those organizations can operate. Those organizations (issuing CAs) then define the rules for obtaining a license (e.g., where to get the license, what proof of identity you need to provide, how often you must renew the license). We trust the license because we trust the issuing organization, we trust the organization because we trust the state, and we trust the state because we trust the country. The same principles apply to certificates.

To kick-start the CA chain-of-trust process, you need to explicitly trust the root CA. A root CA is self-certifying, which means that it has no higher authority, so it generates its own "self-signed" certificate. For a system to trust the root CA, you place the root CA's certificate, which contains the public key, in the Trusted Root container of the system's certificate store. You'll need to perform this step for every workstation or server that will use certificates that chain back to this root CA. Each certificate that the root CA issues (e.g., an intermediate CA's certificate) will contain a signature that the root CA's private key generates, just as a driver's license has the state seal and the governor's signature to make it official. Systems use the root certificate's public key to validate the signature, thus confirming that the intermediate certificate is valid. In a like manner, each certificate that the intermediate CA issues (e.g., an issuing CA's certificate) contains a signature that lets you validate the issuing CA. And to complete the chain, each sender's certificate contains the issuing CA's signature, which lets you validate the sender's certificate and thus validate the sender (assuming that none of these certificates break the chain by being listed on a CRL).

Implementation Considerations
From a technology perspective, you must first decide what type of CA hierarchy you need, which in turn determines how many servers you'll need (you need a minimum of two). Table 1 offers some general guidelines, but ultimately, your policies, business requirements, and application-security needs will drive the hierarchy's complexity.

You must consider whether to use an internal or external root CA. By using a well-known external root CA, such as VeriSign or Thawte, you reduce the likelihood that you'll need to define an explicit root CA trust by adding its certificate to your store. You'll also be less likely to need to exchange root certificates with external parties—a definite plus if you send digitally signed email outside your organization's email system—because other organizations probably already have the CA's root certificate in their systems' certificate stores. As Table 1 shows, using an external root CA removes the burden of supporting a server but costs you some flexibility for setting certificate policies, especially in regard to certificate lifetimes. You also need to consider the cost of purchasing a CA-level certificate, but that cost is generally less than the expense associated with purchasing and operating a root CA server. No matter what type of PKI you set up, make sure the highest-level CA you control operates offline (i.e., not connected to any network or domain) to reduce the likelihood of an intruder compromising the server or its private key. If you decide to host your own root CA, I suggest that you operate the highest-level intermediate CAs offline, for the same reason.

Another consideration is certificate longevity—for both user-level and CA-level certificates. Generally, organizations issue user-level certificates for a period of 1 or 2 years. Longer life spans increase the chance of key compromise; shorter life spans provide more security but increase administrative and user burdens associated with certificate renewal. CA-level certificates must have a longer life than the certificates they issue because when a CA certificate expires, all certificates that the CA issued become invalid. In most implementations, a CA certificate has a valid life span two to five times longer than the life span of certificates it issues. As the remaining lifetime of the CA certificate approaches the life span of the certificates it issues, the CA certificate is renewed (or a new certificate is issued) and the new CA certificate processes new certificate requests or renewals. As a rule of thumb, root CA certificates have a 20-year life span, intermediate CA certificates have a 10-year life span, and issuing CA certificates have a 5-year life span, but again, your organization's policies and business needs will govern your certificate life spans.

Next, you need to consider the key strength of your certificates—the more bits a key has, the greater the key strength and the less likely that the key can be guessed or determined mathematically. The downside to larger keys is that they take longer to compute when a CA is generating or renewing certificates or when used to perform asymmetric decryption. The rules of thumb for key strengths are 4096 bits for root and intermediate CAs, 2048 bits for issuing CAs, and 1024 if not 2048 bits for user certificates.

The last factor that you need to consider relates to CDPs. CDPs are the source for obtaining both root certificates and CRLs. You need to determine where on your network to host the CDP and which protocols will provide access to it. In many installations, the issuing CA also hosts a Web server that provides HTTP access to a CDP. HTTP is also the typical protocol that external parties use to access your CDP because most firewalls permit the HTTP protocol to pass outbound but often block other protocols. However, you aren't limited to using HTTP. You can use FTP or a file share, or if you have an Active Directory (AD) infrastructure, it can host your CDP and provide access through LDAP.

Setting Up Your CA Hierarchy
The rest of this article steps you through the process of using Win2K Certificate Services to set up a three-tier CA hierarchy. Web Figure 1 (http://www.secadministrator.com, InstantDoc ID 39237) provides an overview of the steps and flow involved in this process. First, you'll need to set up three servers—ROOTCA, SUBCA, and ISSUING—and install Win2K, Microsoft Internet Information Services (IIS) 5.0, and the most recent service packs on all three machines. The ISSUING machine will reside on the network, will host the CDP for all three CA servers, and will service end-user certificate requests, so you need to install it on a server-class system scaled to meet your expected connection demands. The ROOTCA and SUBCA machines won't be on the network, so you don't need to scale them to do much more than process one certificate request at a time and periodically generate a CRL. Having said that, however, you don't want to use the old junker desktops that you used 3 years ago. The CA chain is an important part of your hierarchy, so use solid, stable hardware and take adequate steps to back up each server and store the CA certificates in a safe place. Also, because the ISSUING server performs functions for all three CA servers, you'll need to set up the OS and IIS on this server before you install Certificate Services on any of the other CA machines.

Installing the CA Servers
You install the ROOTCA server first, followed by the SUBCA server, then the ISSUING server. The overall process is similar for each of the three CAs; Table 2 lists the unique settings that I used to create the three-tiered hierarchy in our example. To begin any of the CA installations, open the server's Control Panel Add/Remove Programs applet, then click Add/Remove Windows Components. Select Certificate Services and click Next. You'll see a warning stating that you can't rename the server or change its domain membership; click Yes. The first option you set is the Certification Authority Type. Select the CA type based on the values in Table 2. After you set the CA type, select the Advanced options check box, as Figure 2 shows, then click Next. (The Enterprise CA options aren't available unless the server is an AD domain member.)

The Windows Components Wizard then lets you define the public and private key pair options as well as the Cryptographic Service Providers (CSP) and algorithms used to encrypt and generate signatures. The different CSPs and algorithms provide various capabilities and functionality, such as exportable encryption strengths or support for security devices such as smart cards. Unless you have a specific need to change the CSP or the hash algorithm, use the default settings (Microsoft Base Cryptographic Provider 1.0 and SHA-1). You can use the wizard to set key length according to the values in Table 2, then click Next.

On the CA Identifying Information page, which Figure 3 shows, you specify information to include in certificates, as well as information that the people operating the CA use to validate your identity when approving or rejecting certificate requests. The most important value on this page is the CA name. The name must be unique; the security subsystem uses it to locate the appropriate parent-level certificate in the certificate chain. The other fields describe your organization, and the information you enter can be the same for any CA that you configure. The last field lets you specify the number of years for which your root certificate is valid. Because the root CA self-certifies, you can set this value only in ROOTCA's GUI. The lifetimes of subordinate and issuing CA certificates depend on the parent-level CA's lifetime and are controlled through a registry setting on the ROOTCA and SUBCA servers, respectively. I explain these settings later.

Continue clicking Next to move through the wizard pages. The installation will generate a cryptographic key and prompt you to specify a disk location for the database files that Certificate Services uses. The wizard also lets you separate the primary database and the database transaction logs—which I recommend—by specifying separate partitions for them. In addition to the database locations, you'll also need to specify a shared directory that will provide an Authority Information Access (AIA) point for retrieving the CA certificate. The default location for this shared directory is below C:CAConfig, but you can use any location you choose. For ease of maintenance, keep the same location and share names for all three servers.

Special Setup for the Root CA
After the wizard finishes, you need to make several changes on the root CA so that it meets the needs of the other CAs and the people who use the certificates. You first need to change a registry key that governs the lifetime of certificates that the root CA issues to subordinate CAs. The default setting is 1 year, which is too short to be useful. To extend this lifetime, use a registry editor to access and modify the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfigurationValidityPeriod and HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvcConfigurationValidityPeriodUnits subkeys, according to the data in Table 2. The Microsoft article "HOW TO: Change the Expiration Date of Certificates That Are Issued by a Windows 2000 Certificate Authority" (http://www.support.microsoft.com/?kbid=254632) describes these subkeys. You can use this method only on standalone CAs. The ValidityPeriod value holds one of the following: days, weeks, months, or years; the ValidityPeriodUnits value holds a number such as 10 or 20. So for the root CA in this example, the ValidityPeriod value remains set to years, and the ValidityPeriodUnits value is set to 10; these settings let you generate intermediate certificates that are valid for 10 years.

Next, you need to modify the definitions that set the locations of CRLs and root certificates (CDPs and AIAs). Before you begin this process, you need to decide how you'll make CDPs and AIAs available. It's usually wise to provide access through HTTP and a secondary protocol such as LDAP or FTP. If for some reason you can't provide access through a secondary protocol, at least provide redundant access points, such as two separately hosted Web servers. In this example, I use IIS (to provide HTTP access) on the ISSUING server and AD (to provide LDAP access). The ISSUING server will be the only server connected to the network, so you'll use it to host the HTTP-accessible CDP and AIA for all three CAs. (This is why you need to install the ISSUING server's OS before you begin any of the CA installations.) Storing the root CA certificate in AD has another bonus: Because you identified the certificate as a root CA certificate, AD automatically adds it to the certificate store of any Win2K or later machines when they boot. You don't need to do any extra work to install the certificate on your client machines unless they're earlier than Win2K. If you choose not to add the certificate to AD (not an option if you install an enterprise CA) or you want to deploy the certificate only to selected machines, you can use Group Policy to deploy the certificate. (After you install Certificate Services, you'll find instructions for this task in the CA's Help.)

To redefine the CDP and AIA, perform the following steps:

Special Setup for the Intermediate and Issuing CAs
The initial installation steps for the intermediate CA (SUBCA) and issuing CA (ISSUING) are nearly identical to the steps for installing the root CA. The first difference is that you select CA types of Stand-alone subordinate and Enterprise subordinate, respectively. Because the subordinate CA won't be connected to the network, you'll need to manually add the root certificate to the system's certificate store. Using a 3.5" disk, copy the root certificate from the AIA (\ISSUINGCertEnroll or \ROOTCACertConfig). Open the Certificates snap-in. Select the option to manage certificates for the local computer account. Expand the container tree so that you can access the Certificates container found below Trusted Root Certification Authorities. Right-click the Certificates container and select Import from the All-Tasks menu. Browse to the certificate on the 3.5" disk and click Open, which opens the Certificate Import Wizard. When prompted, import the certificate to the Trusted Root Certification Authorities store.

For the subordinate and issuing CAs, you'll need to generate a certificate request that the parent-level CA will process. After copying installation files to the server, the wizard displays the CA Certificate Request page, which Figure 4 shows.

Because the root and subordinate CAs are offline, you won't be able to send the request directly to the CA, so select Save the request to a file and enter a filename on a 3.5" disk. The wizard will store your request as a specially encoded text file. To complete the SUBCA and ISSUING setup, perform the following steps:

Installation of the issuing CA is now complete. If you're installing the intermediate CA, you need to make a few more changes—the same types of changes that you made on the root CA. You'll need to edit the registry to set the certificate lifetime, copy the CRL and certificate to the CertEnroll share, and update the CDP and AIA locations so that certificates will refer to the online Web server and AD to access these resources. The steps are identical to those described in the Special Setup for the Root CA section. Simply substitute the Intermediate CA information (see Table 2) for the Root CA information. Your CA hierarchy is now complete, and you can begin processing certificate requests.

I hope I've helped you understand how to deploy a basic CA hierarchy that you can use to support digitally signed email. Running a CA hierarchy is no trivial undertaking. You need to know how to install the CA services used to generate the digital certificates, as well as set policies and procedures that govern how and when your organization uses the technology. Use the information in this article to help you understand the relationships between the CAs, the certificates, and tools such as CRLs and CDPs, and you'll be well on your way to deploying your own CA.