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

9/11/2012 1:59:58 AM
As with most elements of a network, implementing a public key infrastructure requires careful planning before you begin deployment. Planning a PKI typically consists of the following basic steps:
  • Defining certificate requirements

  • Creating a certification authority infrastructure

  • Configuring certificates

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 develop 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 Digital signatures are 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 The Microsoft 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 you might prefer to 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 users in the organization, uses certificates to provide encrypted e-mail and EFS services. Medium-level security, which is used for general users in departments with more sensitive information, 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.

Table 1. Sample Certificate Plan
Basic securityMedium securityHigh securityExternal security
Secure e-mailSecure e-mailSecure e-mailSoftware code signing
Encrypting File SystemEncrypting File SystemEncrypting File SystemInternet authentication
  Smart card logon 

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 certification authorities that will provide the certificates you need. Certification 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.)

Figure 1. Certification authority trusts flow downward

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.

Table 2. Advantages and Disadvantages of Internal and External CAs
Advantages of an internal CADisadvantages of an internal CAAdvantages of an external CADisadvantages of an external CA
Direct control over certificatesIncreased certificate management overheadInstills customers with greater confidence in the organizationHigh cost per certificate
No per-certificate feesLonger, more complex deploymentProvider liable for PKI failuresNo autoenrollment possible
Can be integrated into Active DirectoryOrganization must accept liability for PKI failuresExpertise in the technical and legal ramifications of certificate useLess flexibility in configuring and managing certificates
Allows configuring and expanding PKI for minimal costLimited trust by external customersReduced management overheadLimited integration with the organization’s infrastructure

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 determining 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 for 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.


Root CAs are the only CAs that do not have a certificate issued by a higher authority. A root CA issues its own self-signed certificate, which functions as the top of the certificate chain for all the certificates issued by all the CAs subordinate to the root.

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.

Figure 2. The Certification Path tab in the Certificate dialog box

In a large PKI implementation, a three-layer CA hierarchy like the one in Figure 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.


The security of the higher-level CAs in a PKI hierarchy is critical because, if an intruder penetrates the security of one high-level CA, all its subordinates are compromised as well. For this reason, it is common practice to leave root and intermediate CAs offline after they issue certificates to their subordinates. You can take a CA offline by shutting down Certificate Services, by disconnecting the Windows Server 2003 CA server from the network, or by shutting the server down completely.

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 be only one enterprise root in any CA hierarchy. All 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.


If you plan to use smart cards to authenticate users on your network, you must create enterprise CAs because smart card certificates must be associated with Active Directory user accounts to be functional.

Exam Tip

Be sure to understand the differences between enterprise root CAs, enterprise subordinate CAs, stand-alone root CAs, and stand-alone subordinate CAs.

Configuring Certificates

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. 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 they 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 reuse the existing keys. Issuing new keys increases the security the certificate provides, but it also increases the processing load on the CA.

Practice: Installing a Windows Server 2003 Certification Authority

In this practice, you install Certificate Services on a computer running Windows Server 2003 and configure it to function as a stand-alone root CA.


Make sure you have Internet Information Services (IIS) installed on the computer before you install Certificate Services.

Log on to Server02 as Administrator.

Click Start, point to Control Panel, and then click Add Or Remove Programs. The Add Or Remove Programs dialog box appears.

Click Add/Remove Windows Components. The Windows Components Wizard appears.

Click Certificate Services (without selecting the check box), and then click Details. The Certificate Services dialog box appears.

Select the Certificate Services CA and the Certificate Services Web Enrollment Support check boxes.

A Microsoft Certificate Services message box appears, warning you that once you install Certificate Services, you cannot change the computer’s machine name or domain membership without affecting the function of the CA. Click Yes to continue.

Click OK in the Certificate Services dialog box.

In the Windows Components Wizard, click Next. The CA Type page appears.

Click the Stand-alone Root CA option, and then click Next. The CA Identifying Information page appears.

In the Common Name For This CA text box, type Issuing and then click Next. The Certificate Database Settings page appears.

Click Next to accept the default database settings.

A Microsoft Certificate Services message box appears, stating that the system must temporarily stop the IIS service to complete the installation. Click Yes to proceed. The Configuring Components page appears, displaying a progress indicator as the wizard installs Certificate Services.

