Chapter 16: Building and Maintaining a Windows PKI

In the previous chapters we explained some of the technical nuts and bolts of Windows Server 2003 PKI. In this chapter, we look at the different steps you need to consider when planning, designing, and building a Windowsrooted PKI.

16.1 Building a PKI

Like any other IT project, a PKI project can be split into four key phases: assessment, design, implementation, and management (administration and maintenance). The phases are illustrated in Figure 16.1. A PKI project can be iterative: During the implementation phase, for example, issues may arise that require a new assessment and changes to the original design.

Figure 16.1: The four major phases of a PKI project.

During the assessment phase, the current and future security requirements of an organization are analyzed. This can be done by running a security audit, performing a penetration test, or just analyzing existing processes. The assessment phase also includes a business requirement analysis.

The design phase deals with the technological and nontechnological design of the PKI solution. Nontechnological design topics include the creation of certificate policies and certification practice statements (CPS).

The implementation phase takes care of the rollout of the PKI solution, its integration with the existing IT environment, and, before the rollout, the development of customized PKI-enabled applications (PKA) or PKI software plug-ins.

Once the PKI is installed and deployed across your enterprise, you must manage and maintain it. In the management phase, you must set up the support model for the PKI (Helpdesk), PKI administrator, and user training and the management of the PKI components.

16.1.1 Assessing the organizational needs for a PKI

During a PKI assessment, you must analyze your company’s current and future security needs. As part of the assessment, you may need to gather some extra information. To do so, you can organize a security audit or a penetration test.

The next sections focus on three key areas of the assessment phase: the business requirement analysis, the decision on whether to insource or to outsource the PKI infrastructure, and the analysis of the applications that need PKI-based security.

Analyzing business requirements

The rollout of a PKI in an enterprise is typically driven by core business needs such as advanced security requirements for information storage and network communication. The size of the investment that a company makes in a PKI will depend on the criticality of the business problem that it wishes to resolve with it or the importance of the business processes whose security level it wants to improve by installing a PKI.

Some business security requirements do not need a certificate-based security solution and can be resolved with simpler arrangements. Also, not every certificate-based solution requires rolling out an enterprise PKI: For some solutions it is enough to buy a limited set of certificates from a commercial certification authority.

The business your organization is in may impose special requirements in the following areas:

• Availability: What level of availability does the PKI need within the organization? This affects the CAs, the CA databases, and the directories used in the PKI solution.

• Scalability: How scalable must the PKI be? Will it have to deal with rapid growth of the number of required certificates? Does planning have to take into account company mergers and acquisitions? Will more and more PKI-based applications be deployed in the future?

• Performance: PKI and its public key cryptography operations create an additional performance load for computer systems. Is this extra load acceptable? Should the existing hardware be upgraded? Should you install additional hardware that speeds up PKI operations?

• Cost: PKI products come in different flavors, with different features and in different price classes.

PKI-enabled applications

A PKI is an infrastructure, and many Windows applications can take advantage of it to provide strong security services to their users. Among these applications are networking systems, VPN systems, ERP software, document signing, and smart card–based applications.

You can build the following PKI-enabled applications (PKA) on top of a Windows PKI:

• Secure Web: You can use certificates for strong authentication using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.

• Secure mail: Signing and sealing electronic mail messages using S/

MIME (Secure Multi-Purpose Internet Mail Extensions) also build on public-key cryptography.

• File system encryption: Windows 2000 and later Microsoft OSs come with the Encryption File System (EFS) extension to the NTFS version 5 file system.

• Code signing: Code signing protects against the downloading of malicious code. The Microsoft code-signing technology is known as Authenticode.

• Document signing: Document signing technology provides the capability to add a digital signature to for example a Word document. This functionality overlaps with the features provided by the Microsoft Rights Management Services discussed in Chapter 12.

• Smart card logon: Smart card logon provides strong two-factor authentication in a Windows 2000 or Windows Server 2003 domain environment.

• Virtual private networking: Windows 2000 and later Microsoft OSs support the IPsec tunneling protocol, which can use certificates to authenticate IPsec tunnel endpoints.

• Remote access authentication: The Windows 2000 and Windows Server 2003 Remote Access Service (RAS) both support the Extensible Authentication Protocol (EAP), which can deal with certificate- based TLS authentication.

• Wireless authentication: Windows Server 2003 and Windows XP support certificate-based authentication for wireless network access.

• Securing SMTP site connections: You can connect Windows 2000 and Windows Server 2003 AD sites using asynchronous SMTP connections. In that case the bridgehead domain controllers authenticate to one another using certificates. This setup also protects the confidentiality and integrity of the AD replication traffic.

• Any custom PKI-enabled application that uses CryptoAPI

Insource or outsource?

You have three choices to implement and manage a PKI: insource, out- source, or a hybrid approach. See Figure 16.2.

Figure 16.2: Insourcing and outsourcing models.

Insourced PKI solutions are solutions that you install, implement, administer, and maintain all by yourself. This means that your IT department must take the lead in implementing all related PKI technologies: CA hardware, CA database, RAs, directories, and the communication links between all participating entities. This path offers you complete independence. You can create your own liability rules and security policies and can decide how to implement, administer, and maintain the PKI.

Outsourced solutions turn most of these responsibilities over to another company. The degree of outsourcing can range from a little (generating some server certificates) to a lot (outsourcing multiple CA services that are dedicated to your company). This is often the best solution for smaller companies or for those without the funds and resources required to install and maintain a proper PKI.

