Udostępnij za pośrednictwem

Deployment Planning (Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure)

  • Artykuł

Applies To: Windows Server 2003 with SP1

Before you can deploy a PKI, you should go through a well-defined planning phase. If you do not do this, the PKI can become valueless after only a short time in operation. To avoid this issue, make sure that the deployment planning covers the following areas.

Table 6 PKI Planning Considerations

Planning area Possible considerations

Business requirements

Defining application requirement

Defining solutions goals

Choosing appropriate technology

CA requirements

Insource the CA infrastructure

Outsource the CA infrastructure

Interoperability with application requirements

PKI trust model

Enrollment policy

Certificate practice statements

Users and computers

Use of certificate templates

Service level requirements

Revocation policy

CRLs, delta CRLs, Online Certificate Status Protocol (OCSP)

Replication latency

Designing the CA Infrastructure

For more information about how to decide what services are provided by the CA types, see the articles on the following Microsoft Web sites:

Considerations

There are some important parameters that help when a organization starts its PKI planning. From a technical viewpoint, there are a number of key factors that can give you rough estimates:

The number of CAs that you need can be estimated by:

  • The size and the geographical spread of the deployment

  • The required trust relationship between certificate holders and the CA

  • Requirements for different certificate practice statements (CPS)

  • Technical requirements based on application demands

  • Partner relationships and trust model requirements

  • Security requirements, availability, and service levels indicate the depth of the hierarchy and the CA locations.

Defining CA Types and Roles

To plan your CA infrastructure, you need to understand the different types of CAs that are available and the roles that the CAs can take.

The following section supplies the most important planning information.

Choosing Enterprise or Stand-alone CAs

Certificate Services offers two types of CAs that have different feature sets: enterprise CAs and stand-alone CAs. A Windows Server 2003 PKI may consist of both types of CAs, which is often recommended for the enterprise environment. A comparison of strengths of the stand-alone CA and the enterprise CA may help you decide what CA type is required for which role.

A stand-alone CA should be used if:

  • It is an offline root or offline intermediate CA.

  • Support of templates that you can customize is not required.

  • A strong security and approval model is required.

  • Fewer certificates are enrolled and the manual work that you must do to issue certificates is acceptable.

  • Clients are heterogeneous and cannot benefit from Active Directory.

  • It is combined with a third party Registration Authority solution in a multi-forest or heterogeneous environment

  • It issues certificates to routers through the SCEP protocol

An enterprise CA should be used if:

  • A large number of certificates should be enrolled and approved automatically.

  • Availability and redundancy is mandatory.

  • Clients need the benefits of Active Directory integration.

  • Features such as autoenrollment or modifiable V2 templates are required.

  • Key archival and recovery is required to escrow encryption keys

The following table is an overview about the preferred roles for both CA types. Depending on the CA topology, these roles can be taken by a smaller or larger number of CAs.

Table 7 CA Types and CA Roles

CA type 3 tier 2 tier 1 tier

Offline root CA

Stand-alone CA

Stand-alone CA

Offline intermediate CA

Stand-alone CA

 

 

Issuing CA

Enterprise CA

Enterprise CA

 Enterprise CA

Table 8 Comparison of Stand-alone and Enterprise CAs

Windows Server 2003 Stand-alone CA Windows Server 2003 Enterprise CA

CA configuration can be published into Active Directory.

CA configuration is always published into Active Directory.

CRL and CA certificate must be manually published into Active Directory.

CRL, Delta CRL, CA certificate, and cross certificates are automatically published to the forest where the CA configuration was registered.

Certificates are automatically published into a directory service if this is specified on a per template level. Certificate publishing may be defined as an attribute on the template in Active Directory.

By default, certificate enrollment is available only by using Web enrollment support.

By default, certificate enrollment is possible by using Web enrollment or the Certificates MMC.

Certificate request processing is done by using Hypertext Transfer Protocol (HTTP) or Secure Hypertext Transfer Protocol (HTTPS).

