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
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 security | Medium security | High security | External security |
|---|
| Secure e-mail | Secure e-mail | Secure e-mail | Software code signing |
| Encrypting File System | Encrypting File System | Encrypting File System | Internet authentication |
| | IPSec | IPSec | |
| | | 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.)
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 CA | Disadvantages of an internal CA | Advantages of an external CA | Disadvantages of an external CA |
|---|
| Direct control over certificates | Increased certificate management overhead | Instills customers with greater confidence in the organization | High cost per certificate |
| No per-certificate fees | Longer, more complex deployment | Provider liable for PKI failures | No autoenrollment possible |
| Can be integrated into Active Directory | Organization must accept liability for PKI failures | Expertise in the technical and legal ramifications of certificate use | Less flexibility in configuring and managing certificates |
| Allows configuring and expanding PKI for minimal cost | Limited trust by external customers | Reduced management overhead | Limited 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.
Note
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.
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.
Tip
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.
Tip
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.
Important
Make sure you have Internet Information Services (IIS) installed on the computer before you install Certificate Services. |
1. | Log on to Server02 as Administrator.
|
2. | Click Start, point to Control Panel, and then click Add Or Remove Programs. The Add Or Remove Programs dialog box appears.
|
3. | Click Add/Remove Windows Components. The Windows Components Wizard appears.
|
4. | Click
Certificate Services (without selecting the check box), and then click
Details. The Certificate Services dialog box appears.
|
5. | 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.
|
6. | Click OK in the Certificate Services dialog box.
|
7. | In the Windows Components Wizard, click Next. The CA Type page appears.
|
8. | Click the Stand-alone Root CA option, and then click Next. The CA Identifying Information page appears.
|
9. | In the Common Name For This CA text box, type Issuing and then click Next. The Certificate Database Settings page appears.
|
10. | Click Next to accept the default database settings.
|
11. | 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.
|
12. | 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.
|
13. | When the Completing The Windows Components Wizard page appears, click Finish. Close the Add Or Remove Programs dialog box.
|
