Lesson 1: Planning a Certification Authority Hierarchy

The primary part of your PKI deployment is the design of your Certification Authorities (CAs). The deployment of your PKI must include the following steps:

  • Determine whether a public CA or a private CA meets your PKI-aware application's business needs. In some cases the design will call for a mix of public and private CAs.
  • Design a CA hierarchy that allows all clients to recognize and verify all issued certificates.
  • Determine whether to deploy an Enterprise or Standalone scope for your private CAs. Each scope offers advantages in specific scenarios that are outlined in this lesson.
  • Plan security for the root CA of your CA hierarchy.
  • Plan a disaster recovery for the potential failure of a CA.

After this lesson, you will be able to

  • Plan and design a CA hierarchy to meet your organization's business needs while maintaining the highest level of security on the network

Estimated lesson time: 60 minutes

Reviewing PKI Components

A PKI is comprised of several services and components working together. A PKI's primary components include

  • Certificates. Electronic credentials that are used to represent an entity on the network. The entity can be a user, a computer, or a network device. Possession of a certificate and its associated public and private keys provides authentication and encryption services. Certificates are the foundation of a PKI.
  • Certificate templates. Define whether a certificate can be designed for a single usage (EFS Recovery) or for multiple purposes (User or Computer).
  • Certificate Revocation List (CRL). A list of certificates that have been revoked before reaching the scheduled expiration date. The CRL includes both the certificate's serial number and the reason for the revocation.
  • Certification authority (CA). A trusted entity or service that issues and manages digital certificates. In a Microsoft Windows 2000 network, you can define CAs by installing Certificate Services on a Windows 2000 Server or Windows 2000 Advanced Server.
  • Certificate management tools. Provided through the Windows 2000 Certification Authority snap-in for the Microsoft Management Console (MMC) to allow management of the issued certificates. From the Certification Authority console you can revoke, issue, and audit all certificates that have been issued by the CA. You can also use the Active Directory Sites And Services console for certificate management. You can configure the permissions for individual certificate templates from the Active Directory Sites And Services console.


    In addition to graphical tools, the Microsoft Windows 2000 Server Resource Kit includes text-based certificate tools, including Certutil and Dsstore. Certutil provides the same functionality as the Certification Authority console. Dsstore is used to manage CA certificates in Active Directory.

  • Certificate distribution point. A location where certificates or CRLs can be retrieved by clients that participate in a PKI. Publication points include Active Directory, Web servers, FTP services, and the local file system.
  • Public key–enabled applications and services. Applications that use certificate-based security. Examples of public key–enabled applications include Microsoft Outlook Express and Microsoft Internet Explorer. Examples of PKI-aware system services include Encrypting File System (EFS), Smart Card Logon, and Internet Protocol Security (IPSec).

Determining Whether to Use a Private or Public CA

One of the first decisions you need to make when you deploy a public key–enabled application is where to obtain the necessary certificates. In general, you must decide between a public CA (also known as a third-party CA) and a private CA.

Choosing a Public CA

Public CAs are managed by third-party companies such as Entrust or Verisign. You should obtain certificates from public CAs when the application requiring the certificates runs on a public network and when the use of a third-party certificate increases customer trust in the application. For example, most e-commerce sites obtain the certificate for their secured Web site from a public CA. Consumers may not trust a small or unknown organization when that same organization issues the certificate for the Web site.

Public CAs include an issuer statement that describes rules of conduct for the certificate. The issuer statement (or CPS) defines acceptable usage, conduct that results in the certificate's revocation, and the issuing company's liability. Public CA service isn't free. Any certificates acquired from a public CA have a price determined by the certificate's use.

Public CAs are also used for interorganization projects. Each organization can trust certificates from the other if they're acquired from a common root authority such as Verisign or Entrust. If you use a public CA, the CA hierarchy is simplified because certificates are acquired from a common CA structure.

Choosing a Private CA

For many internal applications a private CA may be beneficial. Windows 2000 provides all the tools needed to create and maintain a private CA within Certificate Services.

You should obtain certificates from private CAs when you need greater ability to manage and control certificates issued to clients. Rather than waiting for a third-party organization to revoke certificates, you're immediately able to implement the revocation process when you need to.

Consider whether participants will trust certificates issued by your CA and how you will make key certificate services publicly available. These resources include the CA's certificate and the Certificate Revocation List associated with the CA.

Should I Mix and Match Public and Private CAs?

