Windows Server 2003 : Creating and Managing Digital Certificates - Designing a Public Key Infrastructure

Defining Certificate Requirements

As in most phases of designing a network, the first step of the planning phase is to determine the requirements of the users. In the case of a PKI design, you must determine what your client’s security needs are, how certificates can help provide that security, which users, computers, services, and applications will use certificates, and what kinds of certificates your clients need. In many cases, you will have already answered some or all of these questions as you developed an overall security strategy.

A PKI using computers running Windows Server 2003 can create certificates that support any or all of the following applications:

• Digital signatures Used to confirm that the person sending a message, file, or other data is actually who he or she purports to be. Digital signatures do not protect the data itself from compromise; they only verify the identity of the sender.

• Encrypting File System user and recovery certificates The Windows Server 2003 Encrypting File System (EFS) enables users to store data on disk in encrypted form, to prevent other users from accessing it. To prevent loss of data resulting from users leaving the organization or losing their encryption keys, EFS allows designated recovery agents to create public keys that can decode the encrypted information. As with IPSec, EFS does not have to use the PKI for its encryption keys, but the use of a PKI simplifies managing EFS.

• Internet authentication You can use the PKI to authenticate clients and servers as they establish connections over the Internet, so that servers can identify the clients connecting to them and clients can confirm that they are connecting to the correct servers.

• IP Security The IP Security extensions (IPSec) enable you to encrypt and digitally sign communications, to prevent them from being compromised as they are transmitted over a network. The Windows Server 2003 IPSec implementation does not have to use a PKI to obtain its encryption keys, but you can use the PKI for this purpose.

• Secure e-mail Internet e-mail protocols transmit mail messages in plain text, making it relatively easy to intercept them and read their contents. With the PKI, you can secure e-mail communications by encrypting the actual message text using the recipient’s public key, and you can digitally sign the messages using your private key.

• Smart card logon A smart card is a credit card-size device that contains memory and possibly an integrated circuit. Windows Server 2003 can use a smart card as an authentication device that verifies the identity of a user during logon. The smart card contains the user’s certificate and private key, enabling the user to log on to any workstation in the enterprise with full security.

• Software code signing Microsoft’s Authenticode technology uses certificates to confirm that the software users download and install actually comes from the publisher and has not been modified.

• Wireless network authentication The increasing popularity of wireless local area networking (LAN) technologies, such as those based on the 802.11 standard, raises an important security issue. When you install a wireless LAN, you must make sure that only authorized users can connect to the network and that no one can eavesdrop on the wireless communications. You can use the Windows Server 2003 PKI to protect a wireless network by identifying and authenticating users before they are granted access to the network.

Once you have decided what applications you want to secure with certificates, you can create a plan indicating the level of security for each user. For example, you might decide that you want everyone on your network to use secured e-mail, while only the Research and Development and Accounting departments need IPSec for all their network communications. Users’ locations can also be significant. You might want to use software code signing and Internet authentication for clients who connect to your network over the Internet, but omit these requirements for internal users.

When defining the certificate security requirements for your network, the best practice is to create a small set of security definitions and apply them to your users and computers as needed. For example, Table 1 shows a certificate plan for an organization that includes four levels of security: basic, medium, high, and external. The basic security level, applied to most of the users in the organization, uses certificates to provide encrypted e-mail and EFS services. Medium-level security, which is used for general users in more sensitive departments, adds IPSec to secure their LAN communications. Top-level executives and people working with highly sensitive information use high security and must use a smart card to log on to the network. Because the organization runs a Web site where registered customers can download software products, a special classification for external users calls for certificates that provide software code signing and Internet authentication.

Creating a CA Infrastructure

Once you have decided what you are going to use certificates for and who is going to need them, you can plan the infrastructure of certificate authorities that will provide the certificates you need. Certificate authorities function using a hierarchy in which each CA is validated by a CA at a higher level until you reach the root CA, the ultimate authority for the organization. CAs issue certificates not only to applications and users, but also to other CAs. If you trust a particular root CA, you should also trust any lower-level CAs that are authenticated and validated by that root CA. Trusts between CAs flow downward through the hierarchy, just as file system permissions do (see Figure 1).

When creating a CA infrastructure for your organization, you must decide how many CAs you need, who is going to provide them, where to locate them, and what the trust relationships between them should be.

Using Internal or External CAs

You can use either internal CAs running on your own computers or external CAs provided by a commercial service for all your certificate needs. Some applications (such as software code signing) clearly call for one or the other, but in many cases, the choice depends on the needs and capabilities of your organization. The advantages and disadvantages of using internal and external CAs are summarized in Table 2.

In many cases, organizations use a combination of internal and external CAs. They use their own CAs to secure their internal communications and use external CAs when they must secure communications with outside parties, such as customers.

How Many CAs?

If you decide to use internal CAs for your network, the next step is to determine how many CAs you need and where to locate them. A single CA running on Windows Server 2003 can support as many as 35 million certificates, issuing two million or more a day. As a result, most organizations use multiple CAs due to logistical factors other than the number of certificates required.

A variety of factors affect the performance of a CA, and can influence your decision as to how many CAs you need. Some of these factors are as follows:

• Number and speed of processors The CPU performance of a server is the single most influential factor in that server’s performance as a CA. A server with multiple processors or faster processors will perform better as a CA, particularly when issuing certificates with long encryption keys.