Hybrid solutions combine insourcing and outsourcing: Your company maintains a part of the CAs and another company maintains the rest. The CAs that are issuing certificates for applications with high security needs can, for example, be implemented and managed by the company itself. The implementation and management of CAs issuing certificates to applications with less strong security needs can then be outsourced.

Table 16.1 can help you choose between an insourced and an outsourced PKI approach.

Table 16.1 : Advantages and Disadvantages of Insourcing Versus Outsourcing

	Insourcing	Outsourcing
Pros	More and tighter control over certificate policy definition, certificate and key management, certificate issuance, key archival, and recovery. Tighter integration options: integration with enterprise directory and in-house applications. Potentially stronger trust relationships with partners because of in-house certificate policy control.	Leverage expertise of PKI experts. Less effort for planning, design, administration, and maintenance. Can be more cost-effective for a small enterprise. Can be operational in a short period of time. Requires less in-house expertise.
Cons	More expensive: cost of planning, design, administration, maintenance. Requires more in-house expertise. Possible complex integration and deployment. Requires more time to plan, design, and deploy.	Less policy control and enforcement capabilities. Less integration options. Can be more costly for a large enterprise.

16.1.2 Designing, planning, and implementing a windows PKI

In the following sections, we focus on the different steps you must consider when designing, planning, and implementing a Windows-rooted PKI.

PKI policy definition

An important nontechnical aspect that is often overlooked or neglected by technology-focused PKI planners is the definition of the certificate policies (CPs) and certification practice statements (CPSs). Both document categories are derived from a company’s security policy (SP). This section gives an introduction to PKI policy definition, CPs, and CPSs.

A CP focuses on certificates and the CA’s responsibilities regarding these certificates. It defines certificate characteristics such as certificate use, enrollment procedures, liability issues, and so on. The X.509 standard defines a CP as “a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.” The X.509 standard can be downloaded from http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.

A CP answers the following questions:

• For what applications can the certificate be used?

• How can a user enroll for the certificate?

• How are users identified when they request a certificate?

• What is a certificate’s lifetime?

• How is renewal defined? Is a new key pair generated every time a certificate is renewed?

• What key lengths and ciphers are used to generate the certificate?

• Where is the private key stored? How is it protected? Can it be exported?

• What is the CA’s liability when its private key is compromised?

• How should users react when they lose their private keys?

A CP is defined by a group of people within your organization that is known as the policy authority. This group should consist of representatives of the different key departments of your organization: management, legal, audit, human resources, and so forth. In most organizations, the policy authority members are also members of the group that defined the SP. This assures that the CP is in line with the SP.

The certification practice statement (CPS) translates CPs into operational procedures for CAs. Whereas a CP focuses on a certificate, a CPS focuses on a CA. Both the European Electronic Signature Standardization Initiative (EESSI) and the American Bar Association (ABA) define a CPS as “a statement of the practices that a certification authority employs in issuing certificates.”

A CPS answers the following questions:

• What certificate policy or policies does the CA implement?

• What are the policies for issuing certificates? How are certificates issued? Are they issued directly to users or published into a directory? What types of certificates can the CA issue and to which users?

• Who can administer the CA? What subtasks are delegated to the different administrators?

• What are the revocation policies? How is certificate revocation handled?

• When is a certificate revoked? Where are CRLs published? How often are CRLs updated?

• How is access to the CA physically and logically secured?

• Who is responsible for backing up the CA?

• What is the quality of the CA certificate and private key? What is the lifetime of the CA keys and the certificate? What is the CA key length?

• Where and how is the CA private key stored?

• What is the procedure for CA rollover?

The CPS should be defined by members of your IT department, people who are operating and administering the IT infrastructure, and the people who defined the CP. Good examples of a CPS can be found on the Web sites of the following commercial CAs:

• Globalsign: http://www.globalsign.net/repository

• Verisign: http://www.verisign.com/repository/CPS

• Entrust.net: http://www.entrust.net/about/cps.htm

A reference to the CP and CPS to which the CA adheres are made available in the CA certificate and every certificate the CA issues. To do so, the CA embeds a unique CP Object Identifier (OID; see also the following sidebar) in its certificate’s CertificatePolicies extension. This will allow the user of the certificate to reject certificates that were issued under a policy to which the user does not adhere. More detailed policy information can be added by including a URL pointer to the CPS or a short text notice in the certificate extensions.

Introducing Object Identifiers (OIDs) An OID is an object identifier. It is a string of numbers structured using a hierarchical dot notation. The OID format has been defined in the ITU X.209 standard. OIDs are maintained by the ISO standardization organization. To get an OID for your certificate policy, you must contact your local ISO naming authority.

An easy way to look up an OID assignment is available from the following Web site: http://www.alvestrand.no/objectid. This Web site also contains general OID information.

More information on CPs and CPSs is available in documents down- loadable from the following Web sites:

• RFC 2527 (also known as PKIX part 4), “Internet X.509 Public Key

Infrastructure Certificate Policy and Certification Practices Framework,” available from http://www.ietf.org

• Entrust white paper, “Certificate Policies and Certification Practice

Statements,” available from http://www.entrust.com

Defining Your Topology

When designing your Windows PKI topology, you must consider the four topics outlined next. Most of them were discussed in Chapter 14.