Sometimes it's best to mix private and public CAs. For example, if you're hosting a Web-based application on your extranet that will be protected using Secure Hypertext Transfer Protocol (HTTP-S) and you also wish to implement certificate-based authentication, the best solution is a mix of public and private CAs.

For the Web server, you want to acquire a Web server certificate from a trusted public CA. This certificate allows encryption of all data transferred between the client and the Web server hosting the application. The public CA certificate inspires consumer confidence in your Web server because your Web-based application must follow the issuance policy of the public CA that issued the certificate.

For certificate-based authentication of users, it may be desirable to create a private CA to manage user certificates. The primary advantage of using a private CA is that your organization has much more control over the management of issued certificates. It can revoke a compromised certificate quickly if necessary.

Making the Decision

Use the decision matrix shown in Table 10.1 to determine whether to implement a public or a private CA for your application.

Table 10.1 Choosing Between Public CAs and Private CAs

Use a When
Public CA Your application requires verification from a trusted third party, such as selling products on the Internet.

You don't have, and don't want to allocate, the resources to deploy an internal PKI.

Time is limited. Public CAs already have the necessary infrastructure in place.

A project requires certificate interoperability between organizations. Use of a public CA provides all issued certificates with a common root CA.

Your application requires liability protection in case security is breached for your certificate-based application.

Private CA Your organization wants to maintain management control of all client-associated certificates.

The certificates will be used only for internal projects, applications, and services.

You want to minimize the costs associated with issuing certificates.

Your organization has PKI expertise that can manage and maintain Certificate Services.

Applying the Decision

Blue Yonder Airlines requires a mix of public and private CAs for its PKI deployment. The Web server that hosts the online booking Web site must have a public CA–issued certificate to ensure customer confidence in the security of sensitive data such as credit card information. As an added security feature, you also should configure the Web server to require 128-bit encryption to provide the strongest form of encryption available.

A private CA makes it possible to issue smart cards to customers while maintaining the ability to revoke certificates quickly (within four hours, for example, as described in the scenario). Likewise, a private CA provides internal employees with smart card logon and EAP authentication for remote access. Consequently, Blue Yonder Airlines requires a mix of private and public CAs.

Determining the Certification Authority Structure

Most PKI deployments require multiple CAs in the organization. The CAs are organized into either a rooted hierarchy or a cross-certification hierarchy, depending on business needs.

Deploying a Rooted Hierarchy

Rooted hierarchies are the most common CA structures. A rooted hierarchy has an initial CA, known as a root CA. The root CA is unique in that it issues itself a certificate. This certificate is also known as a self-signed certificate.

Below the root CA are one or more subordinate CAs. The root CA issues certificates to the subordinate CAs with the subject matching the name of the subordinate CA, as illustrated in Figure 10.3.

Figure 10.3 A rooted CA hierarchy

Additional levels of CAs might exist below a subordinate CA. These CAs are often referred to as issuing CAs. Rooted CA hierarchies enable the highest form of security because you can remove the root CA from the network, thus protecting it from attack.


There are far-reaching implications if a CA is compromised and the CA's certificate must be revoked. Not only is the CA's certificate revoked, but all certificates issued by the CA—including those issued by subordinate CAs that received their certificates from the compromised CA—are considered compromised and are invalidated. By removing the root CA from your network, you can ensure that all certificates are protected from key compromise of the root CA.

Deploying a Cross-Certification Hierarchy

In a cross-certification hierarchy, a CA acts as both a root CA and a subordinate CA. This structure is used when two organizations want to establish certificate trust between them.

Cross-certification is commonly deployed in business-to-business scenarios when the participating organizations have existing CA hierarchies. Cross-certification allows existing hierarchies to be maintained while allowing additional CAs to exist in the hierarchy.

Figure 10.4 shows an example of a cross-certification hierarchy.

click to view at full size.

Figure 10.4 A cross-certification CA hierarchy

In this hierarchy the Corp CA is the root CA for the corporation. In addition to the self-signed certificate signifying that the Corp CA is a root CA, the Corp CA also has a subordinate CA certificate issued by the Partner CA. This certificate indicates that the Root CA is a subordinate CA of the Partner CA. Following the same logic, the Partner CA is a subordinate CA of the Corp CA.

Figure 10.5 shows the logical structures that exist in the case of cross-certification.

click to view at full size.

Figure 10.5 The logical view of a cross-certification CA hierarchy