• Key length The length of the encryption keys in your certificates is a major factor in the impact of CA service on the computer’s CPU. Longer keys require more processing time and can slow down the certificate enrollment process.

• Disk performance A high-performance disk subsystem in a CA can influence the certificate enrollment rate; however, the degree of influence depends on other factors, such as the CPU performance and key length. If the CA issues certificates with unusually long keys, processing time for each certificate increases, slowing down the enrollment rate and lessening the impact on the disk subsystem. With shorter keys, disk performance is more critical, because the disk subsystem can more easily become the bottleneck slowing down the enrollment rate.

Based on these criteria, many organizations would be adequately served by a single CA, but there are several reasons implementing multiple CAs anyway. One reason is fault tolerance. Having two or more CAs enables the PKI to service clients even if one of the servers fails. Another reason is load distribution when servicing an organization spread out over multiple locations. A corporation with several offices might want a CA in each office to reduce wide area network (WAN) traffic and to keep the certificate enrollment process local. It might also be necessary to deploy multiple CAs so that different servers can issue certificates for different purposes.

Creating a CA Hierarchy

When you deploy multiple CAs in a single organization, the relationships between them are hierarchical, based on a network of parent/child relationships. Every CA in a PKI is either a root CA or a subordinate CA. A root CA is the parent that issues certificates to the subordinate CAs beneath it. If a client trusts the root CA, it must also trust all the subordinate CAs that have been issued certificates by the root CA.

Subordinate CAs can also issue certificates to other subordinate CAs. In this case, the CA in the middle is called an intermediate CA. An intermediate CA is subordinate to the root CA but higher than the other subordinate CAs to which it issues certificates.

Every certificate issued by every CA in the hierarchy can trace its trust relationships back to a root CA. The CA that issues your certificate might possess a certificate issued by another CA, which in turn might possess a certificate issued by a root CA. This hierarchy of relationships is called a certificate chain. In Windows Server 2003, you can display the certificate chain for any certificate by clicking the Certification Path tab in the Certificate dialog box, as shown in Figure 2.

In a large PKI implementation, a three-layer CA hierarchy like the one in Figure 11-1 is typical. The root CA exists only to issue certificates to the intermediate CAs, thereby functioning as the ultimate authority for the PKI. Beneath the CA are one or more intermediate CAs, which issue certificates to the subordinate CAs at the next level. Generally speaking, you create multiple intermediate CAs to separate different classes of certificates, for example, one intermediate CA for internal user certificates and one for external certificates. At the bottom layer of the hierarchy are the subordinate CAs, also known as issuing CAs because these servers actually enroll client users and applications. Intermediate and root CAs usually do not issue certificates directly to clients, only to subordinate CAs.

Understanding Windows Server 2003 CA Types

When you configure a server running Windows Server 2003 to function as a CA, you can configure it to be either a root CA or a subordinate CA. In addition, you select one of the following two types for the CA:

• Enterprise Enterprise CAs are integrated into the Active Directory directory service. They use certificate templates, publish their certificates and CRLs to Active Directory, and use the information in the Active Directory database to approve or deny certificate enrollment requests automatically. Because the clients of an enterprise CA must have access to Active Directory to receive certificates, enterprise CAs are not suitable for issuing certificates to clients outside the enterprise.

• Stand-alone Stand-alone CAs do not use certificate templates or Active Directory; they store their information locally. In addition, by default, stand-alone CAs do not automatically respond to certificate enrollment requests, as enterprise CAs do. Requests wait in a queue for an administrator to manually approve or deny them. Stand-alone CAs are intended for situations in which users outside the enterprise submit requests for certificates.

Whether you choose to create an enterprise CA or a stand-alone CA, you can also specify that the CA be a root or a subordinate. An enterprise root CA is the top of the hierarchy. There can only be one enterprise root in any CA hierarchy. All the other CAs in the hierarchy must be enterprise subordinate CAs.

Stand-alone CAs can function in the same type of hierarchy as enterprise CAs; you can create a stand-alone root CA with stand-alone subordinate CAs beneath it. If you want to create only one stand-alone CA for your PKI, it must be a root CA, because every CA hierarchy must be traceable back to a root.

With your security requirements and your CA hierarchy design in place, you can decide on a configuration for the certificates that the CA will issue to your clients. Some of the criteria to consider when planning certificate configurations are as follows:

• Certificate type Specifies the function of the certificate. Windows Server 2003 includes a collection of certificate templates that enable you to easily configure a CA to issue specific types of certificates.

• Encryption key length and algorithm The length of the encryption keys included in your certificates and the encryption algorithm the certificates use dictate how difficult certificates are to penetrate and how secure the information they protect is. Longer keys provide greater security, but also require more processor time when creating and processing certificates. Different algorithms provide various degrees of security, also at the expense of processor time.

• Certificate lifetime The lifetime of a certificate specifies how long the client can use it before it must be renewed. Longer lifetimes increase the chances that a certificate can be compromised. For certificates with longer encryption keys and stronger algorithms, however, longer lifetimes are often justified. Shorter lifetimes increase the number of certificates your CAs must issue, affecting network traffic and the server processing load. The default certificate lifetime for enterprise and stand-alone root CAs is two years.

• Renewal policies You can configure a CA to issue new public and private keys when renewing a certificate or to re-use the existing keys. Issuing new keys increases the security the certificate provides, but also increases the processing load on the CA.