• Decide on the number of CAs. Your organization may require multiple CAs for scalability, business, geographical, CA policy, or political reasons.

• Choose a PKI trust model. Windows Server 2003 PKI supports the hierarchical, networked, hybrid, and constrained trust models.

• Map the trust model to the Windows domain and site model. The PKI trust model is totally independent of the Windows domain trust model: A single CA can span multiple domains and a single domain can host multiple CAs.

• Define relationships with external CAs or PKIs. To provide PKI interoperability between different PKIs, Windows Server 2003 PKI supports cross-certification and Certificate Trust Lists (CTLs). No matter which of the two you use, you must always define a trust policy. Will the trust be unidirectional or bidirectional? What will be the constraints of the trust?

Specifications of the individual CAs

Certification authorities are key PKI components, so you need to spend enough time to create a detailed design for each individual CA. Part of the CA parameters are set during the installation; another part is set post installation, in the CA configuration phase. Table 16.2 shows the different installation and configuration options you must consider. Besides these installation and configuration options, you must also consider CA hardware sizing.

Table 16.2: CA Installation and Configuration Options

Preliminary Planning	During CA Installation	As Part of the CA Configuration
CA hardware sizing	CA role (root, subordinate—stand-alone, enterprise)	Revocation policy
CA architecture (exit and policy modules)	CA key and certificate properties	Supported certificate types (certificate templates)
Offline CA?	CA naming conventions	Certificate characteristics
Advanced CA private key protection (Hardware Security Module)	CA data storage locations	Enrollment policy (identification options, who can enroll for what?)
—	Reference to CPS	Recovery agent configuration
—	CA X.509 certificate extensions	CA server hardening

Preliminary planning

Before installation of a CA, you must make sure that you think about the CA hardware sizing, its architecture (are special exit and/or policy modules required?), whether the CA will be an online or offline CA, and if you will provide advanced CA private key protection. Next we will only discuss CA hardware sizing and the concept of an offline CA; the other topics were discussed in the previous PKI chapters.

CA Hardware sizing Table 16.3 provides some hardware sizing guidelines for a Windows Server 2003 CA. As far as the scalability of the Windows Server 2003 CA is concerned, Microsoft claims it is unlimited. Microsoft tested Windows Server 2003 PKI on a single four-processor, Intel-based computer, issuing more than 35 million certificates.

Table 16.3: CA Installation and Configuration Options

Hardware Parameter	Comment
Processor	Is the most important CA resource. A powerful state-of-the-art CPU is strongly advised. Multiple CPUs will also enhance CA performance.
Memory	Microsoft recommendation is 512 Mb; 256 Mb is a minimum.
Disks	RAID configuration is advisable. Use separate physical disks for CA database and log files. As for the CA database size, each issued certificates takes about 16 Kb, and each archived private key takes about 4 Kb.

Offline CAs To minimize the risk of CA private key compromise, you may want to set up offline CAs. Within a certificate hierarchy, for example, it is advisable to take the nonissuing CAs (root CAs and intermediate CAs) offline. Making a CA an offline CA can include different things:

• Take it off the network.

• Protect it from the rest of the network by putting it behind a firewall or a router.

• Shut down the CA service.

• Shut down the machine hosting the CA.

• Install the CA on a stand-alone Windows server and set it up as a stand-alone CA.

• Remove a CA server’s hard disk and store it in a vault to which only a limited number of people have access.

• Provide strong CA private key protection by storing the CA’s private key on a Hardware Security Module (HSM).

You must bring an offline CA online to issue certificates and CRLs, and every time its certificate must be renewed.

PKI users must also be able to access an offline CA’s CRLs and CA certificate using CDP and AIA certificate pointers. When setting up an offline CA, you must make sure that the CDP and AIA pointers of both the CA certificate and all the certificates it issues refer to an online location. CDP and AIA configuration are explained in more detail later in this chapter.

When the offline CA is not connected to the network, you can use the following procedure to obtain a certificate for the new subordinate CA:

• During the subordinate CA installation, select “save the request to a file.” The MS Certificate Services will inform you that the installation is incomplete. Put the request file (*.req) on a floppy disk and transport the floppy to the offline CA.

• Bring the offline CA online. Open the subordinate CA’s request file from the offline CA, and copy the text starting with “BEGIN NEW CERTIFICATE REQUEST” and ending with “END NEW CERTIFICATE REQUEST.” Paste this text into the “Submit a saved request” page (Advanced certificate request) of the offline CA’s Web enrollment interface. Submit the request and save the newly generated certificate to the floppy disk. In Windows Server 2003 you can also submit a certificate request file to a CA from the CA MMC snap-in: right-click the CA object and select All Tasks\Submit new request... This action will allow you to select the certificate request file from some file system location.

• Transport the floppy to the subordinate CA. Then from the CA MMC snap-in, right-click the CA object and select “Install CA certificate.” The CA certificate will be installed and the subordinate CA service will be started.

CA installation options

During CA installation, you need to think about the following CA-related parameters: the CA role (enterprise or stand-alone, root or subordinate), its keys and certificate properties, the CA naming conventions, the CA X.509 certificate extensions, and the CA’s database specifications. In the following sections we will only cover the topics that were not discussed in earlier chapters.

CA role The very first screen of the CA installation wizard will ask you whether you want to install the CA as a stand-alone or enterprise CA, or root or subordinate CA. These installation options were discussed in detail in Chapters 13 and 14.