The CA hierarchy on the left shows the CA structure from the Corp organization's perspective. The Corp CA is the root CA, and the Partner CA is the subordinate CA. The CA hierarchy on the right shows the CA structure from the Partner organization's perspective. For the partner organization, the Partner CA is the root CA and the Corp CA is a subordinate CA of the Partner CA.

The risk of cross-certification is that the existence of another organization's root CA means that all other CAs in the structure and the certificates issued by those CAs are also trusted. This circumstance often might be considered excess trust between organizations. You may want to trust only certificates issued by a specific CA located within a partner's CA hierarchy.

You can minimize this risk by implementing certificate trust lists (CTLs). A CTL is a group of CA certificates deemed trustworthy by a CA administrator. Only certificates issued by CAs in the CTL can be used. In a cross-certification scenario, only the CAs at the partner's site that you trust would be included in the CTL.

Making the Decision

Use the decision matrix in Table 10.2 to decide whether to implement a rooted CA hierarchy or a cross-certification hierarchy.

Table 10.2 Designing Certificate Hierarchies

To Do the Following
Provide maximum security for the root CADeploy a rooted CA hierarchy. Only a rooted CA hierarchy allows the root CA to be removed from the network.
Limit trusted CAs to your organization's CAsDeploy a rooted CA and remove all other CAs from the trusted root store.
Provide interoperability between organizations Deploy a cross-certification hierarchy where the root CA from each organization is configured as a subordinate CA of the other organization.
Limit which CAs will be trusted from a partner organization Deploy a cross-certification hierarchy and configure a CTL that contains only the trusted CAs from the partner organization.

Applying the Decision

Blue Yonder Airlines requires a CA hierarchy only for the internal network and for customers of its Web site. The company doesn't need to create cross-certification with another organization.

The rooted CA hierarchy allows Blue Yonder Airlines to increase security by removing the root CA from the network. Even though Blue Yonder Airlines will acquire a certificate for their Web server from a public CA such as Entrust, there's no business reason to create cross-certification between the Blue Yonder Airlines CA hierarchy and the Entrust CA hierarchy. The Entrust certificate will be trusted because the root certificate from Entrust CA will be included in the Trusted Root Certification Authorities container by default for all users of the network, as shown in Figure 10.6.

click to view at full size.

Figure 10.6 The entrust root CA certificate included in the Trusted Root Certification Authorities store

Planning the Scope of a CA

Within Microsoft Services you can install two scopes of CAs: Enterprise and Standalone. The scope of the CA defines where the CA stores its database of issued certificates and how the CA issues certificates, as shown in Figure 10.7.

click to view at full size.

Figure 10.7 Configuring Certificate Services as either an Enterprise or Standalone CA

Deploying an Enterprise CA

An Enterprise CA must be a member of a Windows 2000 domain. Only members of the Enterprise Admins universal group can install an Enterprise CA. If you aren't a member, the Enterprise CA options will be unavailable.

Some of the reasons to consider deploying an Enterprise CA include

  • Certificate templates. Enterprise CAs use certificate templates to restrict certificate usage. Each certificate template includes definitions of authorized purposes. A template can have either a single purpose or several purposes. A certificate can only be used for its defined purposes.


    Only Enterprise CAs support the use of certificate templates. Standalone CAs don't implement certificate templates to define certificate usage restrictions.

  • Integration with Windows 2000 security. Enterprise CAs provide integrated Windows 2000 security by applying the Windows 2000 security model to certificate templates. Permissions for individual certificate templates are configured in Active Directory Sites And Services. You can access the available certificates within the Certificate Templates container, as illustrated in Figure 10.8. Only security principals with both Read and Enroll permissions can acquire specific certificate templates.

    click to view at full size.

    Figure 10.8 Configuring Enroll permissions for each certificate template

  • Storage of data in Active Directory. Enterprise CAs use Active Directory to store the Certificate Services database, thus ensuring that the data is protected by Active Directory's multimaster replication model.
  • Some applications and services that require Enterprise CAs. Enterprise CAs are required for smart card logon, and EFS encryption. If you want to deploy these technologies in your environment, you must deploy at least one Enterprise CA to issue the necessary certificates.
  • Reduction in management for certificate issuance. Enterprise CAs issue certificates based on the credentials of the security principal requesting the certificate and the permissions assigned to the specific certificate template. Because the default issuance policy for Enterprise CAs is to automatically issue certificates, a certificate administrator doesn't need to approve certificate requests, as illustrated in Figure 10.9.