Certificate request processing is done primarily by using RPC/Distributed Component Object Model (DCOM) or HTTP and HTTPS protocol.

Certificate is based on V1 templates with custom object identifier (also known as OID).

Also issues certificates that can be modified and duplicated, based on V2 templates.

User must manually type identification information when the certificate is requested.

User identification information is always automatically retrieved from Active Directory, regardless of whether it is requested through Web enrollment or the Certificates MMC.

Enrollment method (automatic or pending) is valid for all templates. You cannot apply a configuration to individual templates.

You can individually set the enrollment method on each template.

Certificates are manually approved.

Certificates are manually approved or they are approved through Active Directory authentication and access control.

Certificates are not published to a directory location, but to the client or the CA. without a custom-developed policy module.

Depending on the type of certificate, certificate is automatically enrolled into the requester's certificate store and published to Active Directory, based on template definition.

Does not support certificate publishing and object management based on Active Directory.

Supports certificate publishing and object management based on Active Directory.

Can be installed on a domain controller, member server, or stand-alone server (workgroup member).

Can be installed on a domain controller or member server. (The CA is registered as a forest resource.) It must not be installed on a stand-alone server (workgroup member).

Authentication and Authorization

Stand-alone CAs use local authentication for certificate requests, mainly through the Web enrollment interface. Stand-alone CAs provide an ideal service provider or commercial PKI provider platform for issuing certificates to users outside of an Active Directory environment where the user identity is separately verified and examined before the request is submitted to the CA.

A CA running Windows Server 2003, Enterprise Edition, uses DCOM and Kerberos impersonation for authenticating requesters. It compares the client token against an access control list (ACL) set on the certificate template, as well as the DCOM enrollment interface on the CA itself, when a certificate is requested. A Windows 2000 Server CA uses remote procedure call (RPC) instead of DCOM to authenticate a requester. After the user is authenticated and authorized to gain access to the requested template, the CA can immediately process the request, as long as the user has the appropriate enrollment permissions on the template and if the CAs configuration is set to autoenroll.

Certificate Request Approval

When a certificate request reaches a CA that is running a member of the Windows Server 2003 family, both CA types (enterprise and stand-alone) can immediately issue the certificate or put it into a pending state. It is the responsibility of the CA administrator to configure the enrollment method globally for a CA or on a per-template basis. On a Windows 2000 Server CA, the enrollment method setting is valid only on a CA level: all certificates that are issued take this configuration into account. For a Windows Server 2003, Enterprise Edition enterprise CA, the enrollment method can be set individually for a V2 template.

On a Windows 2000 Server enterprise CA, there is no choice for the enrollment method because it immediately approves and issues certificates. On a Windows 2000 Server stand-alone CA, the enrollment method is applied on the CA level and cannot be set on the template level This occurs because a Windows 2000 CA works only with V1 certificates, which cannot maintain enrollment permissions.

Default configurations of stand-alone CAs rely on administrative action both to verify the requester's identity (known as authentication) and to issue the certificate (known as authorization). Here, the Web enrollment support acts as the registration authority (RA) and the CA acts as the enrollment station. Because of this, it is not recommended that you have a standalone CA automatically issue certificates without administrative approval, because a requester's identity cannot be verified. For additional information about certificate enrollment, see "Allowing for autoenrollment" in Help and Support Center.

Offline and Online CAs

Traditionally, the decision of whether to use either an online or offline CAs involves a compromise between availability and usability versus security. The more sensitive that the key material is and the higher the security requirements are, the less accessible the CA should be to users.

Important

For security reasons, a CA should always run on a separate computer. Do not install an online CA on a domain controller, even if it is technically possible.

To maintain a CA offline, different approaches may be applied through physical or technical protection techniques as described below:

Physical Protection

  • Remove the hard disk drive and lock it in a secure location.

  • Shut down and power off the system.

  • Disconnect the network cable, but keep the system running.

  • Protect the system from the network by using either a firewall or a router.