CA keys and certificate Next during CA installation, you must choose the CA key length, the Cryptographic Service Provider (CSP), and the hash functions the CA will use for its cryptographic operations (as illustrated in Figure 16.3). This can only be done if you check the “Use custom settings to generate the key pair and CA certificate” CA installation option.

Figure 16.3: CA key and certificate options during CA installation.

When installing a root CA, you can also set the lifetime of its certificate—this can be done from the CA identifying information screen illustrated in Figure 16.4. When installing a subordinate CA, this field says “Determined by parent CA.” In that case the subordinate CA certificate’s lifetime is dependent on a V2 certificate template setting (if the parent CA is an enterprise CA) or the value of registry key (if the parent CA is a stand- alone CA). How to change these settings was explained in Chapter 15.

Figure 16.4 gives an example of how the CA certificate and key lifetime and the CA key length could be defined for different CAs in a PKI hierarchy. Notice that the deeper you go in the certification hierarchy, the shorter the certificate lifetime, key lifetime, and key length become.

Figure 16.4: Certificate lifetime and key length in a typical PKI hierarchy.

A key topic to remember is that the CA is the heart of your security system, and if its private key is compromised, so is the entire PKI. Protect against attacks by choosing the longest key possible—at least 1,024 bits— and by storing the CA private key in a secure place. Secure private key storage was discussed in Chapter 13. See Figure 16.5.

Figure 16.5: CA naming and certificate lifetime options.

CA naming conventions The CA installation wizard prompts you for the CA’s identification information: the CA common name and distinguished name suffix. Make sure you agreed on the naming conventions before you start the installation. The naming choices made during installation not only affect the CA, but they are also reflected in the CA’s Common Name that is stored in AD and in every certificate the CA issues.

Besides the CA’s common name, Windows PKI also generates a sanitized CA name. This is the short CA name not including any non-ASCII characters and ASCII punctuation characters. It is needed for file names, key container names, and AD object names that cannot handle a CA name including special characters. Sanitized names are limited to 64 characters: If a CA’s name is longer than 64, it is truncated and appended with a hash that is calculated over the truncated part. This name is also referred to as the CATruncatedName in MS documentation.

To retrieve a CA’s sanitized name, run certutil with the -cainfo switch. As Figure 16.6 shows, this command also brings up other interesting CA configuration information.

Figure 16.6: Using certutil to check the CA’s sanitized names.

Once you installed a CA, you cannot change the CA server’s name or change its Windows domain membership. To change the server name or domain membership after installation, you have to uninstall the Certification Authority, change the server’s name or domain membership, and then reinstall the Certification Authority. The CA installation program warns you for this problem, as illustrated in Figure 16.7.

Figure 16.7: A installation warning.

CA database The CA installation wizard allows you to specify the location of the CA database and its log files (as illustrated in Figure 16.8). You will also be asked whether you want to store the CA’s configuration information on the file system. When you check this option, the CA installation program will copy the CA’s naming information and the CA’s certificate to the file system. The configuration directory is automatically shared as certconfig.

Figure 16.8: CA database installation options.

The Windows CA database is a JET Blue database. It has been designed to support an unlimited amount of certificates and is using the same database engine—the Extensible Storage Engine (esent.dll)—that is used in Exchange and the Active Directory. Just as for any other JET database, it is a best practice to split the database and its log files across different physical disk drives. By default, all CA database files are located in the certlog subdi- rectory of the system directory. To find out the location of your CA database files, type certutil -databaselocations at the command prompt or go to the Storage tab in the CA properties—available from the CA MMC snap-in. The CA database files are listed in Table 16.4.

Table 16.4: Windows Certificate Server Database Files

Database File	Goal
<CA name>.edb	The CA store
edb.log	The transaction log file for the CA store
res1.log	Reservation log file to store transactions if disk space is exhausted
res2.log	Reservation log file to store transactions if disk space is exhausted
edb.chk	Database checkpoint file
tmp.edb	Temporary CA store

The CA database layout used in Windows Server 2003 PKI is different from the layout that was used in previous releases. When upgrading from Windows 2000 to Windows Server 2003, the database format is automatically converted. You can look at the layout of the CA database by typing certutil -schema at the command prompt.

Other CA installation options: During CA installation or certificate renewal, you can also add several customized X.509 extensions and properties to the CA certificate:

• CRL Distribution Points (CDP) extensions

• Cross-certificate distribution point extensions

• Authority Information Access (AIA) extensions

• Enhanced Key Usage extensions

• Basic constraint extensions

• Issuance policy constraint extensions

• Application policy constraint extensions

• Name constraint extensions

• CA certificate renewal settings

• CRL and delta CRL validity settings

To set these certificate extensions and properties, you must create a policy statement file called capolicy.inf and store it in the Windows system directory before the installation of the CA. Chapter 14 contains a sample capolicy.inf file.

CA configuration options

Once a CA is installed, you must configure it. In this phase you must consider revocation settings, Authority Information Access (AIA) settings, policy and exit module properties, certificate template settings, delegation of administrative control, identification options, key recovery agent settings, and CA server hardening. Again, in the following sections we will not come back to the topics that were discussed extensively in the previous chapters: CA identification options, enrollment interfaces, certificate templates, and key recovery agent settings.