Figure 10.9 Certificates issued automatically by Enterprise CAs

Deploying a Standalone CA

Standalone CAs can be members of a domain or stand-alone servers in a workgroup. The Standalone CA differs from the Enterprise CA because all data is stored in a local database and the Standalone CA doesn't use certificate templates.

Because the Standalone CA doesn't use certificate templates, a security principal must complete a form when requesting a certificate. By default, the certificate request is then reviewed by a certificate administrator who accepts or rejects the certificate request in the Certification Authority console. All requests requiring a decision by a certificate administrator will be placed in the Pending Requests store until a certificate administrator either issues or denies the certificate request, as illustrated in Figure 10.10.

click to view at full size.

Figure 10.10 A Standalone CA issuing a certificate request


The default behavior for a Standalone CA is to require the certificate administrator to issue or deny certificate requests. You can configure the issuance policy to automatically issue certificates for valid certificate requests to match the default behavior of an Enterprise CA.

Consider deploying a Standalone CA when

  • You're establishing an offline root CA. Offline root CAs, by default, aren't attached to the network. This circumstance prevents the use of an Enterprise CA because Enterprise CAs store the Certificate Services database in Active Directory. With the root CA removed from the network, you'd be unable to access the certificate database. For all offline CAs, you must select a Standalone scope for the CA.
  • You want to integrate Windows 2000 Certificate Services with an Exchange 5.5 Key Management Server (KMS). The Exchange 5.5 KMS requires that the issuing CA be a Standalone CA to run the Exchange 5.5 Policy. Certificate Service must be configured to run as a Standalone CA to support X509.3 certificates.


    X.509 is a standard for digital certificates defined by the International Telecommunication Union-Telecommunications Standardization Sector (ITU-T) and the ISO/International Electrotechnical Commission (ISO/ IEC). First published in 1988 and then extended in 1993, the current version (3.0) was released in 1996.

  • You require a CA to run in the Demilitarized Zone (DMZ) where it can't contact Active Directory. If the CA isn't able to connect to Active Directory, then the CA must be configured as a Standalone CA.

Mixing and Matching CAs

A common question is whether you can mix Standalone and Enterprise CAs in the same CA hierarchy. The answer is Yes! When you design a secure CA hierarchy, one of your goals is to configure the root CA as an offline CA. You must use Standalone CAs for offline root CAs, due to Enterprise CAs' dependence on Active Directory.

Figure 10.11 shows a CA hierarchy that mixes both Standalone and Enterprise CA policies.

click to view at full size.

Figure 10.11 Enterprise and Standalone CAs existing in the same CA hierarchy


Don't consider Enterprise to mean domain and Standalone to mean workgroup. The terms refer only to where the certificate services database information is stored.


Making the Decision

Use the decision matrix in Table 10.3 to determine when to implement an Enterprise CA or a Standalone CA in your certification authority hierarchy design.

Table 10.3 Deciding Between Enterprise and Standalone CAs

Use This CA Scope When You Want To
Enterprise CA Deploy Certificate Services for an internal deployment where the users will be providing their network credentials for authentication.

Deploy Windows 2000 services that require certificate templates provided only by Enterprise CAs. These include

  • EFS deployment
  • IPSec deployment
  • Smart card logon

Leverage the standard Windows 2000 security model to determine who can acquire specific certificate templates.

Standalone CA Deploy offline CAs that must operate without communicating with the rest of the network.

Configure the Exchange 5.5 KMS to use x.509 v3 certificates, rather than the default x.509 v1 certificates.

Place the CA in a location where it can't connect to Active Directory.

Applying the Decision

The requirement to issue smart cards for both customers and internal user accounts requires you to deploy an Enterprise CA. Only an Enterprise CA supports certificates for smart cards. Each CA hierarchy should have an offline root CA to increase the security of the CA hierarchy. An offline root CA requires you to configure a Standalone scope for the CA.

For the internal network, Blue Yonder Airlines requires a mix of Standalone and Enterprise CAs.

Planning Offline CAs

An important step in protecting your CA hierarchy is to remove the root CA, and, potentially, a second level of CAs from the network. This action ensures that the CAs aren't compromised. Remember that if a CA is compromised, all certificates issued by the CA also are compromised.