Technical Protection

  • Keep the system online, but stop the CA service.

  • Use a hardware security module (HSM) with an HSM-operator hardware token to limit access to the CA private key. For more information, see "Hardware CSPs," later in this document.

Maintaining a CA either online or offline is a standard functional definition of the CAs operation mode. You can turn an offline stand-alone CA into an online stand-alone CA if you connect it to the network. Any stand-alone CA that runs on a server in a workgroup and is connected to the network can become an offline CA by using one of the approaches that was mentioned earlier.

The stand-alone root CA is usually placed offline because it is the single point of trust for an entire organization or for several organizations. The lifetime of trust depends on the CAs certificate lifetime, but should be planned for the long term. If a CA must be trusted for long periods of time, you should take that CA offline to provide additional security measures. Also, intermediate CAs are typically configured as offline CAs. An intermediate CA is subordinate to a root CA, but also serves as a parent CA to one or more CAs. Those CAs may be issuing CAs or intermediate CAs. In a CA with at least three tiers, an intermediate CA is a mid-tier CA.

Every online CA implies availability and network connectivity. Online CAs are typically issuing CAs, because issuing CAs respond to requests from users, computers, services, and network devices, such as routers. Every enterprise CA must be an online CA, because it requires connectivity to Active Directory at all times to obtain configuration information, validate requests, and publish certificates. An online CA provides more surface area for security attacks.

Note

As a best practice, an offline CA server should be placed in a secure vault until a subordinate CA certificate needs to be issued or a new CRL needs to be published.

Hardware CSPs

You might consider using one or more HSMs in your PKI topology. An HSM is a dedicated hardware device that is managed separately from the operating system. These modules work with any Windows Server 2003 CA to provide a secure hardware store for CA keys. From an operating system view through the CryptoAPI interfaces, the HSM is seen as a cryptographic service provider (CSP) device.

The HSM provides highly secure operational management that is protected by multilayered hardware and software tokens, as well as a number of other key features, including:

  • Hardware-based, cryptographic operations, such as random number generation, key generation, and digital signatures, as well as key archival and recovery.

  • Hardware protection of valuable private keys that are used to secure asymmetric cryptographic operations.

  • Secure management of private keys.

  • Acceleration of cryptographic operations, which relieves the host server of having to perform processor-intensive, cryptographic calculations.

  • Load balancing and failover in hardware modules by using multiple HSMs that are linked together through a daisy chain.

Although HSMs increase security by raising the level of key protection, HSMs increase the complexity and cost of the PKI.

Several vendors offer HSMs that work well on computers that are running either Windows 2000 Server or members of the Windows Server 2003 family. For more information about how to install HSMs that are proven to work with Windows-based CAs, see the section "Installing an HSM on an offline root CA" later in this document.

Selecting a Trust Model

Trust is a logical relationship established between domains to allow pass-through authentication, in which a trusting domain honors the logon authentications of a trusted domain. User accounts and global groups that are defined in a trusted domain can be given rights and permissions in a trusting domain, even though the user accounts or groups don't exist in the trusting domain's directory. Because a CA is a certificate holder of a CA certificate and an end entity might be a certificate holder of a user certificate, the trust relationship between the issuing CA and the holder is always the same. In a rooted x.509 PKI hierarchy, the trust relationship is inherited from top to bottom.

You can also control trust relationships through certificate trust lists and through qualified subordination. The selection of an appropriate trust model can determine success for a PKI. An organization must think about the number of tiers that the CA topology requires. The hierarchy can be extended from top to bottom and the number of CAs that are used for one level can grow. Note that deeper structures add complexity to the trust management of the PKI.

For more information, see the article "Trusted Root Certificates That Are Required By Windows 2000" on the Microsoft Knowledge Base.

Specifying CA Roles