Revocation settings In a Windows PKI design, you must think about the following revocation-related parameters: the CRL and delta CRL lifetime and publication interval, and the number and type of CRL Distribution Points (CDPs).

All of these parameters are CA-dependent and can be configured once for each CA. If your PKI-enabled applications have different CRL or delta CRL requirements, you can install multiple CAs. For example, you can install one CA with a short publication schedule used for an application with high security requirements and another one with a longer schedule used for an application with lower security requirements.

CRL and Delta CRL Lifetime and Publication Interval The CRL and delta CRL publication intervals can be set from the properties of the Revoked Certificates container in the CA MMC snap-in or from the registry (as outlined next). In the CA MMC snap-in, automatic CRL publication cannot be disabled—this can be done for delta CRLs. Automatic CRL publication can be disabled from the registry by setting the CRLPeriod- Units parameter to 0. For delta CRLs, you must set the CRLDeltaPeriod- Units parameter to 0. When you disable automatic CRL or delta CRL publication, you must fall back to manual publication (which was explained in Chapter 15).

It is a best practice to disable delta CRL publication and set a long CRL publication interval for offline CAs. In that case, the administrative over- head or publishing CRLs and delta CRLs is not outweighed by the number of revoked certificates.

If a CA cannot publish its CRL on time, the revocation information is not updated and the old CRL will expire. Most PKI-enabled applications consider certificates invalid if the CRL has expired or is unavailable. That is why a CRL must at least be valid for the amount of time it takes for a CA recovery in case of a hardware or software failure. A 1-hour CRL publication interval is very likely not enough to perform a complete CA hardware and software restoration. This also explains why you must bring an offline CA online at regular intervals for CRL publication. See also the following sidebar on “Publishing the CRL of an Offline CA.”

In Windows PKI, the CRL lifetime and publication interval are, although closely related, not the same. The CRL lifetime is derived from the publication interval and is by default 10% longer than the publication interval. This allows Windows PKI to deal with the replication delay of CRLs that are published in AD. The CRL overlap can be set in the registry of a CA server using the CRLOverlapPeriod, CRLOverlapUnits, and Clockskewminutes parameters. These parameters are located in the HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\ registry container.

The following example illustrates the use of the parameters. Imagine you must deal with an AD replication delay of 4 hours. To deal with this delay, you can set the CRL overlap period to 5 hours. The following are the registry settings you would use in this example. They result in a CRL lifetime of 1 week, 5 hours, and 10 minutes. This is the sum of the CRLPeriod, CRLOverlapPeriod, and Clockskewminutes parameters. The CRL will be published every week, as specified in the CRLPeriod and CRLPeriodUnits parameters.

CRLPeriod              REG_SZ = Weeks CRLPeriodUnits         REG_DWORD = 1 CRLOverlapPeriod       REG_SZ = Hours CRLOverlapUnits        REG_DWORD = 5 ClockSkewMinutes       REG_DWORD = a CRLDeltaPeriod         REG_SZ = Days CRLDeltaPeriodUnits    REG_DWORD = 1 CRLDeltaOverlapPeriod  REG_SZ = Minutes CRLDeltaOverlapUnits   REG_DWORD = 0

Setting the CRLOverlapUnits parameter in the registry to 0 activates the default algorithm—CRL lifetime is 10% longer than the publication inter- val—for the calculation of the CRL overlap. The same is true for delta CRLs. In this example, the default algorithm has been activated for delta CRLs.

CRL Distribution Points Windows PKI supports three CDP types: LDAP, file system, and HTTP-based CDPs. CDPs are used for both CRL and delta CRL distribution. For CRL downloads within your AD infrastructure, LDAP CDPs are the best choice. If you share PKI-enabled applications and certificates with external entities that do not have access to your AD, or with entities that are not using a Windows operating system, consider alternative CDP locations such as Web pages. In that case you use HTTP-based CDPs. Make sure that these CDPs do not reveal internal namespaces to the external entities.

Publishing the CRL of an Offline CA The following is a procedure for publishing the CRL of an offline CA:

• Bring the offline CA online.

• Start the CA MMC snap-in and publish the CRL to the local file system.

• Copy the CRL to a floppy disk or another removable medium.

• Shut down the CA.

• Publish the CRL at the different CDPs.

For file system and HTTP CDPs, copy the CRL from the floppy disk or other removable medium to the appropriate file system location.

For LDAP CDPs, copy the CRL to the file system, then use certutil together with the -dspublish switch to publish the CRL to AD.

To ensure revocation information redundancy and to make CRLs available through more than one location, it is a best practice to define multiple CDP types (LDAP, HTTP, and so forth). An AD-rooted LDAP CDP automatically provides redundancy (but only on the AD level) because the CRL is replicated in the AD to all domain controllers in the forest. Also, an LDAP CDP refers to a location in the AD configuration naming context, which is available on all AD DCs. To provide the same level of redundancy with HTTP CDPs, add a virtual Web server name pointing to several physical Web servers to the CDP.

Root CA certificates must have an empty CDP. The CDP point is always defined by the certificate issuer (because this is also the entity that is issuing the CRL). Because the root’s certificate issuer is the root CA itself, it does not make sense to include a CDP in the root CA certificate.

The CDPs of an offline CA must point to a location different from the server hosting the offline CA. Otherwise, users would never be able to download an offline CA’s CRLs.