The decision to remove a CA from the network isn't as simple as removing the network interface card or shutting down the server. The design of an offline CA also must include the following considerations:

  • Storage location of the offline CA. You should store the CA in a secure location that makes it extremely difficult to reattach the offline CA to the network. For example, many companies store an offline CA in a vault that's accessible only to authorized personnel.
  • Use of a strong Cryptographic Service Provider (CSP). Windows 2000 includes several default CSPs. CSPs are software modules that actually define how cryptography algorithms are used for authentication, encoding, and encryption. For the strongest form of encryption, consider using a hardware CSP that's physically attached to the offline CA. Hardware CSPs provide additional security by requiring two-factor authentication. For example, some hardware CSPs require the use of a smart card for generating private/public key pairs.
  • Publication of the CRL. Issued certificates must be verified against the CRL even when the CA is removed from the network. Your design must define an accessible network location where the CRL will be published and define how frequently the CRLs will be updated.
  • Publication of the Authority Information Access (AIA). As with the CRL, the certificate associated with the CA must also be available. Clients determine where to access the CRL through the certificate attributes. The AIA publication point must also be set to be a location that's always available.
  • Definition of certificate renewal period. Avoid the need to continually update the root certificate for your CA hierarchy. In general, the root CA certificate should have the longest lifetime of any certificate issued on the network. This ensures that the remaining lifetime on the root CA certificate doesn't affect the lifetimes of any certificates issued by the root CA or CAs subordinate to the root CA.

Configuring an Offline Root CA

You perform the primary configuration of an offline root CA in a text configuration file known as Capolicy.inf. The Capolicy.inf file must be placed in the Systemroot folder before you install Windows 2000 Certificate Services. The Capolicy.inf file is read from the Systemroot folder during the installation of Certificate Services. The following code example shows the structure of the Capolicy.inf file:

  [Version] Signature="$Windows NT$" [CAPolicy] Policies=LegalPolicy [LegalPolicy] OID=1.2.840.113556.1.4.7000.233.28688.28684.8.189041.1105561.1861398.1661801.1 Notice="http://www.abc.tld/certificate/cps.doc" [CRLDistributionPoint] URL="http://www.abc.tld/Public/crlname.crl" URL="ldap:///CN=EnterpriseCA,CN=CA-ROOT,CN=CDP, CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration, DC=abc,DC=tld?certificateRevocationList?base? objectclass=cRLDistributionPoint" [AuthorityInformationAccess] URL="http://www.abc.tld/Public/certname.crt" URL="ldap:///CN=EnterpriseCA,CN=AIA, CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration,DC=abc, DC=tld?cACertificate?base?objectclass=certificationAuthority" [Certsrv_Server] RenewalKeyLength=4096 RenewalValidityPeriod=5 RenewalValidityPeriodUnits=Years 


The four "%"s in a row aren't a typo. You must represent a space character with the string "%%%%20" when defining Lightweight Directory Access Protocol (LDAP) paths in the Capolicy.inf configuration file. The "%" symbols ensure that the space character is included in the LDAP URL.

The following sections are included in the Capolicy.inf configuration file:

  • The [Version] Section. This section defines the configuration file as a Windows NT-compatible configuration file. This circumstance enables the use of pointers for referencing future sections in the configuration file.
  • The [CAPolicy] Section. This section outlines all policies that are defined in the Capolicy.inf text file. It's possible to include multiple policies within a single Capolicy.inf configuration file.
  • The [PolicyName] Section. This section defines the object identification number (OID) for the policy and the legal notice text that will appear when you click the Issuer Statement button in an issued certificate. The issuer statement is also known as a CPS. By clicking the Issuer Statement button when viewing the certificate's properties, the user will either see the text string entered in the Capolicy.inf text file or be redirected to an Internet URL. Using a URL is advantageous in that it allows an organization to modify the CPS without having to renew the CA's certificate.
  • The [CRLDistributionPoint] Section. This section indicates alternative CRL distribution points for the CA. The CRL points must be set to locations that will be available when the CA is taken off the network. The CRL distribution point can be set to be an HTTP URL, an FTP URL, an LDAP URL, or a file reference. The example above shows both an HTTP and an LDAP URL.
  • The [AuthorityInformationAccess] Section. This section is used to indicate alternative AIA distribution points for the CA. As with CRL distribution points, the AIA points must be set to locations that will be available when the CA is taken off the network. The AIA distribution point can also be set to be an HTTP URL, an FTP URL, an LDAP URL, or a file reference.
  • The [Certsrv_Server] Section. This section outlines the settings for certificate renewal. Because the certificate for a root CA is self-issued, the renewal information must be read from the Capolicy.inf file. Options include the length of the keys that are generated during the renewal process and the interval at which key renewal must be performed.

