Running a Windows 2000 PKI Project

This paper is part of a series of white papers known as " The Smart Card Deployment Cookbook."

On This Page

Introduction
Assessing the Organizational Needs for a PKI
Designing, Planning, and Implementing a Windows 2000 PKI
Parameters Set Before or During CA Installation
Parameters Set During CA configuration
Automated Certificate Requests
Trusted Root Certification Authorities
Enterprise Trust
Encrypted Data Recovery Agents

Introduction

Just like any other IT project, a Microsoft Windows 2000 Public Key Infrastructure (PKI) project can be subdivided into four key phases: assessment, design, implementation, and management.

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

The design phase deals with the technological design of the PKI solution, in addition to some non-technological design topics, such as the creation of a Certificate Practice Statements (CPS).

The implementation phase takes care of the deployment of the PKI solution, its integration with the existing IT environment and, prior to the rollout, the development of customized PKI applications or modules.

After the PKI is installed and deployed across your enterprise, you need to manage and maintain it. In the management phase, you deal with the support model for the PKI (Helpdesk, Emergency Response, and so on), administrator and end-user training, and the management of the PKI components.

Assessing the Organizational Needs for a PKI

During an assessment for a PKI project, you analyze your organization's actual and future security needs. Prior to the assessment, you may need to gather some extra information by organizing a security audit or a penetration test.

The paragraphs that follow discuss three key areas that you should focus on during the assessment phase: the analysis of business requirements, the analysis of applications that benefit from PKI-based security, and the decision on whether to insource or outsource.

Analyzing Business Requirements

The deployment of a PKI in a corporate environment is driven by core business needs, such as advanced security requirements for information storage and network communication. The business reason behind a corporate PKI deployment has an impact on every step of your PKI planning and design. For example, the size of the investment that a company makes in a PKI depends on the criticality of the business problem it wants to resolve, or the importance of the business processes it wants to improve by installing a PKI will be prepared to spend much more money on a PKI solution.

Some business security requirements do not need a certificate-based security solution and can be resolved with simpler arrangements. Because not every certificate-based solution requires rolling out an enterprise PKI, companies often decide to outsource the job or simply buy a limited set of certificates from a commercial certification authority (CA).

Your organization might require some extra specifications on the level of:

• Availability. What sort 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. Does the PKI have to be scalable? Will it need to cope with rapid or enormous growth of the number of required certificates? Must planning take into account possible future mergers? Will many more PKI-based applications be deployed in the near future?

• Performance. Public key cryptography operations place load and performance demands on client and server systems. Is it acceptable? Should hardware be upgraded? Should you buy and install hardware that will speed up PKI functions?

• Cost. PKI products are available with different features and in different price classes.

Analyzing the Applications That Benefit from PKI-Based Security

Many Windows 2000 applications (built-in and otherwise) can take advantage of a PKI to provide strong security: networking systems, virtual private network (VPN) systems, Enterprise Resource Planning (ERP) software, document signing, and smart card–based applications. The types of certificates that will be needed and the entities to which certificates will be issued (computers or users) depend on the applications you want to support in your corporate environment.

You can build these types of Windows 2000 applications on top of a Windows 2000 PKI:

• Secure Web. In a corporate intranet or extranet environment, you can use certificates for strong authentication, which uses the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols to provide client authentication, server authentication, and data confidentiality. Each authenticated entity requires a certificate. If you host Web sites and directories on Internet Information Services (IIS), you can map a certificate-based account to a Microsoft Windows NT account so that users who authenticate through certificates are treated just like any other user in post-authentication processes, such as access control. On the IIS level, you can define one-to-one mapping or a many-to-one mapping, which maps certificates of the same type (for example, issued by the same CA) to the same Windows NT account. Mapping definitions are contained in the IIS metabase or in Active Directory™. A new feature of IIS 5.0 running on top of Windows 2000 is the possibility to point a Web server to the Active Directory database to check for certificate mappings.

• Secure mail. Signing and sealing electronic mail messages by using Secure/Multipurpose Internet Mail Extensions (S/MIME) is also based on public key cryptography and certificates. Signing uses the sender's private key; encryption uses the recipient's public key. Microsoft Exchange, Microsoft Outlook, and Microsoft Outlook Express all can provide secure mail. Most secure mail applications use a dual-key pair system to provide non-repudiation of signed mail messages and recovery of encrypted mail messages.

• File system encryption. Windows 2000 comes with the Encrypting File System (EFS) extension to the NTFS version 5 file system. It provides file-system-level encryption. A built-in feature provides recovery of encrypted data by a person other than the one who originally encrypted the data. Because it performs encryption and decryption transparently, it is also easy to use. You can use Windows 2000 to encrypt files or folders through a graphical user interface (GUI) or a command-prompt interface.

