Uncover PKI and Certificate Services in Windows Server 2003

The core component of the Windows Server 2003 public key infrastructure (PKI) software is the Certification Authority (CA), which Microsoft often refers to as the Certificate Server or Certificate Services. A CA receives and processes PKI user certificate requests, identifies and validates those requests, issues certificates according to the PKI's security policy, renews and revokes certificates, publishes certificates to different locations, creates and publishes certificate revocation lists (CRLs), and logs all certificate and CRL transactions to the appropriate database. A Windows 2003 CA can also perform secure private key archival and recovery. (For more information about certificate revocation, key archival and recovery, and certificate autoenrollment, see the articles in "Resources," page 9.) To better understand how CAs and PKI have evolved in Windows 2003, let's examine the components of the latest Certificate Services architecture and the differences between establishing an enterprise CA and a standalone CA in Windows 2003.

Windows 2003 Certificate Services Architecture
The Windows 2003 Certificate Services architecture is almost identical to the architecture that Microsoft used for previous editions of Certificate Services. A key difference is that Microsoft modified the CA database layout to let the CA archive and recover PKI users' private keys. Figure 1 shows the architecture, which includes various modules, databases, administrative tools, intermediaries, and CryptoAPI.

Modules. At the heart of Certificate Services sits a CA server engine (certsrv.exe) that generates certificates and CRLs and directs the message flow between the CA and other Certificate Services components. The engine uses the entry, policy, and exit modules to communicate with the other components.

The entry module accepts certificate requests formatted according to Public-Key Cryptography Standards (PKCS) #10 or the Cryptographic Management protocol using Cryptographic Message Syntax (CMS). After accepting the requests, the entry module places them in a queue for processing by the policy module.

The policy module implements and enforces the CA policy rules as set by the CA administrator. The policy module informs the CA server engine about the layout of a certificate and decides whether the CA should issue a certificate, deny a certificate, or leave a certificate request pending. To retrieve certificate layout information, the policy module can call on information stored in a directory (e.g., Active Directory—AD) or database. Windows 2003 comes with a policy module called certpdef.dll that supports two policy types: the enterprise policy mode and the standalone policy mode. (I discuss these policy modes in greater detail later.) To check out the policy module installed on your CA, open the Microsoft Management Console (MMC) Certification Authority snap-in, right-click the CA object, select Properties from the context menu, and select the Policy Module tab, which Figure 2 shows.

Exit modules distribute and publish certificates, certificate chains, complete CRLs, and delta CRLs. Exit modules can write PKI data to a file or use HTTP or a remote procedure call (RPC) to transport the data to a remote location. Because a Windows 2003 CA can support multiple exit modules, the CA can publish and distribute certificates, certificate chains, complete CRLs, and delta CRLs to different locations at the same time, including Lightweight Directory Access Protocol (LDAP) directories, file shares, Web directories, and even ODBC-compliant databases. The default Windows 2003 CA exit module is called certxds.dll and comes with LDAP, FTP, HTTP, and SMTP support (the Windows 2000 CA supports all but the last protocol). Exit modules let the CA automatically send notification messages to PKI users and administrators. To check out the exit modules installed on your CA, open the Certification Authority snap-in, right-click the CA object, select Properties from the context menu, and select the Exit Module tab, which Figure 3 shows.

The policy module and the exit modules are both customizable and replaceable—any organization can develop its own modules in C++ or Visual Basic (VB) and plug them into the Certificate Services architecture. The Windows 2003 platform software development kit (SDK) documents the steps necessary for creating and replacing modules.

You can use the Certification Authority snap-in or the certutil.exe command-line utility to configure the policy and exit modules. By using the properties associated with the CA object in the Certification Authority snap-in, you can add multiple exit modules, configure X.509 certificate extensions (e.g., CRL Distribution Points—CDP—and Authority Information Access—AIA—points), and configure complete CRL and delta CRL publication parameters.

Databases. The CA has its own database, called CAname.edb, to store certificate transactions and status information, certificates, and optionally archived private keys. By default, the database is in the %systemroot%system32certlog folder. The CA engine communicates with its database through the certdb.dll file. With the release of Win2K Certificate Services, Microsoft changed its database technology to the Jet database engine and in doing so made the Win2K CA scalable. Microsoft uses the same technology for the AD and Microsoft Exchange Server databases.

Administrative tools. Although most administrators will use the Certification Authority snap-in to manage a Windows 2003 CA, you can also use the certutil.exe command-line utility. Both administration tools use the certadm.dll file to communicate with the CA engine.

Intermediaries. Applications that help the client generate correctly formatted PKCS #10 or CMS certificate request files are known as intermediaries or registration authorities (RAs). An intermediary or RA gathers user- and request-specific data required for a valid certificate request. For example, any request sent to a Windows 2003 enterprise CA should mention a certificate template. An intermediary can add a template specification to the request. Intermediaries are bound to a specific transport protocol (e.g., HTTP, RPC). As a result, the CA engine doesn't have to work with different transport providers.

Examples of Windows 2003 intermediaries are the Web-based certificate enrollment pages, which serve as an HTTP intermediary, and the MMC Certificates snap-in that calls on the Certificate Request Wizard, which is an RPC intermediary. The HTTP intermediary calls on the xenroll.dll file to generate private keys on the client machine and the scenroll.dll file to generate private keys on a smart card. The RPC intermediary calls on the certcli.dll file to perform these tasks.

CryptoAPI. For all cryptographic functions, including accessing and using the CA's private key, the CA calls on CryptoAPI. The CA can store its private key on a hard disk or on a dedicated hardware device (e.g., a Hardware Security Module—HSM).