Do You Use Capolicy.inf Only for Root CAs?

In most cases, the answer is yes. The only time you use a Capolicy.inf configuration file for a nonroot CA is to define a CPS for an issuing CA. The Capolicy.inf text file is the only way you can enter information into a CPS for Windows 2000 Certificate Services.

A nonroot CA processes only the [CAPolicy] and [Policyname] sections of the Capolicy.inf configuration file. All other sections are ignored because they're defined by the issuing CA from which the subordinate CA received its subordinate CA certificate.

In addition to configuring the Capolicy.inf file with CRL and AIA publication points, you must also configure the certificate distribution points (CDPs) for the CRL and AIA associated with the CA. Configure the CDPs in the properties of the Certification Authority by defining the X.509 extensions for the CA's policy module, as shown in Figure 10.12.

Figure 10.12 Defining certificate distribution points for the CRL and AIA

The URLs you define for the CRL and AIA distribution points will be included in the properties of any newly issued certificate by the CA.

Making the Decision

Include the design points featured in Table 10.4 in your security plan to ensure the security and functionality of an offline root CA.

Table 10.4. Securing Offline Root CAs

To Do the Following
Allow the CA to be removed from the network for long periods of time Configure the CA to be a Standalone CA. Make sure that the CA is installed on a Windows 2000 Server that isn't a member of a Windows 2000 domain.
Provide the strongest form of encryption at the offline root CA Implement a hardware CSP for the offline root CA.

Ensure that the associated CSP is installed before installing the offline root CA.

Make the CRL and AIA available to network users Configure the Capolicy.inf file to provide alternative locations for the CRL and AIA publication points.

Configure the publishing schedule for the CRL to be a longer period of time than for issuing CAs.

Configure the certificate distribution points for the CRL and AIA to be located at areas of the network that are available when the root CA is offline.

Establish a manual process for placing the updated CRL or AIA into the public locations outlined in the certificate properties for offline CAs.

Edit the registry to allow longer certificate lifetimes for the certificates issued by the root CA. The default of one year is too short for subordinate CAs.

Define a CPS Ensure that the Capolicy.inf file is edited and placed in the Systemroot folder before installing Certificate Services.

To provide for updates, ensure that the Notice= line references a URL rather than just a text statement. Using a URL allows you to modify the CPS without having to renew the CA's certificate.

Provide the most security for your CA hierarchy Ensure that at a minimum, the root CA is removed from the network. For higher-security networks, also consider removing the second layer of CAs in the rooted hierarchy from the network.

Applying the Decision

Blue Yonder Airlines must use a Standalone CA for the offline root CA. Depending on the level of business expected for the Web site, Blue Yonder also can remove a second layer of subordinate CAs from the network.

Blue Yonder Airlines must configure a Capolicy.inf configuration file to issue a CPS that defines usage policy for all customers who receive Blue Yonder Airlines smart cards. The Capolicy.inf configuration file must also provide CRL and AIA publication points that will be available when the root CA is removed from the network.

For example, Blue Yonder Airlines could use the following Capolicy.inf file when installing Certificate Services on their offline root CA:

  [Version] Signature="$Windows NT$" [CAPolicy] Policies=BlueYonder [BlueYonder] OID=1.2.840.113567.1.4.6000.234.28697.28632.8.1325041.1005461.1934398.1223661.4 Notice="http://www.blueyonder.tld/Public/etiquette.html " [CRLDistributionPoint] URL="http://www.blueyonder.tld/Public/crlname.crl" URL="ldap:///CN=RootCA,CN=OfflineROOT,CN=CDP, CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration,      DC=AD,DC=Blueyonder,DC=Tld?certificateRevocationList?base? objectclass=cRLDistributionPoint [AuthorityInformationAccess] URL="http://www.blueyonder.tld/Public/certname.crt URL="ldap:///CN=RootCA,CN=AIA, CN=Public%%%%20Key%%%%20Services,CN=Services, CN=Configuration,DC=AD,DC=Blueyonder, DC=Tld?cACertificate?base?objectclass=certificationAuthority" [Certsrv_Server] RenewalKeyLength=4096 RenewalValidityPeriod=5 RenewalValidityPeriodUnits=Years 