• Code signing. This helps protect against downloads of altered (hacker) code from Web sites. Using a private key, the original code developer signs the code, and the user downloading a piece of it can use the developer's public key to verify the code's origin. The Microsoft code-signing technology is known as Microsoft Authenticode.

• Smart card logon. This provides strong two-factor authentication (based on knowledge of a personal identification number [PIN] code and possession of a smart card) in a Windows 2000 domain environment. Logging on to Windows NT version 4.0 by using a user ID and password provided one-factor authentication (based on knowledge only). Smart card logon in Windows 2000 is implemented as an extension to the Kerberos protocol; it is called PKINIT because it uses public key cryptography only for initial authentication. The smart card logon process replaces all occurrences of the user's password with the user's public key credentials. Active Directory contains a mapping between a user's certificate and a Windows 2000 account. There is a security gain in using PINs instead of using passwords: unlike passwords, PINs are never sent over the network, and thus greatly reduce the possibility of security attacks.

• Secure Web and secure mail using Fortezza crypto cards (United States only). The Fortezza crypto card standard is a smart card standard developed by the U.S. National Security Agency (NSA). A Fortezza crypto card can be used like any other smart card for secure storage of public key credentials. Fortezza also enables secure Web and secure mail applications that use public key technology.

• Virtual private networking. Windows 2000 supports the Internet Protocol security (IPSec) tunneling protocol, which can use certificates to authenticate between two IPSec tunnel endpoints. This is an ideal solution for strong authentication between two tunnel endpoints that are part of different domains that do not have a trust relationship set up. Untrusted domains cannot rely on the standard Windows 2000 authentication protocols, such as Kerberos and NTLM.

• Remote access authentication. Windows 2000 remote access supports the Extensible Authentication Protocol (EAP) authentication protocol, which uses (among other methods) Transport Layer Security authentication. The IETF successor to SSL, TLS uses certificates for client and server authentication.

• Authentication of Simple Mail Transfer Protocol (SMTP) site connections. You can connect Windows 2000 sites with asynchronous SMTP connections, in which case the bridgehead domain controllers at both ends authenticate one another by using certificates.

• Any custom PKI-enabled application that uses CryptoAPI version 2. The Windows 2000 CryptoAPI that is deals with PKI-related operations is fully documented in the Windows 2000 software development kit (SDK) and can be used to build many other PKI-enabled applications on top of Windows 2000.

Not all of these applications require the presence of a corporate PKI or CA infrastructure. For example, you can use EFS on laptops, even if no CA is present.

Deciding Whether to Insource or Outsource

You have three choices to implement and manage an enterprise PKI: insource, outsource, or a hybrid approach.

Insourced solutions are solutions that your organization installs, implements, administers, and maintains. Your IT department must take the lead in implementing all related PKI technologies: CA hardware, the CA database, PKI directories, and the communication links between all participating entities. Your organization can create its own liability rules and security policies, and can decide how to implement, administer, and maintain the PKI. It also has complete control over who gets a certificate.

Outsourced solutions give most of these responsibilities to another company. The degree of outsourcing can range from small (generating some server certificates) to large (outsourcing multiple CA services that are dedicated to your organization). An important consideration with outsourcing is that you must select a company that you can trust with sensitive security issues. However, outsourcing is often necessary for smaller companies or for those without the resources required to install and maintain a PKI.

Hybrid solutions combine insourcing and outsourcing: Your organization maintains part of the CAs in the hierarchy, while another organization maintains others. This model is probably the best choice for most companies. For example, a company might have different security needs for different applications. In this case, applications with high security needs can be managed and implemented by the company itself; the implementation and management of applications with weaker security needs can be outsourced.

The topics outlined in the following table can help you choose between an insourced, outsourced, or hybrid approach.

Insourcing	Outsourcing
Pros · More control over certificate policy definition and management, certificate and key management, issuance, archiving, and recovery · Tighter integration options: integration with enterprise directory and in-house applications · Certificate policy control can encourage stronger trust relationships with partners	Pros · Leverage on expertise of PKI leaders · Less effort for planning, design, administration, and maintenance · Can be more cost effective for a small enterprise; the business with the external partner can be extended as need for PKI-enabled applications grows · Can be operational in a short period of time · Requires less in-house expertise
Cons · More costly to plan, design, administer, and maintain, particularly for a small enterprise · More time-consuming to plan, design, and deploy · Requires more in-house expertise · Integration and deployment can be complicated	Cons · Fewer policy control and enforcement capabilities · Fewer integration options · Can be more costly for a large enterprise

Designing, Planning, and Implementing a Windows 2000 PKI

This section focuses on the different steps you need to consider when designing, planning, and implementing a Windows 2000 PKI.

Defining Your Topology

When designing your Windows 2000 PKI topology, you need to consider possible future extensions of your organization, and then make decisions about the following topics:

• Decide on the number of CAs you want. Your organization may require multiple CAs for reasons of scalability, business, geography, CA policy, or politics.