An ideal PKI hierarchy design divides the responsibility of the CAs. A topology that is designed with requirements that have been carefully considered provides the most flexible and scalable enterprise configuration. In general, CAs are organized in hierarchies. Single tier hierarchies might not provide adequate security compartmentalization, extensibility and flexibility. Hierarchies with more than three tiers might not provide additional value regarding security, extensibility and flexibility.

The most important consideration is protecting the highest instance of trust as much as possible. Single-tier hierarchies are based on the need to compartmentalize risk and reduce the attack surface that is available to users who have malicious intent. A larger hierarchy is much more difficult to administer, with little security benefit.

Depending on the organization's necessities, a PKI should consist of two or three logical levels that link several CAs in a hierarchy. Administrators who understand the design requirements for a three-level topology may also be able to build a two-level topology.

A three-tier CA hierarchy consists of the following components:

  • A root CA that is configured as a stand-alone CA without a network connection

  • One or more intermediate CAs that are configured as stand-alone CAs without a network connection

  • One or more issuing CAs that are configured as enterprise CAs that are connected to the network

Art Image

Figure 1: Three-tier CA Hierarchy

To set up a two-tier topology, apply all of the steps that are described in Example scenario for Contoso Company, later in this document.

If the organization can fulfill its security requirements with a two-tier hierarchy, a three-tier architecture is not required. When you do not have a middle tier, CA management applies to two levels instead of three levels and might lower maintenance cost.

To implement a two-tier topology, use the steps that are outlined in both the "Stand-alone offline root CA" and "Online Enterprise Issuing CAs (CorporateEnt1CA)" sections of this paper.

From a technical perspective, a single level PKI hierarchy can also provide basic PKI services. Leaving out the root and the intermediate tier results in an all-in-one CA. Because the single CA must issue certificates, it cannot be taken offline. Security and flexibility is very limited with this type of implementation. To implement a single-tier topology, apply the steps that are outlined in "Online Enterprise Issuing CAs (CorporateEnt1CA)."

The decision of whether or not to use a separate root CA to issue all certificates in an organization should be a need for security versus a need for cost mitigation and simple administration.

To summarize, a two-tier to four-tier CA topology is the most common deployment. Any organization should be able to deploy a similar PKI architecture to meet any organizational, business, and technical requirement, as well as a respectable level of security.

For reliability and redundancy, improve the availability of the PKI and deploy multiple enterprise CAs instead of extending the depth of the hierarchy.

Root CA

A root CA is a self-signed CA. Technically, the root CA runs the same code as an intermediate or issuing CA. The difference between these types of CAs is in the role that the CA takes. The following table displays a list of the characteristics that a root CA should have, depending on the CA topology.

Table 9 Root CA Characteristics

Characteristic More than 2 tiers 2 tiers 1 tier

High level of physical security

Yes

Yes

No

Permanently offline

Yes

Yes

No

Highly restricted area (vault)

Yes

Yes

Yes

Match the level of risk

Yes

Yes

Yes

High level of cryptographic security

Yes

Yes

Yes

Largest key size

Yes

Yes

Yes

Software CSP

(FIPS 140-1 level 1)

No

No

Yes

Smart cards or PCMCIA tokens with PINs

(FIPS 140-1 level 2)

No

Yes

Yes, recommended

Hardware security modules with operator hardware token

(FIPS 140-1 level 3 or 4)

Yes

Yes, recommended

Yes, recommended

Even if an offline root CA might run only when the CA certificate must be renewed or the CRL has to be published, the CA must be installed on reliable hardware. If you are thinking about using a notebook computer to take the role of the root CA, note that it does not meet the requirements for reliability at the time that this document is being published.

In most customer environments, maintaining a root CA requires extraordinary security measures. The level of security requires that the root CA is offline at all times and, preferably, protected in a secure physical environment. In theory, a desktop system with a removable hard drive can be used to protect a root CA.

Intermediate CAs

