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_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\ValidityPeriod and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\ValidityPeriodUnits 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:
- On ROOTCA, copy the contents of the C:\winnt\system32\CertSrv\CertEnroll folder to a 3.5" disk and use the disk to move these files to \\ISSUING\CertEnroll.
- Using the MMC Internet Service Manager (ISM) snap-in, create a virtual directory named CDP in ISSUING's default Web site that references the CertEnroll folder (use the direct path C:\winnt\system32\CertServ\CertEnroll). After you create the CDP virtual directory, make note of the URL (e.g., http://ISSUING.hp.com/CDP); you'll need it in later steps.
- While logged on to the ISSUING server as a Domain Administrator, open a command prompt and change to the CertEnroll folder. You should see ROOTCA's .crl and .crt files that you copied from the 3.5" disk. The filenames in my example are HP Root CA.crl and HP Root CA.crt.
- Use the Microsoft Windows 2000 Server Resource Kit's Dsstore utility to place the root certificate and CRL into AD. The general format of the command is Dsstore <DC=domain,DC=domain> <function> <file to upload> <CA Name> <server>. For example, assuming the AD domain is called hp.com, you would use the following commands (DC= must be uppercase):
- On ROOTCA, start the MMC Certificate Authority snap-in, which was installed when you installed Certificate Services. Right-click the root CA and select Properties. Go to the Policy Module tab, click Configure, then click the X.509 Extensions tab.
- You'll see two sections: CDP and AIA. Remove the entries in both sections.
- Next, you need to add HTTP entries to the CDP and AIA sections. Click Add and enter the URL that references the CertConfig virtual directory, followed by the appropriate substitution string, which you can find in Table 3. Certificate Services will use these substitutions to populate the CDP and AIA fields in the issued certificates. For example, for the HTTP-accessible CDP, you would enter (no spaces): HTTP://ISSUING.HP.COM/CDP/%CA_NAME%%CERT_SUFFIX%.crl and for the AIA, you would enter HTTP://ISSUING.HP.COM/CDP/%SERVER_DNS_NAME%_%CA_NAME%%CERT_SUFFIX%.crt
- Next, add entries that define the LDAP-accessible CDP and AIA locations. Click Add and enter the LDAP queries that resulted from running the Dsstore commands. Use the first LDAP query (ending in cRLDistributionPoint) for the CDP and the second (ending in certificationAuthority) for the AIA.
- Stop and restart Certificate Services to activate these changes. After you make these changes, you can use the root CA to generate certificates for the intermediate CAs.
Dsstore DC=hp,DC=com addcrl "HP Root CA.crl" "HP Root CA" ROOTCA Dsstore DC=hp,DC=com addroot "HP Root CA.crt" "HP Root CA"
The first command imports the CRL; the second imports the root CA certificate. Each command returns an LDAP query string that you save and use to define the CDP and AIA for the root. For example, the Dsstore commands returned the following query strings:
LDAP:///CN=HP Root CA, CN=ROOTCA,CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=HP,DC=COM?certificateRevocationList?base? objectclass=cRLDistribution Point LDAP:///CN=HP Root CA,CN=AIA, CN=Public Key Services,CN= Services,CN=Configuration, DC=HP,DC=COM?cACertificate? base?objectclass=certificationAuthority
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 (\\ISSUING\CertEnroll or \\ROOTCA\CertConfig). 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:
- Take the 3.5" disk to the parent-level CA. Use the Certreq (Certificate Request) utility, which is in the \system32 directory, to post the certificate request to the CA. Open a command prompt and enter one of the following commands, depending on which downlevel certificate request you're processing. For SUBCA, enter
- Open the Certificate Authority snap-in on the parent-level CA. You'll see four containers: Revoked Certificates, Issued Certificates, Pending Requests, and Failed Requests. Select the Pending Requests container, and you'll see the request that CERTREQ posted. If more than one request is pending, you can identify your request by the ID number. Right-click the request and select Issue from the Tasks menu, then exit MMC.
- Open a command prompt and enter one of the following CERTREQ commands. For SUBCA, enter
- Open the Certificate Authority snap-in, click Tools, and select Install CA certificate. Browse to the chain.p7b file on the 3.5" disk and click Open. Because the SUBCA machine is offline, an attempt to check a CRL will fail, producing an error message asking whether you want to continue. Click OK. In the Certificate Authority hierarchy, you should now see a red check mark where a red dot was displayed before.
CERTREQ -config "ROOTCAHP Root CA" a:\SubCA.req
For ISSUING, enter
CERTREQ -config "SUBCA\HP Subordinate CA" a:\IssueCA.req
The -config option tells the utility which CA to use. The name to the left of the back slash is the server name and to the right is the CA Name. After running the commands, you'll receive a Request ID number. Keep track of this number.
CERTREQ -retrieve -config "ROOTCA\HP Root CA" 2 a:\SubCA.crt a:\chain.p7b
For ISSUING, enter
CERTREQ -retrieve -config "SUBCA\HP Subordinate CA" 4 a:\SubCA.crt a:\chain.p7b
The -retrieve option tells the utility that you need to download and save the issued certificate and certificate-chain information to files. In the above example, the certificate request ID numbers you noted from Step 1 are 2 and 4. After the request number, you specify two files: the file that will hold the certificate and the file that will store the certificate-chain information. Be sure to use a .crt extension for the certificate file and a .p7b extension for the chain file. Use the 3.5" disk to transport these files to the CA and complete the installation.
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.