• Choose a trust model. The primary trust model of Windows 2000 is hierarchical. Windows also supports the distributed and browser trust models. When designing a hierarchical trust model, you need to decide on the number of hierarchical levels you will need and on what those levels will be based (such as geography, business organization, and so on). In a distributed model, you must also decide on the number of hierarchies that your organization needs.

• In PKI projects of limited scope, you might choose a stand-alone CA solution. Given the growing interest in PKI, however, this is not a good idea. You should always consider the possibility of linking your CA trust model with others and provide ways to scale your CA trust model.

• Map the trust model to the Windows 2000 domain and site model. Because the trust model established between CAs is totally independent of the trust model existing between Windows 2000 domains, one CA can span multiple domains and a domain can contain multiple CAs.

With Windows 2000, it is good practice to increase availability by installing one Windows 2000 domain controller or global catalog server in each site. In a PKI environment, the availability of the CA services is much less important than the availability of the directory that holds the certificates and the certificate revocation lists (CRLs). If you integrate the certificate server with Active Directory, the certificates and CRLs are automatically published to the configuration container of the active directory and then replicated throughout the forest.

In some environments, such as the one illustrated below, it might be a good idea to have one CA per group of sites. The example below illustrates a multiple hub-and-spoke site model; in this case, it's a good idea to deploy one CA per core site, simply for availability and performance reasons.

• Define relationships with external CAs or PKIs. When the PKI topology design is done, you should have a clear view of the trust relationships between your organization's CAs. To provide PKI interoperability between different CA domains, Windows uses a special type of browser trust, based on the concept of Certificate Trust Lists (CTLs). You also need to decide on how you will link your PKI domain with other external PKI domains and whether there is a need to do this. If you are planning to use CTLs, think about the following elements: Which CA certificates will be contained in the CTLs? Will the trust be unidirectional or bidirectional? What will be the limitations on the CTLs—which certificate types will they support? What will their lifetime be? Remember that setting up a link between different PKIs requires more than just a technology solution. You will also need to think about policy agreements.

Specifications of the Individual CAs

Certification authorities are your key PKI components, so you need to spend enough time and effort to create detailed designs of the individual CAs. The sections that follow discuss the parameters that you set for the installation and configuration phases of a CA.

Parameters Set Before or During CA Installation

Before or during the installation of a CA, you need to think about its architecture, its role, the specification of its keys and certificates, its naming conventions, the inclusion of a pointer to the CPS or to a short notice text in the certificates, and its database specifications.

CA Architecture Design

When setting the CA architecture, you must decide factors such as whether your organization needs CAs with a customized exit or a policy module.

CA Role

You can choose among the following roles for the CA:

• Stand-alone or enterprise CA

• Root or subordinate CA

• Intermediate or issuing CA (if it is a subordinate CA)

• Offline CA (if it is a root or intermediate CA)

Within a certificate hierarchy, it is advisable to take the non-issuing CAs (root CAs and intermediate CAs) offline. This minimizes the risk of the CA private key being compromised.

Taking a CA offline can mean different things. You can:

• Take it off the network

• Shut down the CA service

• Shut down the CA machine

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

Installing an offline CA on a member server that is a member of a domain can lead to secure channel problems when you bring the CA online again after a long offline period (by default, the machine account password is changed every seven days). Installing it as an enterprise CA would lead to Active Directory updating problems, when you decide to disconnect the server from the network.

A best practice for an offline CA, is to respect all of the above.

If an offline CA needs to issue new certificates (for example, for a new subordinate CA) or generate a new CRL, you need to bring it online. If it is not connected to the network, you can use the following procedure to obtain a certificate for the new subordinate CA:

1. During the installation of the subordinate CA, click Save the request to a file. The Certificate Services feature informs you that the installation is incomplete.

2. Put the request file (*.req) on a floppy disk and transport the disk to the offline CA.

3. Open the subordinate CA's request file from the offline CA, and copy the text between the Begin New Certificate Request and End New Certificate Request lines.

4. Paste this text into the Submit a saved request window (Advanced certificate request) of the offline CA's Web enrollment interface. Submit the request, and then save the newly generated certificate to the floppy disk.

5. Transport the disk to the subordinate CA. From the CA Microsoft Management Console (MMC) snap-in, right-click the CA object, and then click Install CA certificate. The CA certificate is installed and the subordinate CA service starts.

Even though a CA is offline, the users of the certificates it issued must be able to access its CRLs and CA certificate. Even though a CA is offline, you can publish its certificate and CRL in Active Directory: Export them from the offline CA to a floppy disk; bring the disk to a machine that has access to Active Directory, and publish them in Active Directory by using the Dsstore resource kit tool. You must also change the CRL distribution point and authority information access parameters in the CA's certificate (by using the Capolicy.inf file), and in the CA's policy module; the last change should be made before any certificate is issued. In addition, even though a CA is offline, it must be brought online at regular intervals to generate a new CRL (it does not matter if the CRL is empty, as long as it is available). Otherwise, the certificates that have been issued will not be valid after the existing CRL has expired.