In addition to configuring the Capolicy.inf configuration file, Blue Yonder must set the following attributes for the CA before removing the CA from the network:

  • CRL publication interval. The CRL publication interval should be increased from the default of one week. Consider a value in the range of two to three months instead.
  • CRL and AIA distribution points. Disable the default CRL and AIA distribution points because the root CA won't be available on the network. Ensure that the updated versions of the CRL and AIA are manually copied to the distribution points defined.
  • The default lifetime for issued certificates. Edit the registry in HKLM \System\CurrentControlSet\Services\CertSvc\Configuration\CAName to set the value ValidityPeriodUnits to be greater than the default of one year.

Designing the Certification Authority Hierarchy

Once you've determined your CA structure's security by implementing an offline root CA, you must design a CA hierarchy below the root CA. The CA hierarchy helps you deploy certificates to security principals in your organization. In general, your CA hierarchy falls into one of the following general structures:

  • Structure by usage. In this structure, the issuing CAs will be configured to issue only specific certificate templates. The individual CAs are assigned to specific projects such as smart card logon, IPSec deployment, or secure email, as shown in Figure 10.13.

    click to view at full size.

    Figure 10.13 A CA hierarchy based on usage

    You configure this structure by setting each CA to issue only the certificates that are required by the associated project. For example, in a smart card deployment, you might want to configure the CA to issue only Smartcard User, Smartcard Logon, Enrollment Agent, and Enrollment Agent (Computer) certificates. This action restricts the CA to issuing only certificates for the smart card deployment.


    For more information on configuring a CA to support smart card authentication, see Lesson 3, "Using Certificates for Authentication," in this chapter.

  • Structure by administration. An administrative structure attempts to distribute CAs to match the administration of the network. For example, Figure 10.14 shows two subordinate structures divided according to whether the certificate recipients are employees or partners of the organization.

    click to view at full size.

    Figure 10.14 A CA hierarchy based on an administrative model

    At the third level in the figure, different CAs exist for full-time and part-time personnel so that different certificate validity periods can be issued.

  • Structure by location. In geographically distributed organizations you can delegate administration of certificates to IT personnel at each location. Figure 10.15 depicts an organization divided into Europe and North America. Below the subordinate CAs, you could configure the issuing CAs by usage or administration needs.

click to view at full size.

Figure 10.15 A CA hierarchy based on geographic location

Regardless of the structure, for maximum security you must configure the root CA as an offline CA. In higher-security networks, consider configuring the second-level CAs as offline CAs as well. For example, in the structure-by-location example in Figure 10.15, you could configure the Europe and North America CAs as offline CAs.

How Many Levels Do I Require?

The general goal is to create a CA hierarchy that's three to four levels deep. CA hierarchies with fewer than three levels are more vulnerable. If there are only two levels and the root level is compromised, all certificates also are compromised. Likewise, having a CA structure that's more than four levels deep introduces unnecessary complexity and might result in extra time being needed to verify the revocation status for each CA in the certificate chain.

Making the Decision

Use the decision matrix shown in Table 10.5 when deciding which CA hierarchy structure to deploy for your organization.

Table 10.5 Choosing CA Hierarchy Structures

Choose This CA Structure When the Following Conditions Exist
Usage structure There are several active projects within an organization and each project is managed by a separate team.

A pilot project requires that the CA related to the project be rebuilt when the project is launched for the entire organization.

You want CAs dedicated to issuing certificates related to specific projects.

Administrative structure The organization requires different issuance policies based on the relationship of the security principal to the organization.

You must issue the same certificate template, but with differing validity periods.

Location structure The organization is geographically distributed and management of certificates is delegated to each region.

The final CA hierarchy design might end up as a combination of these designs. You might need to implement a highly customized hierarchy to meet your business needs.

Applying the Decision

Blue Yonder Airlines could implement a CA hierarchy based on either usage or administration. Blue Yonder doesn't need to develop a CA hierarchy based on location because the smart card authentication for clients will be centralized at the Salt Lake City office.

Figure 10.16 shows one possible Blue Yonder Airlines CA hierarchy that meets both its customer and internal network needs.

click to view at full size.

Figure 10.16 A CA hierarchy based on administration and usage

Blue Yonder Airlines can establish two separate CAs for outside customers ordering airline tickets. The Enrollment CA will issue only Enrollment Agent (Machine) certificates and Enrollment Agent certificates. This arrangement allows greater security for the Enrollment Agent server. The Smartcards CA issues the smart card user certificate template.