To make these CDP changes to a root CA’s and an offline CA’s certificate, you must define the CDP settings in a capolicy.inf configuration file and make this file available on the CA machine during the CA installation. The capolicy.inf file and how to use it were explained in Chapter 14.

The CDPs of the certificates a CA issues are configured in the Extensions tab of the CA properties dialog box, which is available from the CA MMC snap-in. You can also change these settings from the command line using the following certutil commands:

certutil -setreg CA\CRLPublicationURLs “<list of CDPs>”

To define CDPs, you can use text string variables that are formatted using the replaceable parameter syntax. Microsoft added these variables to make the life of a CA administrator easier. The variables are also referred to as replacement tokens and are defined in Table 16.5.

Table : Table 16.5 Replaceable Parameter Syntax

Text String Variable	Number Variable	Value
<ServerDNSName>	%1	DNS name of CA
<ServerShortName>	%2	NetBIOS name of CA
<CaName>	%3	Name of CA
<CertificateName>	%4	Certificate Name
<ConfigurationContainer>	%6	Location of AD configuration container
<CaTruncatedName>	%7	Sanitized name of CA
<CRLNameSuffix>	%8	CRL base file name and renewal extension
<DeltaCRLAllowed>	%9	Substitutes Delta CRL name suffix for CRL name suffix
<CDPObjectClass>	%10	Used in LDAP URLs for CDP extension
<CAObjectClass>	%11	Used in LDAP URLs for AIA extension

In Windows Server 2003 PKI, Microsoft offers a new interface (illustrated in Figure 16.9) that facilitates the creation of CDPs using the replacement tokens. In the registry, these tokens are translated into number variables. The number variables must be used when you are using the replacement tokens in a capolicy.inf configuration file or in a batch file. The same tokens can be used for AIA and cross-certificate distribution point definition.

Figure 16.9: Defining CDPs using the replaceable parameter syntax.

If an offline CA is not connected to the network and you provide an AD-rooted CDP, you must manually change the value of the %6 replacement token. The %6 replacement token holds the location of the AD configuration container. You can do so by typing:

certutil.exe –setreg ca\DSConfigDN <path to AD  configuration naming context> 

For example:

certutil.exe –setreg ca\ DSConfigDN CN=Configuration,DC=mydomain,DC=com

The following are examples of an LDAP, file system, and HTTP CDP as they are defined in the CA properties (using the replaceable parameter syntax) and how these will show up in the CDP certificate extension of a certificate issued by a CA named ResearchCA located on a machine called myserver. The HTTP CDP is published on a Web server called mywebserver.mydomain.net:

Ldap:/// CN:<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName> ,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer>,<CDPObject Class>

will show up as:

URL=ldap:/// CN=ResearchCA,CN=Myserver,CN=CDP,CN=Public%20Key%20Services, CN=Services,CN=Configuration,DC=mydomain,DC=net?certificate RevocationList?base?objectClass=cRLDistributionPoint File://\\<ServerDNSName>\CertEnroll\ <CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

will show up as:

URL=file://\\mywebserver.mydomain.net/CertEnroll/ ResearchCA.crl Http://<ServerDNSName>/CertEnroll/ <CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

will show up as:

URL=http://mywebserver.mydomain.net/CertEnroll/ ResearchCA.crl

Other revocation-related settings By default, a Windows CA automatically removes expired certificates from a CRL. In some PKA scenarios, it is desirable to maintain expired certificates on the CRL. To do so, you can use the following certutil command:

certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

By default, a Windows CA maintains expired CRLs in the CA database and in the AD. This is a best practice for long-term validation and auditing purposes. You can remove expired CRLs from the CA database by using the certutil command listed below. This only applies to the very last CRL the CA publishes for a given CA certificate.

certutil –setreg ca\CRLFlags + CRLF_DELETE_EXPIRED_CRLS

Authority information access settings A certificate’s Authority Information Access (AIA) fields hold pointers to storage locations for CA certificates. As explained in Chapter 15, they play an important role in the certificate validation process.

For the certificates a CA issues, the AIA settings are—like the CDP settings—configured from the Extensions tab in the CA properties, available from the CA MMC snap-in (illustrated in Figure 16.10). You can also use the following certutil command line:

certutil -setreg CA\CACertPublicationURLs “<list of AIAs>”

Figure 16.10: Configuring AIAs from the CA properties.

As for CDPs, you can specify the AIA settings in a CA’s proper certificate in the capolicy.inf file; how to do this was explained in Chapter 14. In any case, when configuring AIA settings, you can also use the replaceable parameter syntax and the replacement tokens as they were defined earlier.

As for CDPs, the AIAs of the certificates an offline CA issues must point to a location different from the server hosting the offline CA. Otherwise, users would never be able to download an offline CA’s certificate. If the offline CA is not connected to the network and you provide an AD-rooted AIA, make sure you change the value of the %6 replacement token (location of the AD configuration container) by typing:

certutil.exe –setreg ca\DSConfigDN <path to AD  configuration naming context>

For example:

certutil.exe –setreg ca\ DSConfigDN CN=Configuration,DC=mydomain,DC=com

An AIA storage location can hold more than a single CA certificate. An LDAP-rooted AIA storage location can be used to download all CA certificates available from the AIA at once. This is because in the AD, AIA CA certificates are stored in a multivalued attribute called caCertificate of a CA object. When dealing with an HTTP-rooted or file system–rooted AIA storage location, only a single CA certificate can be downloaded at once. This is because HTTP and file system AIA pointers must point to individual CA certificates—they always end in a .cer or .crt certificate extension.

