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%\system32\certlog 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.