CA Keys and Certificates

When you set up a CA, you must choose the key length, the cryptographic service provider (CSP), and the hash functions that the CA will use for cryptographic operations. When installing a root CA, you can also set the lifetime of its certificate. Remember that the CA is the heart of your security system; 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.

The place where the private key is stored depends on the CSP selected during the installation of the CA. A CSP can be software based; for CA private key storage, it should be, preferably, hardware-based. The safest way to store the CA's private key is on a specialized hardware device, a Hardware Security Module (HSM), but these are very expensive. A cheaper alternative is a smart card. Windows 2000 supports different types of smart cards and smart card readers.

Regardless of the choice you make, you need to make sure that the device on which you store the CA's private key is physically secured. Put it in a highly secured area of your organization's computer room, or lock it in a safe. If you're not planning to use any special hardware protection on your root CAs and intermediate CAs, remember that it is a best practice to keep these servers offline. Keeping the offline CA servers in a secured area also offers private key protection.

CA Naming Conventions

During CA installation, you are prompted to enter the CA's identification information: the CA name, organization, organizational unit, city, state or province, country/region, e-mail, and CA description. Be sure to agree on the naming conventions before you start the installation. The naming choices made during installation affect not only the CA; they will also be the CA's Common Name in Active Directory and will be reflected in every certificate the CA issues.

Windows 2000 generates a sanitized CA name, which is the truncated CA name without any non-ASCII characters and ASCII punctuation characters. It is needed for file names, key container names, and Active Directory object names that cannot handle a CA name that includes special characters. Active Directory object names are limited to 64 characters; if a CA's name is longer than 64 characters, it is truncated and appended with a hash calculated over the truncated part.

To look at all CA-related Active Directory names (including the CA sanitized names), run Certutil with the -v -ds switches. All CA-related Active Directory content was explained in the previous chapter.

After you install the CA, you cannot change the server's name. If you need to do this, you must uninstall the CA, change the server's name, and then re-install the CA.

CA Database

The location of the database and its log files can be specified during CA installation. During installation, you are also asked whether you want to store the CA's configuration information on the file system. Doing this copies the CA's naming information and the CA's certificate to the file system (the configuration directory will automatically be shared as "certconfig").

The Windows 2000 CA database is a JET database. It uses the same database engine, the Extensible Storage Engine (esent.dll), that is used in Exchange and Active Directory. Just as for any other JET database, a good practice is to split the database and its log files across different physical disk drives. By default, all of its files are located in the "certlog" subdirectory of the system directory. To determine the location of your CA database files, type certutil -database locations at the command prompt. The CA database consists of the files listed in the following table.

Database file	Purpose
CA name.edb	CA store
edb.log	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 Windows 2000 CA database is designed to support up to 1 million certificates; if every user has an average of four certificates, the database can support approximately 250,000 users. Because there is no limit on the number of CAs that can be supported in a single domain, the number of supported users and certificates in the Windows 2000 PKI is practically unlimited.

The CA database format used in Certificate Services for Windows 2000 is different from the format used in the version of Certificate Server for Windows NT 4.0. When Windows NT 4.0 is upgraded to Windows 2000, the database is converted automatically. To upgrade your CA database from the earlier version to the later version, stop the CA service, use certutil -convertMDB to do the conversion, restart the CA service, and force the publication of a new CRL. To look at the new schema layout of the Windows 2000 CA database, type certutil -schema at the command prompt.

Other Installation-Time CA Configurations

During enterprise or stand-alone CA installation or certificate renewal, you can add several custom extensions to the CA certificate:

• A custom Issuer Statement

• A custom certificate policies field, pointing to all certificate policies that the CA adheres to

• Custom CRL distribution points

• Custom authority information access points

• Custom enhanced key usage settings

• Custom certificate renewal settings

The last four extensions are used only when installing or renewing a root CA certificate. For CRL distribution points for subordinate CAs, authority information access points and key lifetime settings are set by configuring the parent CA's policy settings.

To customize the CA certificate, you must create a policy statement file, Capolicy.inf, and store it in the system directory (C:\winnt) prior to CA installation. The following code represents a sample Capolicy.inf file:

[Version]
Signature="$Windows NT$"
[CAPolicy]
Policies=CompaqPolicy
[CompaqPolicy]
OID=1.1.1.1.1.2.3.4.5
URL = "https://www.compaq.com/certsvc/cp.asp"
URL = "ftp://ftp.compaq.com/certsvc/cp.asp"
URL = "ldap://ldap.compaq.com/certsvc/cp.asp"
Notice = "Compaq Certificate Policy"
[CRLDistributionPoint]
URL="http:://www.compaq.com/Public/CompaqCA.crl"
[AuthorityInformationAccess]
URL="http::// www.compaq.com/Public/CompaqCA.crt"
[EnhancedKeyUsage]
OID=1.2.3.2.110
OID=1.2.3.2.111
[certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriod=4
RenewalValidityPeriodUnits=Years

The settings in the "[CompaqPolicy]" part of the code will embed the following in the CA's certificate policies extension:

[1] CertificatePolicy:

PolicyIdentifier=1.1.1.1.1.2.3.4.5

[1,1]Policy Qualifier info:

Policy Qualifier ID= CPS

Qualifier: https://www.compaq.com/certsvc/cp.asp

[1,2]Policy Qualifier info:

Policy Qualifier ID= CPS

Qualifier: ftp://ftp.compaq.com/certsvc/cp.asp

[1,3]Policy Qualifier info:

Policy Qualifier ID= CPS

Qualifier: ldap://ldap.compaq.com/ certsvc/cp.asp

[1,4]Policy Qualifier info:

Policy Qualifier ID= User Notice

Qualifier: Notice Text= Compaq Certificate Policy

Parameters Set During CA configuration

After you install the CA, you must configure the CA and all the entities related to the operation of your PKI environment. This includes configuring CRL preferences, policy and exit module settings, loading the appropriate certificate templates, delegating administrative control, setting identification options, setting up additional certificate request interfaces, and hardening the CA server.

CRL Settings

In the planning for a PKI, you should consider how CRLs will be generated, distributed, and checked. You need to think about the following CRL-related parameters: the period allowed between key compromise and certificate revocation, the CRL lifetime and publication interval, and the number and type of CRL distribution points.

The period allowed between key compromise and certificate revocation is a parameter that should be agreed upon in the certificate policies and mentioned in the certification practice statement (CPS).

When setting the CRL lifetime and publication interval parameters, keep the following in mind:

• In Windows 2000, the CRL lifetime and publication interval are, though closely related, not the same. The CRL lifetime is deducted from the publication interval and is by default 10 percent longer than its publication schedule. This enables Windows 2000 to deal with the replication delay of CRLs that are published in Active Directory. The CRL overlap can be set in the registry by using the CRLOverlapPeriod, CRLOverlapUnits, and Clockskewminutes parameters, which are located in the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \CertSvc \Configuration<CA Name>\ registry hive.

  For example, imagine you have to deal with a replication delay of four hours. In this case, it would be wise to set the overlap period to five hours. The CRL lifetime resulting from the registry settings (in the list that follows) would be one week, five hours, and 10 minutes, because it is the sum of CRLPeriod, CRLOverlapPeriod, and Clockskewminutes.

  CRLPeriod	REG_SZ = Weeks
  CRLPeriodUnits	REG_DWORD = 1
  CRLOverlapPeriod	REG_SZ = Hours
  CRLOverlapUnits	REG_DWORD = 5
  ClockSkewMinutes	REG_DWORD = a

  Setting the CRLOverlapUnits parameter in the registry to 0 activates the default algorithm for the calculation of the CRL overlap, mentioned previously.

• The shorter the CRL lifetime, the faster the user is apprised of a revoked certificate. Setting CRL publication (and thus CRL lifetimes) too short can burden the network with numerous CRL downloads.

• Windows 2000 supports both automated and manual CRL publishing. To disable automatic CRL publishing, check the disable publication schedule box or set the CRLPeriodUnits parameter in the registry to 0. Automatic CRL publication cannot be set to less than one hour. It is set on the CA level, in the properties of the revoked certificates container available from the MMC Certification Authority snap-in.

• If some of your PKI-enabled applications have different CRL publication requirements, you will need to install multiple CAs. For example, you might install one CA with a short publication schedule that is used for an application with high security requirements, and another CA with a longer schedule for an application with lower security requirements.

Windows 2000 supports four types of CRL distribution points: Lightweight Directory Access Protocol (LDAP), file system, Hypertext Transfer Protocol (HTTP) based, and File Transfer Protocol (FTP) based. For CRL downloads within your Windows 2000–based organization, Active Directory is an obvious storage location; in this case, you use LDAP CRL distribution points. Because Active Directory provides automatic replication of the CRLs throughout your Windows 2000 forest, LDAP CRL distribution points pointing to the CRL in Active Directory will always be fault tolerant (unless you have only one domain controller in your Windows 2000 forest). Remember, however, that the way you set up intersite and intrasite Active Directory replication can affect the availability of the CRLs. If you use certificates to communicate with entities outside your organization, you'll need to consider alternative CRL distribution point locations, such as FTP sites or Web pages.

CRL distribution points for certificates issued by a CA are configured in the X.509 extensions tab of the Policy Module configuration dialog box, available from the properties of the CA object container in the MMC Certification Authorities snap-in. To define CRL distribution points, use the text string variables (also known as the replaceable parameter syntax) defined in the table that follows. In the registry, the text string variables are translated into numbered variables. Remember that the CRL distribution point settings for the certificate of a root CA are configured during CA installation by using the Capolicy.inf file, as explained earlier in this chapter.

Text string variable	Numbered variable	Value
%SERVER_DNS_NAME%	%1	DNS name of the CA
%SERVER_SHORT_NAME%	%2	Network basic input/output system (NetBIOS) name of the CA
%CA_NAME%	%3	Name of the CA
%CERT_SUFFIX%	%4	Renewal extension of the CA
	%5	Location of domain root in Active Directory
%CONFIG_NAME%	%6	Location of the Configuration container in Active Directory
%CA_NAME_HASH%	%7	Sanitized name of the CA
%CRL_SUFFIX%	%8	CRL base file name and renewal extension for the CA

The renewal extension is the extension that is added to the CRL name when the CA's key pair has been changed, and thus when a CRL is generated. The %5 and %6 variables both point to the PKI entries in Active Directory.

To use the replaceable parameter syntax for CRL distribution point and authority information access specifications in the Capolicy.inf file, you need to add an extra % before every parameter; for example, instead of %8, you specify %%8. To specify a space in the CRL distribution point or authority information access, you need to add three extra % to the %20, so it becomes %%%%20.

The table that follows lists some sample file, Active Directory, and Web CRL distribution points.

File CRL distribution point:

File://\\%SERVER_DNS_NAME%\CertEnroll\%CA_NAME%%CRL_SUFFIX%.crl

Active Directory CRL distribution point:

ldap:///CN=%CA_NAME_HASH%%CRL_SUFFIX%,CN=%SERVER_SHORT_NAME%,CN=CDP,CN=Public Key Services, CN=Services,%CONFIG_NAME%?certificateRevocationList?base?objectclass=cRLDistributionPoint

Web CRL distribution point:

https://%SERVER_DNS_NAME%/CertEnroll/%CA_NAME%%CRL_SUFFIX%.crl

Certificate Characteristics

The administrator of a Windows 2000 CA can set the following certificate properties: the certificate lifetime, the CRL distribution points, and the authority information access points. The CA administrator can influence the user’s key pair lifetime. The certificate lifetime is always the minimum of the following:

• The registry validity period setting on the CA, as defined in the following registry key on the CA: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\ValidityPeriodUnits

• The certificate template validity period ( Validity Period on the General tab of Properties for the specific Certificate Template)

• The lifetime of the CA certificate

The CA administrator has full control to modify these settings.

Remember that machine certificates, resulting from an autoenrollment, will renew their key pair automatically together and at each automatic certificate renewal.

To set authority information access points, you can use the same procedure and variables as the ones outlined for CRL distribution points.

The default certificate lifetimes and the way you can change the defaults were explained in the previous chapter. When planning for certificate lifetimes, you must consider the following:

• The longer the lifetime of public and private key, the more packets will be secured with the same key pair, giving a hacker more opportunities to break the mathematical problem behind an asymmetric cipher. Hence, it's a good practice to renew the key pair at each certificate renewal.

• Certificate lifetime is also related to key length. Because it takes less time to resolve the mathematical problem behind an asymmetric cipher by using short keys, Certificates certifying short public keys should have a shorter lifetime than the ones certifying long public keys.

• The storage of public key credentials on a dedicated hardware device (such as a smart card), and consequently, the usage of a hardware CSP, lower the risk for private key compromise. This is a reason to lengthen the key pair and certificate lifetimes.

• More secure storage automatically lowers the risk for attacks on public key credentials—another reason to consider longer certificate lifetimes. The risk for attacks is also influenced by other organizational and IT environmental factors, such as the cryptographic knowledge of your employees.

• Certificate lifetime affects the number of certificate renewal requests sent across your network. In environments with scarce bandwidth—for example, users in remote site connecting to a CA across a slow wide area network (WAN)—this can be a reason to lengthen certificate lifetimes.

• If you issue certificates to users of your corporate extranet, the certificate lifetime might be shorter than when you issue 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.

CA Administration Delegation

Administration of the Windows 2000 CA can be delegated to different administrators by setting the appropriate access control lists (ACLs) on the CA object. The CA permissions and CA administration delegation can be divided into three basic categories:

• The CA Manage permission is for administrators who manage the CA configuration. This permission allows for fine-grain delegation. For example, CA management can be delegated for certificate revocation or certificate request approval.

• The CA Read permission is for administrators who need to look at, but do not need to alter, the CA configuration.

• The CA Enroll permission is for PKI clients that need to request certificates to the CA.

To view the CA permissions, right-click the CA object in the MMC Certification Authority snap-in, and then click Properties.

The following table shows the permissions that can be set in Basic View and Advanced View.

	Meaning	Default membership
Basic View
Manage (1)	Accounts and groups that can manage the CA by using the MMC snap-in or from a command line	Administrators (local); Domain Admins; Enterprise Admins
Enroll	Accounts and groups that can request certificates	Administrators (local); Domain Admins; Enterprise Admins; Authenticated Users
Read (2)	Accounts and groups that can read CA configuration information	Administrators (local); Domain Admins; Enterprise Admins; Authenticated Users
Advanced View
Write Configuration	Accounts and groups that can change CA configuration information	Manage members (1)
Read Control	Accounts and groups that can view the CA configuration information	Read members (2)
Modify Permissions	Accounts and groups that can change CA security permissions	Manage members (1)
Modify Owner	Accounts and groups that can change ownership of a CA object	Manage members (1)
Revoke Certificates	Accounts and groups that can revoke certificates	Manage members (1)
Approve Certificates	Accounts and groups that can approve certificate requests	Manage members (1)
Read Database	Accounts and groups that can access and read the CA database	Manage members (1)

Although Windows 2000 offers plenty of flexibility for the definition of CA-related administrative tasks, it offers no or very little flexibility for the delegation of CA-related installations in a Windows 2000 forest. For example, in a forest, only a root domain or an enterprise administrator can install an enterprise CA, because installation of an enterprise CA requires read/write permission to the Active Directory configuration naming context. Consequently, an enterprise administrator cannot delegate the installation of an enterprise subordinate CA to an administrator of a child domain.

Hardening the CA Server

A CA's private key is the most critical element of PKI security. If a root or intermediate CA's private key is compromised, part or all of your PKI-trust infrastructure is ruined. The level of security provided by a CA on the level of private key storage will also have an significant impact on the amount of trust people have in the CA. This is why it is so important to securely store the CA's private key securely, and to keep root and intermediate CAs offline. It is also important to "harden" your CA server by boosting the following types of security:

• Physical security. Install Certificate Servers on computers in secure areas where physical access is controlled and where there is protection against fire, power loss, and other disasters.

  Logical security. Implement software access control systems on the computer to prevent unauthorized access to computer systems. In a Windows 2000 environment, logical security depends on the quality of the operating system's authentication and access control system.

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

  • You can provide high-quality access control by checking the ACLs on all the server's resources at regular intervals. Remember, in Windows 2000, you need to check ACLs on file system objects and on Active Directory objects.

  • You can use the Security Configuration and Analysis tool (SCA—it comes with Windows 2000) to audit the security settings on Windows 2000–based servers. You can automate the SCA and run it at regular intervals in batch mode (by using Secedit.exe).

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

• Organizational security. Make sure the administrators of the CA and the operators of the computer room where the CA server is located are aware of the importance of the CA. Convince them that this is not an ordinary file and print server but a server used to secure your corporate IT environment.

Defining Public Key Policy Settings

Windows 2000 Group Policy object (GPO) objects include some PKI-related entries: Automated Certificate Request Settings, Trusted Root Certification Authorities, Enterprise Trust, and Encrypted Data Recovery Agents. The table that follows shows the mapping between the PKI-related GPO settings, the GPO levels (domain, site, organizational unit [OU], or local), and the GPO portions (user or machine). Notice that the same settings occur on the site, domain, and OU levels. Settings that are defined on the machine level are shared with all users logging on to the machine and all services running on the machine. Settings defined on the user level are valid only on the user level.

	GPO level	User	Machine
Automated Certificate Request	Domain		X
	Site		X
	OU		X
	Local
Trusted Root CAs	Domain		X
	Site		X
	OU		X
	Local
Enterprise Trust	Domain	X	X
	Site	X	X
	OU	X	X
	Local
Encrypted Data Recovery Agents	Domain		X
	Site		X
	OU		X
	Local		X

Automated Certificate Requests

The Automated Certificate Request GPO setting refers to automated certificate enrollment and renewal. Windows 2000 administrators can set machine accounts to enroll automatically for a certificate when they boot up or the next time their GPO settings are enforced. For example, you can use this feature to autoenroll all machines located in one of your Windows 2000 sites. Automatic renewal starts automatically at a moment that is defined in the renewal overlap parameter of a certificate template, before the expiration of the certificate.

The following machine-related certificate types can be automatically requested: computer, domain controller, Internet Protocol security (IPsec), and enrollment agent. Automated enrollment can be very useful for IPsec or SSL certificate-based machine authentication. In the Automatic Certificate Request Setup Wizard, you can select multiple enterprise CAs that may service the request. This feature can provide some level of fault tolerance; if the first CA in the list is unavailable, the next one can be tried.

Every time the GPO settings are applied to the machine, an autoenrollment event occurs. This event triggers more than just autoenrollment:

• The status of the current available machine certificates is checked against the autoenrollment object. This means not only that the machine will automatically enroll for a certificate, but also that it will reenroll in case of certificate revocation, certificate expiry, or even when the CAs that can issue the autoenroll certificate have been changed in the GPO setting.

• Certificates of enterprise root CAs are downloaded from the directory service–based enterprise root store to the machine's local Trusted Root Certification Authorities certificate store.

• Download of enterprise CA certificates from the Active Directory–based NTAuth store to local machine NTAuth store.

The autoenrollment event can occur when the GPO is pulsed; this happens automatically at machine startup or every eight hours, and this can happen manually by using the resource kit tool Dsstore with the –pulse switch.

Independently of this setting, every Windows 2000 domain controller that is part of a Windows 2000 forest containing an enterprise CA automatically enrolls for a domain controller certificate.

Trusted Root Certification Authorities

The Trusted Root Certification Authorities GPO setting contains a list of trusted CA certificates. The name of the container is rather misleading; it can contain certificates of root and subordinate CAs, and certificates of CAs internal and external to your Windows 2000–based organization. Unlike the Enterprise Trust setting explained later in this paper, you cannot limit the trust of CA certificates in this container based on time or application (certificate template). The certificates that are part of this GPO setting are downloaded to the Trusted Root Certification Authorities container of your Windows 2000–based clients.

Besides the use of this GPO setting, there are two other ways to automatically download CA certificates to users' Trusted Root Certification Authorities certificate store container. The certificate entries in the directory service–based enterprise root store and NTAuth store are downloaded to the Trusted Root Certification Authorities certificate store when the autoenrollment event occurs.

Directory Service–Based Enterprise Root Store

If a root domain administrator or an enterprise administrator installs an enterprise or stand-alone root CA in Windows 2000 domain, a CA object is automatically added to the Active Directory–based enterprise root store. The multi-valued Cacertificate attribute of the CA object contains the CA's certificate or certificates. This store is located in CN=< CA NAME >, CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>,DC=com. To display or modify (add-delete) the content of the directory service–based enterprise root store, you can use: dsstore <DN of root domain (required) > [-display | -del | -addroot].

The NTAuth Store

If a root domain administrator or an enterprise administrator installs an enterprise CA in a Windows 2000 domain, its certificate is automatically added to the NTAuth store. This Active Directory store contains the certificates of enterprise CAs that are capable of issuing smart card logon and enrolment agent certificates. The certificates are added as fields in the multi-valued Cacertificate attribute of the following Active Directory object: CN=NTAuthTemplates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>,DC=com.

Enterprise Trust

The Enterprise Trust GPO setting contains a signed list of certificates of CAs that are internal or external to your organization, and that need to be trusted by your internal Windows 2000 entities. The setting is referred to as a Certificate Trust List (CTL). The concept of CTLs was also used in Microsoft Exchange version 5.5 Advanced Security to enable S/MIME-based security interoperability between two organizations. To create a CTL, an administrator needs a "CTL signing" or "administrator" certificate. By default, members of the Enterprise Admins and Domain Admins groups can enroll for these certificate types.

Using the Enterprise Trust GPO setting, the trust definition can be fine-tuned based on certificate type and validity period. This is very different from the Trusted Root Certification Authorities GPO setting: a CA that is trusted using this setting is, by default, trusted for all purposes and for its entire lifetime. You can fine-tune the trust by accessing the following components of the …dialog box:

• Use Certificate type to specify that certificates coming from a particular CA are trusted only for some uses or purposes (such as secure e-mail). Besides the certificate purposes available by default, you can also add your own purposes by adding the appropriate object identifier (also known as OID) in the User defined purposes dialog box. These purposes are listed in the subject usage extension of the CTL.

• Use Validity period to specify that certificates coming from a particular CA are trusted only if they are used within a certain time limit. If the administrator doesn't specify a lifetime, the CTL expires when the "CTL signing" certificate expires. The CTL validity period can be specified in months and days; it is listed in the effective date and next update extensions of the CTL.

Besides the subject usage, effective date, and next update fields, the CTL format used by Microsoft also contains a version number, a list identifier, the subject algorithm, the thumbprint algorithm, a thumbprint, and a friendly name. A CTL's properties are displayed in the CTL dialog box that opens when you double-click a CTL. The same dialog box can be used to view the CTL signature.

Encrypted Data Recovery Agents

The Encrypted Data Recovery Agents GPO setting is used to define accounts that have the ability to recover encrypted Encrypting File System (EFS) data. A Windows 2000 domain administrator can grant this privilege to a limited number of Windows 2000 accounts. Only accounts that have an "EFS recovery" certificate can be added to this setting. You can add accounts by pointing to their recovery certificates stored in Active Directory or on the file system.

Microsoft Enterprise Services

Jan De Clercq: Senior Consultant, Compaq Global Services

March 2001

For information about Enterprise Services, see https://www.microsoft.com/es/.

Companies, organizations, products, people, and events depicted in examples in this paper are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.