Intermediate CAs are subordinate to the root CA. By definition, if you implement an intermediate CA, the topology consists of a minimum of three tiers. The intermediate layer of a PKI hierarchy often provides useful policy, administrative or operational differentiation. Intermediate CAs are also known as policy CAs because they are often used to manage or dictate different security and operational policies between different geographical areas, business units, or the intranet or extranet for a corporation.

To implement policies without an intermediate CA, you can also assign policies to issuing CAs on a logical basis.

An intermediate CA's security requirements are the same as for the root CA because an intermediate CA provides CA certificates to online issuing CAs. The intermediate CA should be an offline, stand-alone CA.

Note

It is highly recommended that you only issue certificates from an intermediate CA after the administrator manually approves the request. This is the default configuration for a Windows Server 2003 stand-alone CA.

Issuing CAs

Depending on the architecture, an issuing CA is a subordinate of an intermediate CA or a subordinate of the root CA. Enterprise CAs are ideal for issuing large numbers of certificates, because they can automatically validate the user and certificate profile information. The purpose of an issuing CA is to enroll certificates to end-entities and not to subordinate CAs.

Note

You can limit the number of subordinate CA levels in a certificate hierarchy by defining a maximum path length in the basic constraints extension of a CA certificate. A path length of zero will ensure that an issuing CA may only issue certificates to end-enties. You can define the basic constraints extension and path length by using a CApolicy.inf configuration file.

Understanding Root Trust

When a client uses a certificate, it is mandatory that the trust relationship between the certificate and the root CA can be verified. A certificate is trusted if the client that verifies the certificate trusts the root CA certificate that is in the client certificates certificate trust path as well. A client must have the related root CA certificate in its local certificate store to proof a trust-relationship with the root CA. For more information, see "Policies to establish trust of root certification authorities" on the Microsoft Web site.

If Active Directory is available, it is important to understand how clients like users or computers can benefit from Active Directory to establish a trust relationship with the root CA

You can achieve the trust that is obtained from a root certification authority by deploying the root CA certificate through one of the following six methods:

  • Enterprise trust in Active Directory

  • Group policy in Active Directory

  • Certificate Trust Lists (CTLs) in Group Policy

  • Manual trust on a local computer

  • Manual trust by a user

  • Windows Update

Depending on the permissions and the scope of the distribution mechanism, certificates are put into different locations and require different maintenance tools. For more information, see the following table.

Table 10 Certificate Trust Mechanisms

Distribution method Scope Uses Group Policy object Location Maintained with

Enterprise trust

Entire forest

Yes

Services\Public Key Services\CertificationAuthorities

Certutil.exe or PKI Health Tool

Group policy trust

Domain

Yes

Domain Security Group Policy object

Group Policy MMC

NTAuth (for CAs trusted to issue authentication certificates)

Entire forest

Yes

Services\Public Key Services\NTAuth object

Certutil.exe or PKI Health Tool

Manual trust on the local computer

Local computer and all users that log on to system

No

Registry HKEY_LOCAL_MACHINE

Certificates MMC for the local computer

Manual trust by user

Current user

No

Registry HKEY_CURRENT_USER

Certificates MMC for the local computer

Windows Update

Local computer and all users that log on to system

No

Registry HKEY_LOCAL_MACHINE

Group Policy MMC or Add or Remove Programs in Control Panel

Enterprise Trust

You can use the built-in autoenrollment service to automatically download root CA certificates and certificate trust lists (CTLs) from the Active Directory enterprise trust store on both Windows 2000 and Windows XP clients.

For additional information, see the following articles on the Microsoft Web site:

Group Policy Trust

Group Policy trust is defined and configured by using the Group Policy MMC and the Default Domain Security Group Policy object. Group Policy trust is configured and enforced for the domain where the Group Policy object applies. Because of this, different users in different domains trust different root CAs. It is highly recommended to create a new domain policy and not edit the default domain policies.

Note