Other certificate characteristics The bulk of the certificate characteristics (with the exception of the CDP and AIA extension) can be configured from the Certificate Templates MMC snap-in. Remember that this is only true for version 2 certificate templates. Certificate templates and their properties were covered in Chapter 13.

Two very important certificate characteristics are the certificate lifetime and renewal period. When planning for these characteristics, you must consider the following:

• The trust your organization has in the certificate subjects: If you are issuing certificates to users of your corporate extranet, the certificate lifetime should be shorter than when you are issuing certificates to users of your corporate intranet. Generally, the level of trust that an organization has in its internal users is higher than the level of trust it has in the external users of the corporate IT infrastructure.

• Certificate lifetime impacts the number of certificate renewal requests that are sent across your network. In environments with limited network bandwidth (e.g., when users in a remote site are connecting to a CA across a slow WAN), this can be a reason to lengthen certificates’ lifetimes.

CA administrative delegation and role separation Windows Server 2003 PKI provides a role-based administration model. Also, it allows for role and task separation between the different CA administrators. As will be explained next, this role-based model piggybacks on the Windows access control model (permissions and user rights). This new administration model is in line with the role definitions defined in version 1.0 of Certificate Issuing and Management Components (CIMC) Family of Protection Profiles. The latter can be downloaded from http://csrc.nist.gov/pki/documents/CIMC_PP_20011031.pdf.

To assign a PKI role to a user or group, you must assign the role’s corresponding security permissions or user rights to the user or group. Permissions can be set from the Security tab in the properties of the CA object (accessible from the CA MMC snap-in), as illustrated in Figure 16.11.^{[1 ]}User rights can be set from the GPO MMC snap-in. Table 16.6 shows the administrative roles and their associated permissions/user rights available in Windows Server 2003 PKI. Table 16.7 shows the tasks associated with every administrative role.

Figure 16.11: Setting CA object permissions.

Table 16.6: Windows Server 2003 PKI Administrative Roles

Administrative Role (CIMC Equivalent)	Associated Permissions—User Rights	Meaning
CA Administrator	Manage CA permission	Configure and maintain the CA. This includes the ability to assign all other CA roles and renew the CA certificate.
Certificate Manager (Officer)	Issue and manage Certificates CA permission	Approve certificate enrollment and revocation requests.
Backup Operator (Operator)	Back up files and directories and restore files and directories user rights	Perform system backup and recovery.
Auditor (Auditor)	Manage auditing and security log user right	Configure, view, and maintain audit logs.
Enrollees	Request Certificates CA permission	Enrollees are clients who are authorized to request certificates from the CA.
Read	Read CA permission	Allows an entity to read records from the CA database.

Table 16.7: Windows Server 2003 PKI Administrative Roles and Associated Tasks

Activity	Local Admin	CA Admin	Cert Manager	Backup Operator	Auditor
Install CA	X	—	—	—	—
Configure policy and exit module	—	X	—	—	—
Stop and start the Certificate Services service	—	X	—	X (only stop)	—
Configure extensions	—	X	—	—	—
Configure roles	—	X	—	—	—
Renew CA keys and certificates	X	—	—	—	—
Define key recovery agents	—	X	—	—	—
Configure Certificate Managers restrictions	—	X	—	—	—
Delete single row in database	—	X	—	—	—
Delete multiple rows in database	X	—	—	—	—
Enable role separation	X	—	—	—	—
Issue and approve certificates	—	—	X	—	—
Deny certificates	—	—	X	—	—
Revoke certificates	—	—	X	—	—
Reactivate certificates placed on hold	—	—	X	—	—
Enable, publish, or configure CRL schedule	—	X	—	—	—
Recover archived key*	—	—	X	—	—
Configure audit parameters	—	—	—	—	X
Audit logs	—	—	—	—	X
Back up system	—	—	—	X	—
Restore system	—	—	—	X	—
Read CA database	X	X	X	—	X
Read CA configuration information	X	X	X	X	X

* Extracting the recovery blob from the CA database requires certificate manager privileges. Decrypting the blob and extracting the private key require a Key Recovery Agent (KRA) certificate; see also Chapter 15.

On a default Windows Server 2003 CA installation, the CA roles are assigned and modified by local administrators on a stand-alone machine or Enterprise Admins and Domain Admins when the CA is part of a domain.

CA Administrators have the Manage CA and Issue and Manage Certificates permissions on the CA object. Local administrators, Enterprise Admins, and Domain Admins are CA Administrators by default on an Enterprise CA. Only local administrators are CA Administrators by default on a stand-alone CA. If the stand-alone CA is joined to an AD domain, the Domain Admins are also CA Administrators.

The local administrator will always have full control of the CA system and cannot be blocked from taking control of the CA. Local administrator privileges are also required for tasks like CA key and certificate renewal, enabling role separation, and so forth.

Certificate Managers are the accounts that have been assigned the Issue and Manage Certificates permission in the security properties of the CA object. Certificate Manager roles can be fine-tuned from the CA MMC snap-in: You can restrict which users and/or groups’ certificates that a Certificate Manager group can manage. To do so, open the properties of the CA object, and then go to the Certificate Managers Restrictions tab (as illustrated in Figure 16.12).