You can establish three CAs for the internal network. Use the Internal Smartcards CA to issue all certificates related to smart card logon. Use the IPSec CA to issue IPSec-specific certificates for all computers that perform IPSec, including L2TP/IPSec Virtual Private Network (VPN) clients. Finally, use a dedicated CA to issue other certificates (such as User and Computer certificates) for users and computers requiring certificates for other purposes on the network.

Planning Disaster Recovery of CAs

The final step in deploying CAs is planning for the recovery of the CAs in the event of disaster. Disaster can result from disk failure or accidental removal of Certificate Services.

You can prevent CA failure by implementing hardware solutions for fault tolerance. Certificate Services performs best when you place the Certificate Services database on a redundant array of independent disks (RAID) volume that combines multiple disks into what is known as a stripe set with parity or RAID-5 disk volume. A RAID-5 volume protects data by writing the data in a stripe across multiple physical disks. For each stripe, one disk contains parity information that allows recovery of the data stored in that stripe if a single disk fails in the RAID-5 disk set. In addition, you should store the Certificate Services log files on a RAID-1 mirror set. This ensures that the log files are also protected in the event of disk failure. A mirror set offers better performance than RAID-5 disk volumes for log files.

Ensure that the Certificate Services data stores are backed up regularly. You can accomplish this in one of two ways:

  • Include the System State option in your Windows 2000 backup set
  • Manually run backup from within the Certification Authority console


You must include Internet Information Services (IIS) in the backup set because the Web Enrollment Support pages included with Certificate Services update the IIS metabase.

In the case of an offline CA, you may want to consider backing up the server with disk imaging software. Some organizations store an exact duplicate of the offline CA at a remote location to protect against natural disasters. When the CA is updated (such as renewing the CAs certificate), a new image is created for remote storage.

Making the Decision

Consider the points in Table 10.6 in your disaster recovery plan for CAs.

Table 10.6 Planning Disaster Recovery of a CA

To Do the Following
Prevent loss of data in the Certificate Services database Store the Certificate Services database on a RAID-5 disk volume. Hardware RAID-5 is preferable to software RAID-5 solutions for both performance and recoverability reasons.

Store the Certificate Services log files on a RAID-1 disk volume. As with the Certificate Services database, hardware RAID-1 solutions are preferable to software RAID-1 solutions for both performance and recoverability reasons.

Ensure that a rebuilt CA is still valid for all issued certificates Ensure that all server keys are backed up. This allows the CA to reuse existing keys in the event of a failure.
Allow a CA to be recovered Ensure that the Certificate Service database is regularly backed up through the Certification Authority console or by including System State in the backup set.
Ensure recoverability Run a test recovery to a different server to ensure that your recovery procedures are adequate.

Applying the Decision

Blue Yonder Airlines must include a backup and restore strategy for all CAs in their organization. The company should purchase a common computer system that implements RAID-5 and RAID-1 disk sets for the Certificate Services database and log files.

In addition, you should schedule regular backups that include the system state backups. The backup sets must include the IIS directory structure so that the IIS metabase captures all changes made by Certificate Services.

To ensure recoverability in the event that you have to rebuild and restore a CA from backup, you should export the existing private and public keys associated with the CAs certificate to files and include those files in the regular backup set.

Finally, you should create an image of the root CA for the hierarchy on a CD. This CD allows you to restore the root CA quickly in the event of failure. You must update this image whenever additional certificates are issued or renewed at the root CA.

Lesson Summary

Developing your CA structure is a primary component of your PKI design. The CA structure must meet your business needs, ensure security, and, most of all, provide the necessary functionality to ensure success for your PKI-based applications.

Make sure that your design includes a decision on whether to use public or private CAs for specific scenarios. Once you decide on using a public or private CA, you must design the CA hierarchy structure. This process involves determining whether to use a rooted hierarchy or a cross-certification hierarchy. With rooted hierarchies, you must decide whether a CA will be taken offline to protect the Certificate Services database from vulnerabilities.

Finally, you must design a CA structure that mirrors your administrative model. Protect the CA structure in the event of failure so that you can restore the CA hierarchy without reissuing certificates.

Microsoft Corporation - MCSE Training Kit (Exam 70-220. Designing Microsoft Windows 2000 Network Security)
MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)
ISBN: 0735611343
EAN: 2147483647
Year: 2001
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net