Only root CA certificates must be trusted and registered on client computers. Do not add subordinate CA certificates to the Group Policy trust, because intermediate and issuing CAs certificates may not be explicitly trusted. CryptoAPI automatically

NTAuth

The NTAuth store is deployed on all computers in the forest from the configuration partition of the forest in the following directory path:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Important

NTAuth CAs are trusted to both issue authentication (logon) certificates for any user in the forest and enable logon for smart cards, Internet Information Services (IIS) mapping, and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).Precise control of issuing CAs can be achieved through qualified subordination with constraints.

You can verify the certificates that are currently registered in NTAuth by typing the following at a command prompt where the domain component information is configured with the name of the Active Directory root domain:

certutil.exe -store ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

You can see a more visual display of certificates by typing the following at a command prompt:

certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC="

You can also manually maintain the NTAuth store by typing one of the following commands at a command prompt:

certutil –addstore

certutil –delstore

certutil –dspublishCertificateFileNTAuth

For more information about the NTAuth store and smart card logon, see the following articles on the Microsoft Web sites:

In a Windows Server 2003 Active Directory environment that contains only clients running Windows XP, the NTAuth store is not mandatory for smart card logon and certificate mapping, compared to a Windows Server 2003 mixed environment with Windows 2000 clients. Because Windows Server 2003 Active Directory supports publishing cross-certificates and because clients running Windows XP support name and policy constraints for x.509 certificates, administrators may waive the NTAuth policy in homogenous Windows Server 2003 and Windows XP environments. This option requires and assumes that CAs have defined name constraints instead of being listed in the NTAuth store of the directory. Therefore, domain controllers that process both smart card logon and certificate mapping requests will explicitly trust all CAs that chain to trusted root CAs, assuming that the certificate matches a valid user account in Active Directory.

Warning

Disabling NTAuth policy verification enables domain controller trust of any CA that issues a valid smart card logon certificate and chains to a trusted root CA in the Active Directory environment. Any CAs, including the default third-party root CAs, should have name constraints defined before disabling the NTAuth policy. If this does not occur, unintended trust and logon access may occur. Use this option with extreme caution and only when root CAs have been properly constrained in the environment.

For more information about qualified subordination and name constraints, see "Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003" on the Microsoft TechNet Web site.

Manual Trust on a Local Computer

Root CA certificates may also be manually trusted on a local computer by using the Certificates MMC snap-in for the local computer. The user must be a local administrator to add root CA certificates to the machine certificate store. All root CA certificates in the computer's machine certificate store are inherited by all users who log on to that computer. The users trusted root certificate store and the machine trusted root certificate store form a union from a user's perspective.

For more information about certificate stores, see Chapter 13, Public Key Technology on the Windows 2000 Resource Kit Web site.

Confirm that certificates are stored in the correct location. Any root CA certificate that is stored in the local computers certificate store is visible to any user on that computer. If a root CA certificate is registered in the local computer store and if the CA certificate is also manually added by a user, the root CA certificate might appear twice in the Certificates MMC snap-in. If a root certificate is not available in the local computers certificate store but is available in the users store, building a certificate chain also may not work for some applications.

You can maintain the computers certificate store also with the Internet Explorer Administration Kit (IEAK) or CAPICOM. For more information about CAPICOM, see the article "CAPICOM Reference" on the MSDN Web site.

Manual Trust by User

It is recommended that only administrators maintain certificate trust and that you store only CA certificates in the local computers certificate store.

Windows Update

By default, computers that are running Windows XP and members of the Windows Server 2003 family run a service that will download updated public root CA certificates that have been added to the Microsoft root program. The service is not available in the Windows 2000 family.

Any organization that has a CA that meets the requirements that are outlined in the Microsoft Root Certificate program is able to distribute the CA certificate through Windows Update. For more information, see "Microsoft Root Certificate Program" on the Microsoft TechNet Web site.