Depending on your configuration, another Microsoft Certificate Services message box might appear, stating that the system must activate Active Server Pages (ASP) in IIS. Click Yes to proceed. The Configuring Components page finishes showing the progress of the installation.

When the Completing The Windows Components Wizard page appears, click Finish. Close the Add Or Remove Programs dialog box.
  •  Windows Server 2003 : Creating and Managing Digital Certificates - Introducing Certificates
  •  Laptop For All Budgets (Part 2) - Notebooks, Ultrabooks
  •  Laptop For All Budgets (Part 1)
  •  Windows Tips & Tricks (August 2012) – Part 2 - Manage Your Google Docs Offline with gExplore
  •  Windows Tips & Tricks (August 2012) – Part 1 - Wake Your PC with a Smartphone or Tablet
  •  Windows 8's Unexpected Features (Part 3)
  •  Windows 8's Unexpected Features (Part 2)
  •  Windows 8's Unexpected Features (Part 1)
  •  Windows Server 2008 R2 and Windows 7 : Deploying DirectAccess (part 3) - Installing and configuring DirectAccess and network location server
  •  Windows Server 2008 R2 and Windows 7 : Deploying DirectAccess (part 2) - Creating a certificate revocation list (CRL) distribution point on the DirectAccess server
  •  Windows Server 2008 R2 and Windows 7 : Deploying DirectAccess (part 1) - Creating a certificate template for computer autoenrollment
  •  Windows Server 2008 R2 and Windows 7 : Planning to Deploy Directaccess
  •  Iwork Pro : Export Strength
  •  Is It Time To Ditch Windows Search? (Part 4) - Power tools,Search for files over Wi-Fi, Search your PC from your mobile phone
  •  Is It Time To Ditch Windows Search? (Part 3) - Search across the LAN
  •  Is It Time To Ditch Windows Search? (Part 2) - Search within files
  •  Is It Time To Ditch Windows Search? (Part 1) - Simple filename searches
  •  In Search Of The Perfect Mid-Tower (Part 4) - Thermaltake Level 10 GTS
  •  In Search Of The Perfect Mid-Tower (Part 3) - Corsair Obsidian 550D, NZXT Phantom 410 Gunmetal Edition
  •  In Search Of The Perfect Mid-Tower (Part 2) - Corsair Vengeance C70, MSI Ravager
    Top 10
    Letter Of The Month – November 2012 (Part 2)
    Letter Of The Month – November 2012 (Part 1)
    Mac App Store Sandboxing Nightmare
    iStopMotion 3
    That’s Online Entertainment (Part 3)
    That’s Online Entertainment (Part 2)
    That’s Online Entertainment (Part 1)
    How to Buy…A TV TUNER (Part 2)
    How to Buy…A TV TUNER (Part 1)
    Philips E-Line 273E3LH LED Monitor - Big-Screen-Entertainment
    Most View
    Introducing Windows Presentation Foundation and XAML : Building a WPF Application using Only XAML
    BenQ XL2420T : Best 3D monitor
    IIS 7.0 : Configuration File Syntax
    Deploying an ASP.NET Application in Windows Azure
    Sharepoint 2007: Use the My Links to Manage Your Links
    SharePoint 2010: Architecture Fundamentals - Understanding SharePoint Administration
    Fine-Tuning Windows 7’s Appearance and Performance : Balancing Appearance and Performance
    Audioquest Dragonfly – USB DAC/Headphone AMP
    iPhone 3D Programming : Blending and Augmented Reality - Rendering Anti-Aliased Lines with Textures
    Windows Azure : Processing with worker roles - A simple worker role service
    Silverlight : Print a Document
    CMS Revolution (Part 1)
    Windows Azure : Blobs - Usage Considerations
    Panasonic LUMIX LX7: A High-end PnS With f/1.4-2.3 Lens And 11fps Continuous Shooting
    Windows 7 : Managing Your User Account
    The New Domain Names (Part 1)
    Windows Server 2003 : Implementing a GPO (part 2) - Modifying a GPO
    This Will Be The End Of Me
    Sharepoint 2010 : Business Connectivity Services Deployment Types (part 3) - Configure Indexing & Performing a Search
    The Best In-Car Accessories