Windows 2003 Certificate Services Installation
When you install Windows 2003 Certificate Services, you can install a root CA, a subordinate CA, an enterprise (AD-integrated) CA, or a standalone (non­AD-integrated) CA. Installing Certificate Services in enterprise mode activates the enterprise mode of the Windows 2003 CA policy module. Let's compare the enterprise mode with the standalone mode to see how they differ. Table 1 compares the default characteristics of a Windows 2003 standalone CA with a Windows 2003 enterprise CA.

To install a CA in enterprise mode, the account installing the CA must be an enterprise administrator and a domain administrator of the AD forest's root domain. In addition, the server on which you install the enterprise CA must be a member of a domain that has a functioning AD. If these conditions aren't met, the enterprise mode installation options will be shaded in the CA Installation Wizard and you'll be able to install the CA only in standalone mode.

To install a CA in standalone mode, no AD is required. You can install the CA on a standalone server, a member server, or a domain controller (DC). Also, the account performing the installation doesn't need to be an enterprise or domain administrator—local machine administrator permissions are sufficient. If you do use enterprise administrator privileges to install a standalone CA, the CA will offer some additional features. For example, if an enterprise administrator installs a standalone CA on a member server that's joined to the domain, the CA will publish to the AD the certificates that it issues.

Certificate Templates
An enterprise CA uses certificate templates stored in the AD configuration naming context (NC). Certificate templates define the content and characteristics of a certificate. Certificate templates also provide a way to control which certificate types an enterprise CA can issue and which users can request which certificate types from an enterprise CA. Windows 2003 PKI supports version 2 certificate templates. In contrast to version 1 templates, version 2 templates are fully customizable. You can use the MMC Certificate Templates snap-in to customize them.

A standalone CA can't use AD certificate templates. As a consequence, you can't control which users can request which certificate types from the CA. By default, a standalone CA can issue only Web authentication (Secure Sockets Layer—SSL—or Transport Layer Security—TLS), email protection (Secure MIME—S/MIME), server authentication, code signing, timestamp signing, and IP Security (IPSec) certificates. You can, however, modify the standalone CA's Web interface (e.g., to list other certificate types) or simply request other certificate types by using special Object Identifier (OID) values stored in a certificate's Extended Key Usage X.509 extension.

Certificate Request Information Retrieval
An enterprise CA retrieves user information from AD during certificate enrollment. The CA uses this information to populate certain certificate fields. For example, a certificate issued by an enterprise CA contains a reference to a user's user principal name (UPN) in the certificate's SubjectAltName X.509 field. Because a standalone CA has no access to AD, the user must manually complete the user identification information required for the certificate on the enrollment Web site.

For both enterprise and standalone CAs, you can change the default values that the CA adds to a certificate request at the time of enrollment by editing the certdat.inc file in the %systemroot%system32certsrv directory. You can change the default values for the following certificate entries: sDefaultCompany, sDefaultOrgUnit, sDefaultLocality, sDefaultState, and sDefaultCountry. Changing these values to your organization's default values reduces the amount of information that a user must enter when requesting a certificate.

Automated Certificate Enrollment
An enterprise CA supports automated certificate enrollment, and Windows 2003 extends this feature to cover both users and machines. For additional information about automated certificate enrollment, see "Windows Server 2003 PKI Certificate Autoenrollment," January 2004, InstantDoc ID 40948. A user who wants a certificate from a standalone CA must manually start the enrollment process—no automation is provided.

Centralized Key Archival
Whereas an enterprise CA supports centralized key archival in the CA database, a standalone CA doesn't. For more information about the CA's key archival and recovery capabilities, see "Windows Server 2003 PKI Key Archival and Recovery," February 2004, InstantDoc ID 41281.

Certificate Request Approval
An enterprise CA can support automatic or manual certificate request approval. You can use the properties of an enterprise CA (using the policy module properties) or the properties of a version 2 certificate template (using the Issuance Requirements tab in the certificate template's properties) to set the certificate request-handling properties. If you use a version 2 certificate template to set the certificate request-handling properties, the change will apply only to the certificate type defined in the template. You can force the administrator to manually approve all incoming certificate requests—independent of the certificate template settings—by setting the request- handling properties to Set the certificate request status to pending. The administrator must explicitly issue the certificate in the CA properties. The same options are available for a standalone CA. The only difference is that a standalone CA can't use certificate templates, and as a consequence, you can't set request-handling properties for individual certificate templates. Unlike an enterprise CA, a standalone CA doesn't rely on the built-in Windows authentication mechanisms to authenticate incoming certificate requests; therefore, Microsoft doesn't recommend setting a standalone CA's request-handling property to automatic approval. You should always leave this property set to the default to require manual CA administrator approval for every incoming certificate request.

Publishing Certificates and CRLs
An enterprise CA uses AD to store and publish certificates, complete CRLs, and delta CRLs. Both a standalone CA and an enterprise CA can also publish to the file system. Each certificate published in AD automatically maps to the Windows account of its requestor. AD adds the certificate to the multivalued userCertificate attribute of a user or inetOrgPerson AD object. However, not every certificate that an enterprise CA generates is automatically published in AD. Examples of certificates that aren't automatically published are an enrollment agent or certificate trust list (CTL) signing certificate.

A standalone CA can publish issued certificates to AD, but this step isn't the default behavior. A standalone CA will automatically publish certificates to AD only if an enterprise administrator installs the CA on a member server joined to the domain. You can obviously always publish the certificates manually to AD.

The Best CA for the Job
Now that you're aware of the differences between an enterprise CA and a standalone CA, you can pick the best option for your situation. A Windows 2003 enterprise CA typically is best suited for enterprise certificate users who have an AD user account and who use Kerberos to authenticate to the AD infrastructure. A Windows 2003 standalone CA typically is best suited for external users (e.g., extranet users) who don't have an internal Windows account.