Computers that are running either Windows XP or Windows Server 2003 periodically download the current list of Root CA certificates that are added to the Third-Party Root Certification Authority store on the local computer. For more information, see the chapter "Certificate support and the Update Root Certificates component" in "Using Windows XP Professional with Service Pack 1 in a Managed Environment: Controlling Communication with the Internet," which is available for download on the Microsoft Web site.

To install or remove this service, you can use Add or Remove Programs. To do this, click Start, point to Control Panel, and then click Add or Remove Programs. In the toolbar, click Add/Remove Windows Components, and then, in Components, select the Update Root Certificates check box.

This service can also be managed through Group Policy in Active Directory.

Figure 2: Windows Components Wizard

Art Image

Creating an Enrollment Strategy

A certificate can be used to provide authentication evidence of its owner, encrypt, or sign data. Because of this, the certificate issuer must ensure that certificate holders are known entities. Before certificates are enrolled, you should answer the following questions:

  • How will users obtain their certificates?

  • What is the process for enrollment identification?

The most secure way to initially enroll user certificates is to do a face-to-face authentication at the registration authority and store user certificates on hardware tokens. This provides the highest level of assurance, but also the highest cost of deployment.

If certificate enrollment with hardware tokens through enrollment agents is not an option, the CA can verify the certificate requester with domain credentials. This authentication method for certificate enrollment is usual when users self-enroll certificates. This scenario assumes that a user is the only person who is able to use the credentials.

It is recommended that you use a combined enrollment strategy that implements a strong initial identity check. Subsequent certificate enrollment and renewal can then be based on the initial certificate.

Creating a CA Renewal Strategy

Certificate lifetimes can have an impact on the security of your PKI for the following reasons:

  • Over time, encryption keys become more vulnerable to attack. In general, the longer amount of time that a key pair is in use, the greater the risk that the key can be compromised. To mitigate this risk, you must establish the maximum allowable key lifetimes and renew certificates with new key pairs before these limits are exceeded.

  • When a CA certificate expires, all subordinate certificates that are issued by this CA for validation also expire. This is known as time nesting and is traditionally enforced by CryptoAPI in the client.

  • When a CA certificate is revoked, all certificates that have been issued by the CA must also be re-issued.

End entity certificates expire when the issuing CA certificate reaches the end of its lifetime, unless:

  • The end entity certificate is renewed with a new key pair that chains to a CA certificate with a longer lifetime.

  • The end entity certificate was revoked before the CA certificate expiration date is reached.

You must plan the CA certificate renewal precisely during the PKI deployment phase. If this important planning step is missed, the entire PKI might stop working when the CA certificate expires, because all of the certificates that depend on the CAs certificate are then no longer usable for both encryption and signing operations. Remember that a certificate is capable of decrypting data, even if it has expired or been revoked.

Note

It is strongly recommended that you generate new key material when you renew a CA's certificate in order to partition the CRL that is issued by the CA and also prevent ambiguous certificate chaining errors caused by use of the same public key.

Determining the Total Number of CAs

The total number of CAs depends on the organizations security requirements and the organization's size. It is also dependent upon the geographical, political, and business hierarchy of the organization. As outlined earlier in this document, there is a choice of different trust levels that may be applied. After the organization has decided how many tiers should be implemented, it is important to plan the number of CAs that are required at each level. For a PKI topology that uses intermediate CAs, the number of CAs depends on the number of different CA policies that are required to issue CAs. The number of issuing CAs depends on the number of certificates that should be issued, the network connectivity between the requester and the CA, and the number of intermediate CAs.

A three-tier architecture consists of:

  • One root-CA

  • At least one policy CA (This can be one or many servers.)

  • At least two issuing CAs for every policy CA to ensure fault tolerance

A two-tier architecture consists of:

  • One root-CA

  • At least two issuing CAs to ensure fault tolerance

  • A single-tier architecture consists only of a single CA.