Figure 16.12: Assigning certificate managers restrictions.

The Backup Operator role is based on the system backup user right. A CA Backup Operator has the ability to stop the CA service but not start it. The Auditor role is based on the system audit user right. By default, the local system administrator has these user rights.

The Enrollee role is based on the Request Certificates permission on the CA object. The Read role is based on the Read permission on the CA object. See Table 16.7

Windows Server 2003 PKI also allows for strict role separation between the different administrative roles. If role separation is enabled, a user can only be assigned to a single role. If a user is assigned to multiple roles and attempts to perform a CA administrative operation, the operation will be denied. To enable role separation, type the following commands at the command line:

certutil -setreg ca\RoleSeparationEnabled 1net stop certsvcnet start certsvc

To disable role separation, type the following:

certutil -delreg ca\RoleSeparationEnablednet stop certsvcnet start certsvc

To see whether role separation is enabled, type the following:

certutil -getreg ca\RoleSeparationEnabled

CA server hardening A CA’s private key is the most critical element of PKI security. If a root or intermediate CA’s private key is compromised, the entire or part of your PKI-trust infrastructure falls down. The security level provided for a CA’s private key will also have an important impact on the amount of trust people have in the CA. This is why it is so important to store the CA’s private key securely, to keep root and intermediate CAs offline, and to harden your CA server by boosting its physical, logical, communications, and organizational security.

• Physical security: Install Certificate Servers on computers that are located in secure areas with physical access control and adequate protection against fire, power loss, and other disasters.

• Logical security: In a Windows Server 2003 environment, logical security depends on the quality of the operating system’s authentication, access control, and auditing system.

• You can provide high-quality authentication by equipping all servers with smart-card readers, which provide two-factor authentication.

• You can implement strict access control settings on all of the CA server’s resources. You must lock down the server wherever possible and not install any unneeded services or software components. A good resource for Windows Server 2003 hardening is the Windows Server 2003 Security Guide available from the Microsoft Web site.

• You can use the built-in Windows and CA auditing system and the Security Configuration and Analysis (SCA) tool to audit the security- and PKI-related events on Windows Server 2003 machines.

• Communications security: To provide communications security for the CAs (issuing CAs or other online CAs) connected to your production network, you can install them on a separate subnet or behind a dedicated firewall or router that filters all non-PKI related traffic.

• Organizational security: Make the CA administrators and operators aware of the important security role of the CA. Convince them that this is not an ordinary file and print server but a server that is used to secure the rest of your corporate IT environment.

CA fault tolerance

Neither Windows 2000 PKI nor Windows Server 2003 PKI supports CA service or database clustering. Also, a Windows 2000 or Windows Server 2003 machine can only host a single CA instance.

Certificate enrollment fault tolerance is provided when using multiple enterprise CAs in an AD environment. AD-enabled PKI clients can query the AD to find out about the location of an enterprise CA and can contact another enterprise CA when one is not available.

Revocation checking fault tolerance can be provided by making sure that you can always—independent of the CA’s availability—issue a new CRL and make it available to your PKA and PKI clients. In Windows PKI, this is possible thanks to a feature known as CRL resigning.

CRL resigning allows you to issue a new CRL using the old CRL provided you have access to a copy of the CA’s private key. A CA’s private key can be exported using the Certification Authority Backup Wizard, which can be accessed by right-clicking the CA object in the CA MMC snap-in and then selecting All Tasks\Back up CA. In the wizard, make sure that you select the “Private key and CA certificate” option (as illustrated in Figure 16.13). The wizard will save the exported private key and certificate in a PKCS#12-formatted file (*.p12). The old CRL can always be retrieved from a CDP. To resign an old CRL, use the following certutil command:

certutil -sign <old CRL name> <resigned CRL name>

Figure 16.13: Exporting a CA’s private key and certificate.

Defining public key policy settings (GPO)

Windows Server 2003 GPO objects include the following PKI-related entries: Encrypting File System, Automatic Certificate Request Settings, Trusted Root Certification Authorities, Enterprise Trust, and Autoenrollment Settings. They are located in the Windows Settings\Security Settings\ Public Key Policies GPO container.

The Encrypting File System GPO container is used to define accounts that have the ability to recover encrypted EFS data. The Automatic Certificate Request container is used to define machine certificate autoenrollment settings. The Trusted Root Certification Authorities container is used to distribute trusted root CA certificates to clients. The Enterprise Trust container is used to define Certificate Trust Lists (CTLs). The Autoenrollment object is used to define user autoenrollment settings.

Table 16.8 shows on which GPO level (domain, site, OU, or local) and for which GPO portion (user or computer) the PKI-related GPO settings are available. GPO settings that are defined on the machine level are shared with all users logging on to that machine and all services running on it.

Table 16.8: PKI-Related GPO Settings

	GPO Level	User GPO Portion	Machine GPO Portion
Encrypting File System	Domain Site OU Local	— — — —	X X X X
Automatic Certificate Request	Domain Site OU Local	— — — —	X X X —
Trusted Root CAs	Domain Site OU Local	— — — —	X X X —
Enterprise Trust	Domain Site OU Local	X X X —	X X X —
Autoenrollment	Domain Site OU Local	X X X —	X X X —

^{[1 ]}The Security tab shows a simplified view of the ACL editor; there is no advanced view (which was available for a Windows 2000 CA).