Note the following:

  • You cannot change the CA type at a later time; you must uninstall the original CA and then reinstall the CA to change it from either a stand-alone CA to an enterprise CA or an enterprise CA to a stand-alone CA.

  • You can install only one instance of a CA on a Windows Server 2003 system.

  • The certificate distribution point and the CRL publication interval is valid for all certificates that are issued by a CA and cannot be set for individual certificates.

For certificates that are used externally, the naming and information that is part of the certificates should not reveal the internal PKI or network infrastructure, such as the name of a CA or CRL distribution point paths in the issued certificates.

Hardware Requirements

This section provides some general guidelines for hardware requirements for a Windows Server 2003 CA. This section should not be used as an authoritative guide for performance characteristics. Specific performance characteristics vary, depending on the implementation and customer environment.

Hardware Guidelines

Microsoft performance testing in a lab environment has shown that the signing key length of the CA has the most significant impact on the enrollment rate of the CA. A larger number of certificates can be signed and enrolled in a given time if a smaller key size is used. If a larger key size is used, more CPU time is required to issue certificates.

The total number of issued certificates should not have a significant influence on either server performance or the rate at which the CA issues certificates; the performance of the issuing CA stays nearly the same, whether thousands or millions of certificates have previously been issued. Therefore, the scalability of the CA is considered to be linear, based on the size and performance of the disk arrays that are used to store both the database and log files.

The following table lists configuration factors that may affect performance of the CA.

Table 11 Resources That Affect CA Performance

Resource Performance notes

Number of CPUs

Additional CPUs increase the overall performance of the CA. This is the most critical resource for a Windows Server 2003 CA.

Memory

In general, additional memory does not have a significant role in the enrollment performance of the CA. The CA should meet general recommended system requirements (512 MB), however, the minimum amount of memory is 256 MB.

Disk size

The capacity of the disk volume that stores the database and log files it the primary limiting factor for the number of certificates that a CA is able to maintain.

Disk performance

In general, a short key length (512 KB) generates very little CPU utilization and a very high disk load. Larger key sizes generate more CPU utilization and less disk usage. A high-performance disk subsystem can increase the rate of enrolled certificates. A RAID set is recommended for both performance and fault-tolerance purposes. CA operations are primarily disk-write intensive.

Number of volumes

Using separate disks for the database and log files provides basic performance improvement. In general, the drive that contains the CA database is used more than the drive that contains the log files. The disk write capacity improves if you use more physical drives in a RAID set.

RAID stripe size

It is recommended that you use a stripe size larger than 64 KB.

Key length

The larger the signature key length, the greater the CPU utilization. Larger keys degrade CA performance. To be CPU-independent, you may want to use hardware acceleration to provide a large number of both key generation and signing operations.

Bandwidth

A 100 megabit network connection is suitable to enroll a large number of certificates and causes no performance bottleneck, assuming that the server is running the CA exclusively with no additional applications or network services.

Processor Notes

In general, a computer that has a current processor and 512 MB of memory is considered sufficient for most organizational uses of a Windows Server 2003 CA. The enrollment rate is directly related to the ability of the CA to sign requests that are based on CPU availability. Many hardware, environmental, network, or client factors can affect the performance of a CA.

Disk Configuration Notes

Disk space and disk speed also limit the performance and scalability of a CA. Each certificate that is issued uses approximately 16 KB of disk space in the database, and an additional 4 KB is required if the private key is archived. The certificate database must contain all of the issued certificates to be able to revoke certificates and provide a record of operations. Because none of the records are ever automatically tombstoned or automatically deleted, the certificate database continuously increases in size when new certificates are issued. Nevertheless a CA administrator can use the Certutil.exe command-line utility to delete expired records from the CA database.

Scalability

The Windows 2000 CA has been tested to issue more than 7 million certificates and the Windows Server 2003 CA has been tested to issue more than 35 million certificates on a single four-processor, x86-based computer. The maximum database size was not reached in either of the test scenarios.