How Certificate Services Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

• Certificate Services Architecture

• Certificate Services Protocols

• Certificate Services Interfaces

• Certificate Services Physical Structure

• Certificate Services Processes and Interactions

• Related Information

Certificate Services provides customizable services for issuing and managing certificates used in software security systems employing public key technologies. You can use Certificate Services to:

• Create certification authorities (CAs) which will receive certificate requests.

• Verify the information in a certificate request.

• Verify the identity of the certificate requester.

• Issue and renew certificates.

• Revoke certificates.

• Publish certificate revocation lists (CRLs).

Additionally, in Windows Server 2003, you can use Certificate Services to:

• Enroll users for certificates from the CA using the Web, or the Microsoft Management Console (MMC) Certificates snap-in, or transparently through autoenrollment.

• Take advantage of programmatic and command-line scripting to perform common tasks such as enrollment processing.

• Help simplify — by using certificate templates and CA policy — the choices a certificate requester has to make when requesting a certificate.

• Take advantage of the Active Directory directory service to publish trusted root certificates, publish issued certificates, and publish CRLs.

• Implement the ability to log on to an Active Directory domain using a smart card.

An optimal environment for Certificate Services includes one or more servers running Certificate Services. The servers running Certificate Services have been planned and deployed to enable:

• Efficient verification of certificates through a process called chain building. With the chain-building process, all certificates in a CA hierarchy are verifiable and lead to a root CA that provides an ultimate anchor of trust.

• Security of all CAs in the hierarchy by means of proper configuration and delegation of administrative responsibilities. In addition, it might be desirable to take the root CA offline in order to more stringently protect the hierarchy from compromise.

• Well defined processes and procedures for validating certificate requests and renewals, as well as for revoking certificates.

The following sections provide an in-depth view of how Certificate Services works in an optimal environment.

Certificate Services Architecture

In order to properly configure and manage Certificate Services, you need to understand its major components, the parameters of those components, and dependencies. The following figure shows a functional block diagram of how Certificate Services is implemented in Windows Server 2003.

Windows Server 2003 Certificate Services Functional Diagram

The Certificate Services engine, exit modules, and policy modules of Windows Server 2003 Certificate Services work in conjunction with CryptoAPI to perform a variety of tasks, which include:

• Submitting certificate requests (client module).

• Processing certificate requests (Certificate Services engine).

• Verifying whether requesters are qualified to receive certificates (policy module).

• Creating and issuing certificates for qualified requesters (Certificate Services engine).

• Generating a private key and distributing it to the requester’s protected certificate store (CryptoAPI and cryptographic service providers).

• Managing the private key for all cryptography operations (CryptoAPI).

• Distributing the certificates that are issued to qualified clients and, optionally, publishing certificates to Web pages, public folders, or Active Directory (exit module).

• Publishing periodic CRLs to Active Directory and, optionally, to Web pages or public folders (exit module).

• Storing all certificate transactions for the audit trail (certificates database).

  Note

  • In Windows Server 2003, all cryptographic functions and private key management are performed by CryptoAPI in conjunction with cryptographic service providers (CSPs). CryptoAPI also manages any interactions with hardware security modules (HSMs), if present. Any system service or application can request cryptographic services by using CryptoAPI.

The following sections describe these Certificate Services components:

• Client module

• Certificate Services engine

• Policy module

• Exit module

• Certificates database

• CryptoAPI

Client Module

The client module is the software that is used by the end user to generate a certificate request, send the request, and receive the finished certificate. Windows Server 2003 Certificate Services provides CA services for X.509 v3 certificate clients. It supports all Windows clients, as well as any other clients that can generate X.509 v3–compliant certificate requests.

Certificate Services Engine

The Certificate Services engine, whose file name is Certsrv.exe, is the core component of Certificate Services. The engine acts as a broker for all requests it receives from clients and regulates the flow of information between the other components during the processing of a request and the generation of a certificate. At each stage of processing, the engine interacts with the various modules to ensure appropriate action is taken based on the state of the request.

The Certificate Services engine supports the following CA operations:

• Issuance

• Publication

• Revocation

• CRL maintenance

• Other operations useful for certificates, such as key archival

Certificate Services operates in two modes: enterprise and stand-alone. In both modes, Certificate Services performs two main operations: receiving requests and publishing requests. Requests are received by a Distributed Component Object Model (DCOM) interface that clients call to submit requests. Requests are published by a number of different methods, including:

• Stand-alone Web enrollment with IIS and Certificate Services

• Enterprise Web enrollment with IIS and Certificate Services

• Enterprise enrollment with an enrollment agent

• Enterprise direct enrollment

These enrollment methods are described later in this section.

Request Handling

The default entry module processes these types of requests:

• Public Key Cryptography Standard (PKCS) #10 certificate requests

• Certificate Management protocol using CMS made through remote procedure calls (RPCs) or HTTP

The entry module is a dynamic-link library (DLL) that cannot be customized. Windows Server 2003 services usually use RPCs to submit certificate requests to enterprise CAs. However, the Web Enrollment Support pages use HTTP to submit certificate requests to CAs.

Intermediary applications can be written to handle certificate requests from different types of clients, across multiple transports, or according to policy-specific criteria. IIS is one intermediary application that accepts HTTP-based requests and makes DCOM calls on behalf of users to the CA interfaces. Intermediaries can also check on the status of a previously submitted request and obtain the Certificate Services configuration information.

Certificate requests to Certificate Services are placed in a pending queue until they are approved or denied by the policy module.

Note

• You can develop custom certificate enrollment applications that submit RPC or HTTP requests to Certificate Services. For more information about developing custom applications for Windows Server 2003 Certificate Services and about the required certificate request format, see “Using Certificate Enrollment Control” in the Cryptography collection of the Microsoft Platform SDK on MSDN.

Policy Module

After Certificate Services has parsed a certificate request, it loads the policy module and tells it where to find the request. The default policy module then examines the request, validating the different fields against its policy.

The policy module contains the set of rules governing issuance, renewal, and revocation of certificates. This policy is created from hard-coded values, registry settings, and — in the enterprise mode — certificate templates. Certificate Services provides a callback interface for the policy module. The callback interface enables the module to request information about a certificate request from the certificates database.

Note

• The policy module does not directly access the request; all access is through the Certificate Services engine.

The policy module determines whether a certificate request is approved, denied, or queued (left pending) for an administrator to approve or deny issuance. It does this by verifying the information in the request against various sources, such as a directory service, an external legacy database, or information from an outside authority. In addition, the policy module can send alerts to the appropriate administrator if manual (offline) approval of the request is required.

You can create custom policy modules to insert additional certificate attributes and extensions that might be required by a client application. Extension handlers work in tandem with the policy module to set rules extensions on a certificate. Each extension handler acts as a template for the rules extensions that should appear in a certificate. The policy module must load the appropriate extension handler when it is needed. For example, information such as a job title and a signing limit can be inserted and used by an online purchasing form to determine whether the user can sign for the amount requested.

The policy module can use additional information included in the certificate request to incorporate requested attributes in the issued certificate. For example, certificate requests to stand-alone CAs must include all information about the requested certificate. Therefore, the policy module incorporates this information into each issued certificate. However, enterprise CAs use certificate templates to specify certificate attributes, so certificate requests to enterprise CAs require less information.

After it has validated all the fields, the policy module will create some of the necessary certificate fields, such as the validity period, and determine whether the request should be approved or denied. The policy module then notifies the Certificate Services engine of the result.

Windows Server 2003 Certificate Services includes default policy modules for enterprise and stand-alone CAs. In addition, you can build custom policy modules to address special needs.

Enterprise CA policy

By default, an enterprise CA policy always issues a certificate or denies a request immediately. Enterprise CA policy uses Active Directory to determine the identity of the requester, and then automatically determines whether the requester has security permissions to receive a certificate of the type being requested. However, on a per-template basis, you can specify that certificate requests are directed to a pending queue so that an administrator can approve or deny them.

Stand-alone CA policy

By default, stand-alone CA policy sends certificate requests to a pending queue so that an administrator can approve or deny them. If you prefer, you can configure stand-alone CA policy to automatically approve all certificate requests. However, because a stand-alone CA does not verify the identity of requesters in Active Directory, there is no automatic means to verify the identity and validity of the certificate requester. Therefore, if a stand-alone CA is configured to approve certificate requests automatically, it can pose a significant security risk.

Custom policy modules

Policy module settings are fully customizable. You can customize policy enforcement by:

• Modifying the installed policy module using the Certification Authority snap-in to create a custom policy module that then makes an explicit call to the default policy module.

• Developing your own policy modules.

• Acquiring a non-Microsoft policy module when one is available.

After you customize the policy module, you can configure Certificate Services to only call the new policy module.

For more information about how to customize policy modules, see “Certificate Enrollment Control” in the Cryptography collection of the Microsoft Platform SDK on MSDN.

Exit Module

After the Certificate Services engine has signed and published either a newly created certificate or new CRL, it notifies the exit module of this event. The engine provides a callback interface for the exit module, which allows the exit module to query the certificates database about issued certificates and other data. Exit modules publish completed certificates and CRLs through a number of transports or protocols. For more information, see “Certificate Services Protocols” later in this document.

Note

• CA administrators can add in additional responses to notifications by creating a custom exit module. One example might be: Call this pager when a certificate with the user name of the CEO is issued.

The exit module packages the issued certificate in the appropriate transport mechanism or protocol and distributes it to the location specified in the request. Certificate requests can specify that the certificate be distributed to Lightweight Directory Access Protocol (LDAP) directory services, file systems, or URLs. The exit module also delivers CRLs to CRL distribution points.

By default, the server notifies each exit module installed on the server whenever a certificate or CRL is published. The default enterprise exit module publishes certificates and CRLs to Active Directory. The default stand-alone exit module publishes certificates and CRLs to the local file system.

Because Windows Server 2003 Certificate Services supports multiple exit modules, you can use the certification authority snap-in to install multiple exit modules for a CA. For example, you can install exit modules that post certificates to legacy open database connectivity (ODBC) databases or to non-Microsoft LDAP directory services.

As with policy module settings, exit module settings are fully customizable. For more information about customizing exit modules, see “Writing Custom Exit Modules” in the Cryptography collection of the Microsoft Platform SDK on MSDN.

Certificates Database

The certificates database records all certificate transactions. The certificates database:

• Tracks each certificate request, the requester, and whether the request was granted or denied.

• Records information for the issued certificate, such as the private key, serial number and expiration date.

• Provides a complete audit trail for each certificate from request to expiration.

• Flags and tracks certificates that are revoked by CA administrators.

You can use the Certification Authority snap-in to manage the audit trail.

Note

• To audit CA activity, use the Certification Authority snap-in and Event Log.

For more information about the certificates database, see “Certificate Services Physical Structure” later in this document.

CryptoAPI

Certificate Services uses CryptoAPI for all cryptographic operations, including key generation and exchange, data encryption and decryption, hashing, digital signatures, and signature verification.

CryptoAPI is a generic application programming interface to cryptographic modules, called cryptographic service providers (CSPs). These CSPs are modular in nature and are replaceable by system administrators. During installation, the CA administrator can choose which CSP Certificate Services will use. For most default installations of Windows Server 2003 and Certificate Services, this will be the Microsoft RSA-enhanced provider.

CryptoAPI can also be configured with a hardware-based CSP. If a hardware-based CSP is installed, the CA Administrator can configure Certificate Services to use this CSP.

Note

• CSPs cannot access any CryptoAPI interfaces and operate on Windows unless they have received a digital signature from Microsoft. The CSP digital signature is verified each time the CSP is loaded, and each time it attempts to access the CryptoAPI interface. If the signature verification fails, no cryptographic functions are accessible to applications.

Applications can use the functions in CryptoAPI without needing information about the underlying security implementation, just as an application can use a graphics library without needing information about the particular graphics hardware configuration.

Certificate Services Protocols

Two protocols, DCOM and LDAP, provide key Certificate Services functionality.

Certificate Services uses the DCOM protocol for enrollment. Certificate Services performs two main operations: receiving requests and publishing requests. Requests are received by a DCOM interface that clients call to submit requests. Requests are published by a number of different methods, which are discussed in How Certificate Enrollment and Renewal Requests are Processed later in this document.

In the enterprise mode, both Certificate Services and clients use a directory service, such as Active Directory, to provide and access services for a domain. Both Certificate Services and clients retrieve templates from Active Directory. Certificate Services also accesses Active Directory by LDAP to verify the client and to store and retrieve certificates.

In addition, Certificate Services can distribute certificates through any transport mechanism. That is, it can accept certificate requests from an applicant and post certificates to the applicant through HTTP, RPC, disk file, or custom transport.

Certificate Services Interfaces

Certificate Services publishes the following external DCOM interfaces:

• ICertRequest and ICertRequest2. These interfaces accept requests for new and existing certificates.

• ICertAdmin and ICertAdmin2. These interfaces provide administrative functions, including request management (modification, denial, resubmission, and revocation), importing certificates, key archival, CRL management, server configuration, user role retrieval, and certificate data retrieval.

• ICertView and ICertView2. These interfaces allow properly authorized clients to create a customized or complete view of the Certificate Services certificates database.

• ICertPassage. The ICertPassage RPC protocol provides an interface to a CA for submitting a PKCS #10 request and receiving a certificate in a PKCS #7 response.

  Note

  • ICertPassage has been superseded in Windows Server 2003 by ICertRequest, but is still used by Windows 2000 clients.

Access to these interfaces is available to developers through licensable APIs. Each of these published interfaces has one of four terminating interfaces inside Certificate Services:

• ICertRequestD and ICertRequestD2

• ICertAdminD and ICertAdminD2

Certificate Services also uses five internal interfaces, which are not accessible to developers:

• ICertPolicy. Certificate Services determines whether to deny, send to a pending queue, or issue a certificate request through this interface, by calling the policy module.

• ICertServerPolicy. The policy module queries and modifies certificate request data through this interface.

• ICertExit. Certificate Services notifies any exit modules through this interface upon certificate or CRL issuance.

• ICertServerExit. An exit module can query the Certificate Services engine about issued certificates through this interface.

• ICertDB. Certificate Services uses this interface to access the certificates database.

The following figure shows the relationship between the published external interfaces, the terminating interfaces, and the internal interfaces for Windows Server 2003 Certificate Services.

Certificate Services Interfaces

Certificate Services Physical Structure

When people think of Certificate Services physical structure, they typically think in terms of the number of servers running Certificate Services, how these servers are linked, whether these servers are dedicated exclusively to Certificate Services or perform multiple functions, and so on. Many of these issues are addressed in PKI design documents. For more information about these issues, see “PKI Technologies.”

The physical structure of Certificate Services itself can best be described in terms of where certificates and certificate-related data are stored. Certificate Services uses a number of places to store certificates and configuration data:

• The certificates database and CA log file

• The registry

• Active Directory

• The file system

Identical or closely related certificate data can appear in several — even in all — of these locations. For example, parts of the configuration information from the configuration container in Active Directory are replicated to the clients certificate store. Certificates that are stored in the Active Directory Configuration container are deployed to all clients across the forest. And, if a certificate is registered in the Configuration container and the domain security Group Policy object (GPO), a certificate can appear twice on the client.

Certificates Database

Certificate Services uses an Extensible Storage Engine (ESE) database to store all certificate requests in any status, all issued certificates, certificate extensions, certificate attributes, and CRLs. The database is composed of four tables: the Request and Certificates table, the Extensions table, the Attributes table, and the CRL table.

These tables maintain status information (receipt, parsing, authorization, signing, and dispatch) as the service processes a certificate request. When Certificate Services receives a request, it creates a row in the certificates database and begins to parse the request and verify the request signatures.

The database also stores all certificates and CRLs issued by the service so that administrators can track, audit, and archive service activity. As Certificate Services parses a certificate request, it fills in the fields of the certificates database from the fields in the request. After the request has been fully parsed, the policy module is notified and the context handle corresponding to the request is passed as a parameter. In addition, the database is used by the Certificate Services engine to store pending revocations before publishing them in a CRL.

Because the certificates database is a transaction database, it includes certificate log files, which record all certificate transactions. By default, the certificates database and the CA log files are installed at the following location:

systemroot\system32\certlog

You can choose another location to install either the certificates database or the CA log files — including installing the database and log files separately on different drives — when you are installing a CA.

Note

• There is a one-to-one mapping between the tables in the certificates database.

The following table describes the contents of the certificates database.

Schema of the Certificates Database

Column Name	Localized Name	Type	Maximum Length
Request.RequestID	Request ID	Long	4 -- Indexed
Request.RawRequest	Binary Request	Binary	65536
Request.RawArchivedKey	Archived Key	Binary	65536
Request.KeyRecoveryHashes	Key Recovery Agent Hashes	String	8192
Request.RawOldCertificate	Old Certificate	Binary	16384
Request.RequestAtributes	Request Attributes	String	32768
Request.RequestType	Request Type	Long	4
Request.RequestFlags	Request Flags	Long	4
Request.StatusCode	Request Status Code	Long	4
Request.Disposition	Request Disposition	Long	4 -- Indexed
Request.DispositionMessage	Request Disposition Message	String	8192
Request.SubmittedWhen	Request Submission Date	Date	8
Request.ResolvedWhen	Request Resolution Date	Date	8 -- Indexed
Request.RevokedWhen	Revocation Date	Date	8
Request.RevokedEffectiveWhen	Effective Revocation Date	Date	8 -- Indexed
Request.RevokedReason	Revocation Reason	Long	4
Request.RequesterName	Requester Name	String	2048 -- Indexed
Request.CallerName	Caller Name	String	2048
Request.SignerPolicies	Signer Policies	String	8192
Request.SignerApplicationPolicies	Signer Application Policies	String	8192
Request.Officer	Officer	Long	4
Request.DistinguishedName	Request Distinguished Name	String	8192
Request.RawName	Request Binary Name	Binary	4096
Request.Country	Request Country/Region	String	8192
Request.Organization	Request Organization	String	8192
Request.OrgUnit	Request Organization Unit	String	8192
Request.CommonName	Request Common Name	String	8192
Request.Locality	Request City	String	8192
Request.State	Request State	String	8192
Request.Title	Request Title	String	8192
Request.GivenName	Request First Name	String	8192
Request.Initials	Request Initials	String	8192
Request.SurName	Request Last Name	String	8192
Request.DomainComponent	Request Domain Component	String	8192
Request.EMail	Request E-mail Address	String	8192
Request.StreetAddress	Request Street Address	String	8192
Request.UnstructuredName	Request Unstructured Name	String	8192
Request.UnstructuredAddress	Request Unstructured Address	String	8192
Request.DeviceSerialNumber	Request Device Serial Number	String	8192
RequestID	Issued Request ID	Long	4 -- Indexed
RawCertificate	Binary Certificate	Binary	16384
CertificateHash	Certificate Hash	String	128 -- Indexed
CertificateTemplate	Certificate Template	String	254 -- Indexed
EnrollmentFlags	Template Enrollment Flags	Long	4
GeneralFlags	Template General Flags	Long	4
SerialNumber	Serial Number	String	128 -- Indexed
IssuesrNadeID	Issuer Name ID	Long	4
NotBefore	Certificate Effective Date	Date	8
NotAfter	Certificate Expiration Date	Date	8 -- Indexed
SubjectKeyIdentifier	Issued Subject Key Identifier	String	128
RawPublicKey	Binary Public Key	Binary	4096
PublicKeyLength	Public Key Length	Long	4
PublicKeyAlgorithm	Public Key Algorithm	String	254
PublicKeyAlgorithmParameters	Public Key Algorithm Parameters	Binary	4096
UPN	User Principal Name	String	2048 -- Indexed
DistinguishedName	Issued Distinguished Named	String	8192
RawName	Issued Binary Name	Binary	4096
Country	Issued Country/Region	String	8192
Organization	Issued Organization	String	8192
OrgUnit	Issued Organization Unit	String	8192
CommonName	Issued Common Name	String	8192 -- Indexed
Locality	Issued City	String	8192
State	Issued State	String	8192
Title	Issued Title	String	8192
GivenName	Issued First Name	String	8192
Initials	Issued Initials	String	8192
SurName	Issued Last Name	String	8192
DomainComponent	Issued Domain Component	String	8192
EMail	Issued E-mail Address	String	8192
StreetAddress	Issued Street Address	String	8192
UnstructuredName	Issued Unstructured Name	String	8192
UnstructuredAddress	Issued Unstructured Address	String	8192
DeviceSerialNumber	Issued Device Serial Number	String	8192

Registry

Certificate Services uses the registry to store all of its configuration data, as well as other data. This registry key is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

For more information about relevant registry settings, see “Certificate Services Tools and Settings.”

Active Directory

Various PKI-related containers such as certification authorities, enrollment services, templates, object identifiers (OIDs), and the authority information access and CRL distribution point extensions are created when the first enterprise CA is created in a forest. The permissions on the containers are also set at that time. These containers are replicated to every domain controller within a forest.

Installing an enterprise CA creates the following containers.

“Trusted root CA and CRL distribution point containers”

Before you can install an issuing CA, you must publish the root CA’s certificate to the Active Directory trusted root CA container, and publish the root CA’s CRL to the Active Directory CRL distribution point container. This will cause all domain members (including the issuing CA) to import the root CA’s certificate into their own root stores and will enable them to verify the revocation status of any certificates issued by the root CA. The common name of the trusted root CA container is:

CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=

The common name of the CRL distribution point container is:

CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Authority information access container

The authority information access container is the publication point for the most currently published CA certificates for root and intermediate CAs. The authority information access extension in a certificate identifies the location of the authority information access container, which helps clients find CA certificates dynamically during chain building.

The common name of the authority information access container is:

CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=

NTAuthCertificates container

Publishing CA certificates to the NTAuthCertificates leaf object indicates that these CAs are trusted to both:

• Issue authentication (logon) certificates for any user in the forest.

• Enable logon for smart cards, IIS mapping, and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).

The common name of the NTAuthCertificates leaf object is:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=?

Certificate Templates container

Installing the first enterprise CA in the forest also installs 29 certificate template objects in Windows Server 2003 or 24 certificate template objects in Windows 2000. The common name for the Certificate Templates container is:

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=

For more information about certificate templates in Windows Server 2003 and Windows 2000, see the “Certificates Technical Reference.”

OID container

Windows Server 2003 adds an object identifier (OID) container to the configuration container. Because OIDs are not hard-coded in version 2 templates, the OID container is required to work with version 2 templates. The common name for the OID container is:

CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Windows Server 2003 includes four predefined issuance policy OIDs:

• All issuance (2.5.29.32.0). The all issuance policy OID indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates.

• **Low assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). The low assurance OID is used to represent certificates that are issued with no additional security requirements.

  Note

  • The x.y.z portion of the OID is a randomly generated numeric sequence that is unique for each Windows Server 2003 forest.

• Medium assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). The medium assurance OID is used to represent certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face-to-face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier.

• High assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). The high assurance OID is used to represent certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver because a person holding this certificate can recover private key material from a Windows Server 2003, Enterprise Edition CA.

Key recovery agent container

Key recovery agent certificates are published to the key recovery agent container in Active Directory when enrollment occurs. Because a CA can issue multiple key recovery agent certificates, each key recovery agent certificate will be added to the multi-valued user attribute of the CA object.

The common name for the key recovery agent container is:

CN=KRA,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Note

• The key recovery agent container only appears under Windows Server 2003.

File System

By default, the only directory in the file system that is used by Certificate Services is systemdir\CertLog. This is where the certificates database and request logs are stored. Some organizations prefer to create two separate directories, one for the database and one for the log files.

Certificate Services and its associated tools produce several logs which can be used for troubleshooting:

• Certificate Services logs to systemroot\certsrv.log (when debug logging is enabled).

• Certutil.exe logs to systemroot\certutil.log.

• Certification Authority snap-in logs to windir\certmmc.log.

Certificates and CRLs also are stored on the local file system. During the installation of the root CA, the root certificate is saved to the following shared folders:

• \\Localhost\Certenroll

• \\Locahost\Certconfig

• The SystemCertificates\My folder of the local computer, which is located at:

  \\Documents and Settings\username\Application Data\Microsoft\SystemCertificates\My

• The trusted root certification authorities container in the local computer registry, which is located at:

  HKEY_Local_Machine\Software\Microsoft\SystemCertificates\Root

The initial CRL is published in the following shared folders:

• \\Localhost\Certenroll

• The intermediate certification authorities container in the registry of the local computer.

The CA certificate of a stand-alone CA is stored in the following shared folders:

• \\Localhost\Certenroll

• \\Locahost\Certconfig

Contents of the CertConfig and CertEnroll Shared Folders

More than one certificate file exists in the \CertConfig and \CertEnroll shared folders after a period of time. If the CA name is used as part of a file name, the sanitized CA name adds additional escape characters in order to accommodate any extended ASCII characters in the file name. The escape characters appear in the file name as %20.

The following table explains the certificate file name extensions and their purposes.

Certificate Paths and File Name Extensions

Sample File Name	Description
\\Localhost\CertConfig\Certsrv.txt	This is the configuration file for the CA.
\\Localhost\CertConfig\Certsrv.bak	If the CA is reinstalled, the original CA configuration file is renamed with the .bak extension.
\\Localhost\CertConfig\SubCAname.req \\Localhost\CertConfig\SubCAname(1).req	Request file that is used to generate the CA certificate. Request files are used only for subordinate CAs. Request files are generated with the same base file name suffix as certificates.
systemroot\\SubCAname.req systemroot\\SubCAname(1).req	If no shared folder was created during the CA setup procedure and Active Directory is used to publish the CA’s configuration information, request files are written to the systemroot drive instead of to the \\Localhost\CertConfig file.
\\Localhost\CertConfig\CAname.crt \\Localhost\CertEnroll\CAname.crt	This is the concatenated name of the original root CA certificate.
\\Localhost\CertConfig\CAname(1).crt \\Localhost\CertEnroll\CAname(1).crt	When a root CA certificate is renewed, the version number (in parentheses) is appended to the certificate name.
\\Localhost\CertConfig\CAname(0-1).crt \\Localhost\CertEnroll\CAname(0-1).crt \\Localhost\CertConfig\CAname(1-0).crt \\Localhost\CertEnroll\CAname(1-0).crt	When a root certificate is renewed, a cross-certificate is automatically created from the old root certificate, which is trusted by all clients, to the new root certificate, which is not yet trusted. If the old root certificate is version 0 and the new root is version 1, the CA name is appended with the version number of the old root certificate and the version number of the new root certificate (in parenthesis and separated by a dash). If the cross-certificate provides cross trust from the new to the old CA certificates, then the order of the numbers in parenthesis is reversed.
\\Localhost\CertEnroll\CAname.crl	This is the name format for the original base revocation list for a CA.
\\Localhost\CertEnroll\CAname(1).crl	When an updated base CRL is created, the updated version is indicated in parentheses. Thus, (1) indicates the first updated base CRL.
\\Localhost\CertEnroll\Caname+.crl	A plus sign is added to the base CRL name to indicate that this is a delta CRL.

As illustrated in this table, an important function of the CertConfig and CertEnroll shared folders is to provide links between original and renewed root certificates, and original and updated CRLs. For root certificates, these links are provided by cross-certificates. The cross-certificates are automatically generated when Certificate Services starts after renewing a root CA certificate with a new key. Cross-certificates are not created for subordinate CAs, nor are they created when a root certificate is renewed with the same key. If you upgrade from Windows 2000 Server after renewing a root CA certificate with a new key, the cross-certificate is generated the first time that Certificate Services starts after you upgrade to Windows Server 2003.

Certificate Services Processes and Interactions

Certificates are a powerful security technology. Therefore, it is important to understand and carefully manage the processes performed by Windows Server 2003 Certificate Services. These processes are described in the following subsections:

• How certificates are created. This describes the core functioning of Windows Server 2003 Certificates Services.

• Certificate enrollment and renewal. Beyond the basic process associated with the creation of a new certificate, there can be significant differences in how enrollment and renewal are handled, depending on whether a stand-alone or enterprise CA is being used, whether manual or autoenrollment is used, and which versions of the operating system are involved.

• How certificates are revoked. In Windows Server 2003, certificate revocation and management have been enhanced with the addition of delta CRLs.

• How key pairs are stored.

  Note

  • Another important closely related process, certificate validation, is described in “How Certificates Work.”

How Certificates Are Created

Certificates are created only after a certificate request has been successfully processed. The process of validating or denying a certificate request involves all of the key components of Windows Server 2003 Certificate Services:

• The Certificates Services engine

• Policy module

• Exit module

• Certificates database

In addition, significant roles are played by the client requesting the certificate, CryptoAPI, and, typically, a directory such as Active Directory. The following figure illustrates these components and their relation to each other.

Components Involved in Certificate Creation

The following steps are involved in creating a certificate:

Note

• This process applies to most common PKCS #10 requests or Certificate Management protocol using CMS requests.

1. When a user initiates a certificate request, Enrollment Control (Xenroll.dll) uses a cryptographic service provider (CSP) on the client’s computer to generate a public key and private key pair for the user.

2. After a key pair has been generated, Xenroll builds a certificate request based on a certificate template.

3. The user’s public key is sent with the user’s identifying information to the Certificate Services engine.

4. Meanwhile, a copy of the request is placed in the request folder for the requester. In the case of a user, this folder is:

   C:\Documents and Settings\username\Application Data\Microsoft\SystemCertificates\Request\

5. The CA authenticates the user.

6. The Certificate Services engine passes the request to the policy module, which might perform an additional access check by querying Active Directory or another reliable source such as IIS.

7. The policy module also checks the registry for a list of certificate templates for the CA. The policy module checks the list for version numbers to verify that it has the most recent versions of all certificate templates. If the request references a more recent version of the certificate template than is currently available, the request fails.

8. If the access check is successful, the Certificate Services engine creates a new row in the Request and Certificates table of the certificates database. A request ID is entered into the database to help track the request.

9. Additional attributes of the certificate request, such as the extensions associated with the request, are entered into the appropriate fields in the database.

10. The Certificate Services engine validates the digital signature used to sign the certificate request. This validation process involves comparing all the certificates in the chain leading up to the root CA to a reliable source, such as Active Directory or IIS. This validation process also involves confirming that none of the certificates in the chain has been revoked.

11. The policy module applies a certificate template to fill out the data associated with the request. This process adds information such as usage restrictions and validity periods, as well as subject name format, to the data in the original request. Some of this data is fixed and therefore copied directly from the template, some comes from the certificate request, and some is constructed on a per user basis (concatenating the friendly name of the user into common name format, for example).

    Note

    • When a certificate is being renewed, data that is not being modified is simply reused.

12. If a certificate template has been set to pending, an administrator must verify related information in the request — such as the identity of the requester — which is not controlled by the policy module.

13. The policy module returns the request to the Certificate Services engine, noting whether the request should be issued, should be denied, or is pending.

14. If the request has been approved, the Certificate Services engine constructs the certificate with the appropriate subject, validity period, and extensions.

15. The Certificate Services engine encodes, signs, and validates the certificate from information in the database to verify that the certificate is valid for the entire certificate chain and all defined purposes, and performs another revocation check before it issues the certificate.

16. The issued certificate is sent to the exit module, which saves the certificate to the certificates database and, depending on the template configuration, publishes it to the directory service.

    Note

    • If this is a local forest, the certificate is published to the user object. If this is a forest trust, the certificate is published to the contact object.

17. The exit module constructs and signs a response, which is returned to Xenroll.dll on the client. This response can include:

    • A CMS response.

    • A certificate BLOB.

    • A message indicating whether the certificate request has been approved, has been denied, or is pending.

    • An error message.

    • Request ID.

Xenroll places the certificate in the following folder:

C:\Documents and Settings\username\Application Data\Microsoft\SystemCertificates\My\Certificates

Certificate Enrollment and Renewal

Certificate enrollment and renewal in PKIs based on Windows Server 2003 Certificate Services varies depending on:

• The types of enrollment.

• The types of clients.

• Optional components involved in the enrollment and renewal process.

Types of Enrollment

Certificate Services supports three certificate enrollment and renewal methods:

• Autoenrollment

• Manual

• Custom

The methods used to process certificate enrollment and renewal will vary depending on the level of verification the CA must perform to authenticate the certificate requester’s identity.

Some enrollment and renewal requests can be approved or denied quickly by configuring the CA to simply verify whether the requester has a valid e-mail address or is a member of a domain.

If the certificate request involves a high-security application, on the other hand, an authorized enrollment agent might have to verify the requesters identity through other agencies or by conducting background checks, In such situations, manual certificate enrollment and renewal processes would be appropriate.

The enrollment and renewal options available to you will depend on the types of clients and CAs that you have.

Autoenrollment

Autoenrollment provides a quick and simple way to issue user and computer certificates and to benefit from applications that can use PKI.

Automatic certificate enrollment and renewal can be configured using the Automatic Certificate Request Setup Wizard (only for Windows Server 2003 and Windows XP user and computer certificates). Certificate autoenrollment also works in a Windows Server 2003 Terminal Services session if you use a Remote Desktop Protocol (RDP) 5.1 client.

On computers that are running Windows XP, you can automatically enroll users and computers for certificates, including smart card–based certificates. In contrast, the Windows 2000 Server family only supports certificate autoenrollment for computer certificates.

Certificate autoenrollment is based on the combination of Group Policy settings and version 2 certificate templates. This combination allows certificate enrollment and renewal in the background for computers and users at any time when you apply Group Policy.

To perform autoenrollment, the certificate requester must be registered and authenticated as either a user or computer in Active Directory.

You can configure computer autoenrollment for computer, domain controller, and IPSec certificates.

Certificate autoenrollment occurs at the end of the logon process. It also occurs every eight hours while a user is logged on. Users can also manually activate or cancel autoenrollment in the Certificates snap-in. When activated, autoenrollment determines through Active Directory queries whether any certificates need to be autoenrolled for the user or computer. If the computer is not networked, autoenrollment is not activated.

When autoenrollment is activated, Certificate Services first checks for any pending autoenrollment requests. If there are any pending requests, an enterprise CA can return a pending status with the request identifications. Autoenrollment attempts to complete pending request identifications by querying the CA that designated the requests as pending. If the certificate is denied, autoenrollment fails the request and an error is generated in the CA event log. If the certificate still has not been issued after a specified period of time — configurable in the registry — then the request is considered to have failed. If a certificate is issued, then it is added to the following folder:

Documents and Settings\username\Application Data\Microsoft\SystemCertificates

Certificates that are automatically issued are also automatically renewed from the enterprise CA that issued the certificates. Certificates can be manually renewed with the Certificate Renewal Wizard or through the Certificate Services Web Enrollment Support pages.

You can strengthen the security of autoenrollment by:

• Specifying in the certificate template that an additional signature with a specific OID must be included in the request.

• Requiring that a smart card be used to complete the autoenrollment process.

• Configuring the CA to place incoming requests in a pending queue and defining CA officers to verify and approve pending requests.

Manual enrollment

Manual enrollment can be configured using the Certificate Request and Certificate Renewal wizards, or using Windows Server 2003 Certificate Services Web Enrollment Support pages.

Certificate Request and Certificate Renewal wizards

You can request or renew certificates for Windows Server 2003 and Windows XP users and computers by using the Certificate Request Wizard and the Certificate Renewal Wizard that are available in the Certificates snap-in. These wizards do not function unless an enterprise CA is online to process and issue certificate requests and renewal requests. The ACLs for the certificate templates determine which user accounts or computer accounts can enroll for the various types of certificates.

You can request or renew certificates with an existing private and public key set or request that certificates be issued or renewed with a new private and public key set. However, do not renew certificates with the same private and public key sets if the maximum safe key lifetime would be exceeded.

Manual enrollment using Web Enrollment Support

You can have users submit their certificate requests by using a Web page. When a request is received by a CA, the CA verifies whether the requester is qualified to receive a certificate and then either approves or denies the request.

The Windows Server 2003 Certificate Services Web Enrollment Support pages are composed of Active Server Pages and ActiveX controls that provide a Web-based user interface to a CA. By default, the Web Enrollment Support pages are automatically installed on the computer where the CA is installed, but you can also install the Web Enrollment Support pages on another computer running Windows Server 2003.

You can use the Web Enrollment Support pages to perform the following tasks:

• Request and obtain a basic user certificate.

• Request and obtain other types of certificates by using advanced options.

• Request a certificate by using a certificate request file.

• Renew certificates by using a certificate renewal request file.

• Save a certificate request to a file.

• Save the issued certificate to a file.

• Check on pending certificate requests.

• Retrieve the CA’s certificate.

• Retrieve the latest CRL from the CA.

• Enroll for smart card certificates on behalf of other users (for use by trusted administrators).

The Web Enrollment Support pages that are installed for stand-alone CAs are similar to the pages that are installed for enterprise CAs, but they differ in that stand-alone CAs do not use certificate templates. For stand-alone CAs, all information about the certificate, including information about the requester, must be specified in the certificate request. The Web Enrollment Support pages for stand-alone CAs support a number of types of certificates that have much of the same functionality as certificate types that are based on templates.

You can deploy stand-alone CAs and Web Enrollment Support pages to issue most of the types of certificates that enterprise CAs can issue. However, certificates for logging on by using smart cards and for autoenrollment require an enterprise CA to issue and renew the certificates.

Custom enrollment and renewal applications

The standard enrollment and renewal methods that are available in Windows Server 2003 can meet a wide range of needs. However, if you have special needs, you can develop custom certificate enrollment and renewal applications. Windows Server 2003 Certificate Services supports industry-standard certificate requests by using remote procedure call (RPC) requests or HTTP requests. You can develop custom applications that make certificate requests to Certificate Services. For more information about developing custom applications with Windows Server 2003 Certificate Services, see “Programming Certificate Services” in the Cryptography collection of the Microsoft Platform SDK on MSDN.

Client Requirements for Enrollment

You can enroll version 2 templates with any computer running Windows XP or later through the default enrollment methods, including the Certificates snap-in, autoenrollment, Web Enrollment Support pages, or command-line tools.

A computer running Windows 2000 cannot use the Certificates snap-in to enroll a version 2 template. However, any client that is running Microsoft Internet Explorer 5.01 or later can use a version 2 template to enroll certificates through the Web enrollment methods and a downloaded ActiveX control. To download the ActiveX control on a client computer, it is necessary to log on as an administrator or power user on the local computer. In addition, clients running Windows 2000 can enroll version 2 templates through a connection to a server running Windows Server 2003 that has Terminal Services enabled.

Note

• An enrollment agent that enrolls certificates that are based on version 2 templates requires either a Windows XP or Windows Server 2003 enrollment station. There is no support to enroll version 2 templates with an enrollment agent on a Windows 2000 enrollment station. Nevertheless, certificates that are based on version 2 templates that have been enrolled through an enrollment agent on either a Windows XP or Windows Server 2003 enrollment station can be used on a Windows 2000 client computer.

If certificates have been enrolled with a Windows 2000 PKI where only version 1 templates were available, there is no immediate need to re-enroll or renew these certificates with version 2 templates.

The following three tables list different enrollment methods that are supported on computers that are running Windows 2000, Windows XP, or the Windows Server 2003 family. You can use scripted enrollment with support of CAPICOM and Xenroll. For more information, see “Programming Certificate Services” in the Cryptography collection of the Microsoft Platform SDK on MSDN.

Certificate Request Wizard Enrollment

	Version 1 template	Version 2 template
Self enrollment on a Windows 2000 workstation	Yes	No
Self enrollment through a Windows Server 2003 Terminal Server session	Yes	Yes
Self enrollment on a Windows XP workstation	Yes	Yes
Enrollment agent on a Windows 2000 workstation	No	No
Enrollment agent through a Windows Server 2003 Terminal Server session	No	No
Enrollment agent on a Windows XP workstation	No	No

Web Enrollment

	Version 1 template	Version 2 template
Self enrollment on a Windows 2000 workstation	Yes	Yes
Self enrollment through a Windows Server 2003 Terminal Server session	Yes	Yes
Self enrollment on a Windows XP workstation	Yes	Yes
Enrollment agent on a Windows 2000 workstation	Yes	No
Enrollment agent through a Windows Server 2003 Terminal Server session	Yes	Yes
Enrollment agent on a Windows XP workstation	Yes	Yes

Scripted Enrollment

	Version 1 template	Version 2 template
Self enrollment on a Windows 2000 workstation	Yes	Yes
Self enrollment through a Windows Server 2003 Terminal Server session	Yes	Yes
Self enrollment on a Windows XP workstation	Yes	Yes
Enrollment agent on a Windows 2000 workstation	Yes	Yes
Enrollment agent through a Windows Server 2003 Terminal Server session	Yes	Yes
Enrollment agent on a Windows XP workstation	Yes	Yes

Note

• Because a PKI is a forest resource, the Active Directory site structure is not taken into account when any kind of certificate is requested and issued. An Active Directory–integrated certificate requester enumerates all registered enrollment services in Active Directory and sends its request to a CA that can enroll the certificate type that the user wants. The client does not necessarily choose the closest CA, from a network perspective. Because of this, you should verify that the CA deployment ensures that any client has reliable network connectivity with a CA.

Client Requirements for Renewal

When a certificate comes to the end of its lifetime, it must be renewed or replaced to ensure that the certificate owner is able to continue with the certificate’s purpose.

In certificate renewal, the renewal requester already owns a certificate. The renewal takes the information of the existing certificate into account when the renewal request is submitted. A certificate can either be renewed with a new key or the existing key can be used for the renewed certificate.

If a certificate was enrolled with a version 2 template, it cannot be renewed if it was based on a version 1 template. However, a certificate that was enrolled with a version 1 template can be renewed with a certificate that was made from a version 2 template.

The following three tables list the different certificate renewal methods that are supported on computers that are running Windows 2000, Windows XP, or the Windows Server 2003 family.

Certificate Renewal Wizard Enrollment

	Version 1 templates	Version 2 templates
Self renewal on a Windows 2000 workstation	Yes	No
Self renewal on a Windows 2000 workstation with Windows Server 2003 Terminal Server session	Yes	Yes
Self renewal on a Windows XP workstation	Yes	Yes
Renewal with an enrollment agent on a Windows 2000 workstation	No	No
Renewal with an enrollment agent on a Windows 2000 workstation with Windows Server 2003 Terminal Server session	No	No
Renewal with an enrollment agent on a Windows XP workstation	No	No

Web Enrollment

	Version 1 templates	Version 2 templates
Self renewal on a Windows 2000 workstation	No	No
Self renewal on a Windows 2000 workstation with Windows Server 2003 Terminal Server session	No	No
Self renewal on a Windows XP workstation	No	No
Renewal with an enrollment agent on a Windows 2000 workstation	No	No
Renewal with an enrollment agent on a Windows 2000 workstation with Windows Server 2003 Terminal Server session	No	No
Renewal with an enrollment agent on a Windows XP workstation	No	No

Scripted Enrollment

	Version 1 templates	Version 2 templates
Self renewal on a Windows 2000 workstation	Yes	Yes
Self renewal on a Windows 2000 workstation with Windows Server 2003 Terminal Server session	Yes	Yes
Self renewal on a Windows XP workstation	Yes	Yes
Renewal with an enrollment agent on a Windows 2000 workstation	No	No
Renewal with an enrollment agent on a Windows 2000 workstation with Windows Server 2003 Terminal Server session	No	No
Renewal with an enrollment agent on a Windows XP workstation	Yes	Yes

Enrollment and Renewal Using Optional Components

Certificate enrollment and renewal rarely take place without the use of optional components, including Active Directory or another directory service, IIS, or another client acting as an enrollment agent. The following sections discuss the enrollment and renewal process for enterprise and stand-alone CAs where these optional components are being used.

Enterprise direct enrollment

The most basic enrollment method in the enterprise mode is direct enrollment. This is where the client makes a DCOM call directly to Certificate Services and passes the request over this call.

The client will have already retrieved any templates from Active Directory, and will have created the request, using an appropriate template. The following figure shows this configuration and the relationships between Certificate Services, Active Directory, and the client.

Enterprise Direct Enrollment

Enterprise indirect enrollment with enrollment agent

Another likely enrollment method in enterprise mode is for clients to use an enrollment agent. An enrollment agent is a person who is authorized with a special Enrollment Agent certificate to request certificates on behalf of a client. Most uses of enrollment agents will be for smart card clients, which can store the private key off the computer. The following figure shows this configuration and the relationship between the enrollment agent, Certificate Services, and Active Directory.

Enterprise Enrollment with Enrollment Agent

Before any enrollment occurs, the enrollment agent will have retrieved any certificate templates from the registry of the server that hosts the CA. When a user needs to enroll, the enrollment agent uses the certificate template to create a certificate request and signs the request with the Enrollment Agent certificate. The enrollment agent computer then makes an authenticated DCOM call to Certificate Services. The enrollment agent then sends the certificate request over this DCOM call.

Unlike in the Web enrollment configurations, the enrollment agent computer does not impersonate the client. Instead, the DCOM call made to Certificate Services will have the enrollment agent computer as the caller name. This is important to note, because the certificate request will have the client’s identifying information, which will not match the DCOM caller name. Certificate Services would normally reject this mismatch. However, the Enrollment Agent certificate used to sign the request contains the Enrollment Agent OID, which is explicitly trusted to issue certificates on behalf of others. As a result, Certificate Services will accept the request.

Stand-alone Web enrollment

The most common method of enrollment in the stand-alone mode is by an HTML interface, provided by a set of Web pages running on a server running IIS. This is called Web enrollment.

IIS can be installed on the same computer as Certificate Services or on a separate computer. In either case, when the client needs a certificate and must enroll in a hierarchy, it connects to IIS by HTTP and authenticates to the server in a manner required by IIS. The client then creates a certificate request and sends it over the HTTP connection to the server by way of a remote DCOM interface. This HTTP connection is most often secured by Transport Layer Security (TLS). IIS then receives the request and passes it by way of a local DCOM interface to Certificate Services.

The following figure shows this configuration and the relationship between IIS, Certificate Services, and the client.

Stand-alone Web Enrollment

Enterprise Web enrollment

Enterprise mode Web enrollment also can be configured with IIS and Certificate Services running on the same computer or on separate computers.

Before enrollment occurs, the client will have retrieved any certificate templates from Active Directory. When the client needs to enroll, it will make an HTTP connection to IIS and authenticate in some manner. The computer running IIS must be trusted for delegation in Active Directory. This allows IIS to impersonate the client and make an authenticated DCOM call to Certificate Services. IIS then passes the request over this DCOM call.

The following figure shows the relationship between IIS, Certificate Services, and the client.

Enterprise Web Enrollment

How Certificates Are Revoked

To help maintain the integrity of an organization’s public key infrastructure (PKI), the administrator of a CA must revoke the subject’s certificate if the subject leaves the organization, if the subject’s private key has been compromised, or if some other security-related event dictates that it is no longer desirable to have the subject’s certificate considered valid. When a certificate is revoked by a CA, it is added to that CA’s certificate revocation list (CRL).

CRLs are complete, digitally-signed lists of unexpired certificates that have been revoked. The CRL is retrieved by clients who can then cache it (based on the configured lifetime of the CRL) and use it to verify certificates presented for use.

Windows Server 2003 Certificate Services supports industry standard X.509 version 2 CRLs. Each CA maintains a CRL for the certificates it issues and publishes the CRL to CRL distribution points, which can include Web pages, network shares, or Active Directory. An X.509 version 3 certificate usually contains the CRL distribution point for its issuing CA.

Note

• Non-Microsoft products can use CRLS published by CAs running on Windows operating systems to provide revocation information in other formats, such as Online Certificate Status Protocol (OCSP), Simple Certificate Validation Protocol (SCVP), and XML Key Management Specification (XKMS).

By default, enterprise CAs publish CRLs once per week to Active Directory. By default, stand-alone CAs publish CRLs once per week to the following folder on the CA server:

systemroot\Certsrv\Certenroll

Delta CRLs

Microsoft Windows Server 2003 can publish large CRLs, generating large amounts of directory replication traffic. For a CA with a large population of users, this list can become as large as 1 MB. Many applications require up-to-date revocation status information, which requires the CA to publish the CRLs frequently. Even when there are no new revocation changes, the CA has to republish the entire list so that applications have the latest information.

For this reason, a new type of CRL called a delta CRL has been introduced with Windows Server 2003 Certificate Services. Delta CRLs are CRLs that contain the list of changes in revocation status that have occurred since the last base CRL was published.

Note

• Delta CRLs are not necessarily relative to the last published CRL, but always relative to a designated base CRL. Delta CRLs are not aggregated, and the client always uses a pair of the latest delta CRL and a valid base CRL.

It is important that a relying party (client) has access to both a base and delta CRL. If the base CRL is not available for the client’s, an error will occur with the delta CRL’s processing. When an error occurs, the client falls back to the base CRL.

Reasons for Revocation

When a certificate is revoked, a certificate issuer can specify why the certificate was revoked. This is done by specifying a revocation reason code. The reason codes are defined by RFC 3280 and include:

• KeyCompromise. The token or disk location where the private key associated with the certificate has been compromised and might be in the possession of an unauthorized individual. This can include cases where a laptop is stolen or a smart card is lost.

• CACompromise. The token or disk location where the CA’s private key is stored has been compromised and might be in the possession of an unauthorized individual. When a CA’s private key is revoked, all certificates issued by the CA that have been signed using that private key are considered revoked, as well.

• AffiliationChanged. The user has terminated his or her relationship with the organization indicated in the DistinguishedName property of the certificate. This reason code is typically used when an individual has been terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires that a different certificate be issued by a departmental CA.

• Superseded. A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This reason code is typically used when a smart card fails, the user forgets a password, or the user has changed their legal name.

• CessationOfOperation. If a CA is decommissioned, the CA’s certificate should be revoked with this reason code. Do not revoke the CA’s certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.

• CertificateHold. A temporary revocation that indicates that a CA will not vouch for a certificate at a specific point in time. After a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another reason code, or unrevoked and returned to use.

  Note

  • Although CertificateHold allows a certificate to be unrevoked, it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.

• RemoveFromCRL. If a certificate is revoked with the CertificateHold reason code, it is possible to unrevoke a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL.

  Note

  • This is specific to the CertificateHold reason and is only used in delta CRLs.

• Unspecified. You can revoke a certificate without providing a specific reason code. Although it is possible to revoke a certificate with the Unspecified reason code, this is not recommended, because it does not provide an audit trail as to why a certificate is revoked.

The Revocation Checking Process

Prior to checking the status of a certificate, the client checks the certificate to ensure that the certificate is trusted and valid. For more information about how certificate trust is established, see How Certificates Work.

Every issued certificate has a defined period during which the issuing CA will vouch for the validity of the certificate. The validity period is defined in two fields in the issued certificate:

• NotBefore. This field defines the date and time on which the certificate’s validity period begins.

• NotAfter. This field defines the last date on which the certificate is considered valid by the issuing CA. The NotAfter date cannot be set to a date later than the NotAfter date defined in the issuing CA’s certificate.

If CRL-based status checking is used and the certificate is found to have a valid time, the presented certificate is examined to see if it contains a CRL distribution point extension. The CRL distribution point extension indicates both the protocol that must be used to retrieve the CRL (HTTP, FTP, LDAP, or FILE) and the location where the CRL is stored (represented as a URL).

Using this information, CryptoAPI searches the local certificate stores and the local cache for any CRL signed by the issuer (that is the CA) of the certificate that is to be validated. A cached version of a current CRL will always be used (so long as it is valid), rather than downloading the same CRL again. The following logic is used to evaluate the CRL:

• If a CRL is found and the certificate’s serial number is listed in the CRL, then the certificate will be considered revoked.

• If the CRL is expired and the certificate is listed in the CRL with any reason other than CertificateHold, the certificate will be considered to be revoked and no attempt will be made to retrieve a new CRL.

• If the certificate is not listed in the CRL, or if the reason code is CertificateHold**,** then a new CRL will be retrieved from the URLs listed in the certificate’s CRL distribution point extension. The new CRL is fetched only if it is past the NextUpdate field in the currently held CRL. The new CRL is checked to determine if the certificate is revoked. If the original reason was CertificateHold, the CRL is checked to determine if the certificate is unrevoked by looking for the RemoveFromCRL reason code.

• If the CRL cannot be obtained, the client will generate a Server offline error.

CRL Format

A version 2 CRL includes the following fields:

• Version. The version of formatting used for the CRL.

• Issuer. The issuing CA’s distinguished name (DN) represented using an X.500 DN such as CN=TestCA,OU=PKI,DC=nwtraders,DC=com.

• This Update. The date that this CRL was issued. Universal Time Coordinate (UTC) format is used for dates up to the year 2049. Generalized Time format is used for dates of 2050 and beyond.

• Next Update. The date at which the next CRL will be issued. The same date formatting rules are used as for This Update.

• Revoked Certificates. A sequence of zero or more revoked certificates with the following fields represented for each revoked certificate.

• Certificate Serial Number. The serial number assigned by the issuing CA for each revoked certificate.

• Revocation Date. The date at which the revocation took place.

• CRL Entry Extension. An optional field that contains version 2 extensions for CRLs that provides additional information about a single CRL entry.

• ReasonCode. Identifies the reason for the certificate revocation. Reasons can include: Unspecified, KeyCompromise, CACompromise, AffiliationChanged, Superseded, CessationOfOperation, CertificateHold, and RemoveFromCRL.

• HoldInstructionCode. This option, only defined in the PKI x.509 format, indicates the action to be taken if the CertificateHold is entered in the ReasonCode field. This extension is not supported by a Windows Server 2003 CA.

• InvalidityDate. The date on which it is known, or suspected, that the private key associated with the certificate was compromised.

• CertificateIssuer. An optional field used to indicate the CA that issued the certificate if indirect CRLs are implemented. A Windows Server 2003 CA does not use this extension, but it is supported by Windows XP clients.

• AuthorityKeyIdentifier. A numeric representation of the issuer name and serial number from the CRL issuer’s certificate that is used in the certification chain building process.

• IssuerAltName. An optional field used to associate alternative identities with the issuer. This can contain a DNS name or a Uniform Resource Indicator (URI). A Windows Server 2003 CA does not use this extension, but it is supported by Windows XP clients.

• CRLNumber. A monotonically increasing sequence number that indicates the version of the CRL since the first CRL was published.

• IssuingDistributionPoint. Identifies the CRL distribution point if CRL partitioning is implemented. For example, the CRL can be partitioned so that end-entity, CA certificate, or specific reason code revocations are published at a specific distribution point. A Windows Server 2003 CA does not use this extension, but it is supported by Windows XP clients.

  Note

  • Windows Server 2003 does not support partitioning CRLs by reason code.

• deltaCRLIndicator. Indicates that the CRL is a delta CRL. This also specifies the minimum CRL number of base CRL with which the delta CRL can be combined to obtain the complete state of the CA.

• Signature (Issuer Signature Algorithm). Identifies the algorithm used to certify the CRL.

• SignatureValue. The actual digital signature computed using the indicated Issuer Signature Algorithm on the ASN.1 DER encoded CRL. The value is encoded as a bit string and omits the signature algorithm and SignatureValue fields.

CRL Distribution Point Extensions

When a CA issues a certificate, it can place a CRL distribution point extension in the new certificate that points to the relevant CRL for the certificate containing the extension only.

For example, the root CA issues certificates with a CRL distribution point that points only to the root CA’s CRL. A first level subordinate CA issues certificates with a CRL distribution point that points only to the first level subordinate CA’s CRL. Finally, a second level CA issues certificates with a CRL distribution point that points only to the second level CA’s CRL.

Note

• For more information, see Trusted root CA and CRL distribution point containers earlier in this subject.

When the default revocation provider is used, the full certificate chain must be built first, then each certificate in the chain is searched for a CRL distribution point extension to fetch a CRL that will prove the revocation status of that one certificate only. The Windows client does not support a certificate status model where one CA can supply information about revoked certificates that were issued by a different CA. This is because the key that was used to sign the certificate in question must be the same key used to sign the CRL that is used to verify revocation status of the certificate.

The CRL distribution point might point to both primary and alternative locations for CRL retrieval. When a client must acquire the latest CRL, the CRL distribution point extension in a certificate is checked and the CRL retrieval is attempted by contacting the URLs in the CRL distribution point extension. If the name resolution of a fully qualified domain name fails, or the CRL is unavailable, the client tries the next CRL distribution point from the CRL distribution point extension field.

Note

• If the client is able to resolve the name of the CRL distribution point but the CRL is not physically available, it might take a significant period of time before the timeout threshold is reached. Windows XP provides enhancements in reducing the timeout threshold as well as CRL unavailability detection.

If the CRL distribution point extension is not available in a certificate, then CryptoAPI will only check the local certificate store and cache for a CRL. If a local CRL is available, it will be checked despite the absence of a CRL distribution point extension. However, a specific application must specify whether or not to demand a revocation check of a certificate.

CRL Publication

A CRL distribution point URL can specify several protocols for CRL access. These include:

• HTTP. HTTP websites can store the updated CRLs.

• LDAP. A Lightweight Directory Access Protocol database can contain the updated CRLs.

• File. CRLs can be accessed using the Server Message Block (SMB) protocol.

• FTP. File Transfer Protocol servers can be used to distribute updated CRLs. The CRL, by default, is published in two locations by a Microsoft enterprise CA:

  • https://*CAName/*certenroll/CRLName

  • LDAP:///CN=CAName,CN=CAComputerName,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration, DC=ForestRootDomain,DC=TLD

When a CRL is published, the CRL will take on different names, depending on whether the CA’s certificate has been renewed, and whether the existing private keys are re-used when the certificate is renewed. The following table outlines some examples of CRL names that are automatically generated for a Windows Server 2003 CA.

Auto-generated CRL File Names

Scenario	Name of the CRL File	Name of Delta CRL File	CA Version
A certification authority named IssuingCA that has never had its CA certificate renewed	issuingca.crl	issuingca+.crl	0.0
A certification authority named IssuingCA that has been renewed once with the same key	issuingca.crl	issuingca+.crl	0.0
A certification authority named IssuingCA that has been renewed once with a new key	issuingca.crl issuingca(1).crl	issuingca+crl issuingca(1)+.crl	2.2
A certification authority named IssuingCA that has been renewed three times, twice with a new key	issuingca(3).crl	issuingca(3)+.crl	3.3

How Key Pairs Are Stored

Windows Server 2003 and Windows XP store a user’s public key certificates in the user’s personal certificate store. Certificates are stored in plaintext because they are public information, and they are digitally signed by certification authorities to protect against tampering.

User certificates for each user profile are located in the following folder:

systemroot\Documents and Settings\username\Application Data\Microsoft\SystemCertificates\My\Certificates

These certificates are written to the users personal store in the system registry each time the user logs on to the computer. If roaming profiles are being used, users’ certificates are stored on the file server where the roaming user profile is stored

Private keys for the Microsoft RSA-based cryptographic service providers (CSPs), including the Base CSP and the Enhanced CSP, are located in the user profile under:

systemroot\Documents and Settings\username\Application Data\Microsoft\Crypto\RSA

In the case of a roaming user profile, private keys reside in the RSA folder on the file server where the roaming user profile is stored and are downloaded to the user’s computer until the user logs off or the computer is restarted.

Because private keys must be protected, all files in the RSA folder are automatically encrypted by using a random symmetric key called the user’s master key. The user’s master key is 64 bytes in length and is generated by a strong random number generator. 3DES keys are derived from the master key and are used to protect private keys. The master key is generated automatically and is periodically renewed. It encrypts each file in the RSA folder automatically as the file is created.

The Data Protection API automatically encrypts the user’s master key or keys. Master keys are stored in the user profile under

systemroot\Documents and Settings\username\Application Data\Microsoft\Protect

For a domain user who has a roaming profile, the master key is located in the user’s profile and is downloaded to the user’s profile on the local computer until the computer is restarted.

Certificate Services Key Storage

Certificate Services must maintain a key pair for signing certificate requests. The public part of that key pair resides in a certificate located in the My folder of the local computer. The private part of that key pair resides in the cryptographic service provider (CSP) containers.

As shown in the following figure, Certificate Services can have multiple certificates that contain the same public key and, thus, use the same private key. The reasons for this might be because of certificate expiration or varying certificate attributes. There can be up to a maximum of 65,536 Certificate Services certificates.

Each private key has only one active base CRL and one active delta CRL that contains revoked certificates that were signed by that key. Expired CRLs can be automatically deleted upon CRL publication if there is an existing, non-expired CRL for that private key.

Relationship of Certificates, Private Keys, and CRLs

Key Archival and Key Recovery

Subjects can lose their private keys in a variety of ways, such as accidental deletion or deliberate misuse. An administrator might also want to recover the key of a particular subject to access data protected by that key. Key recovery can be used whenever the key archival process has stored the subject’s private key.

Windows Server 2003, Enterprise Edition can be configured to archive the private key of a specific certificate when the certificate is issued. This private key archive allows the key to be recovered at a later time if the private key is lost. This process is implemented in two separate phases: key archival and key recovery.

The following sections detail how the key archival and key recovery processes work in Windows Server 2003.

Key Archival Process

1. The client finds a CA in the Active Directory (enrollment services container in the configuration partition) and makes an authenticated DCOM connection to the CA.

2. The client requests the CA’s encryption certificate.

3. The CA sends the encryption certificate to the client.

4. The client validates that the CA’s encryption certificate has been signed by the same key as the CA signing certificate and performs a revocation status check. This ensures that only the intended CA can decrypt the certificate request containing the private key.

5. The client encrypts the private key corresponding to the request with the CA encryption certificate public key, builds a Certificate Management protocol using CMS (CMC) request, and sends the full CMC certificate request to the CA.

6. The CA validates that the encrypted private key cryptographically pairs with the public key in the certificate request.

7. The CA validates the signature on the request with the public key in the request.

8. The CA encrypts the private key from the user request with a random 3DES symmetric key and then encrypts the symmetric key with one or more key recovery agent public keys.

9. The CA saves the encrypted key BLOB containing the encrypted private key and the symmetric key encrypted with one or more key recovery agent public keys to the CA database.

10. The CA processes the certificate request normally.

11. The CA responds to the client with a full PKI response in CMC.

    Note

    • Only RSA encryption keys can be archived in the CA database. Signature only keys as well as non-RSA key pairs will not be archived. Denied and resubmitted requests will also not archive private keys.

Key Recovery Process

Key recovery is initiated by an end-entity that has lost access to a private key. The end-entity is typically a user or an administrator of a computer who notifies a key recovery agent about lost private key material. The key recovery agent must have a key recovery agent certificate that was used to protect the symmetric key on the private key of the user. The key recovery agent can also be a Certificate Manager (an officer on the CA that issued the certificate in question to the user).

Note

• Each organization should determine whether key recovery agent and Certificate Manager should be combined into one role or should be separate roles.

The actual key recovery process first retrieves the PKCS #7–encrypted recovery BLOB from the database. The encrypted BLOB is protected by ACLs to ensure that only a valid Certificate Manager is able to copy the BLOB from the database. Encrypted BLOBs in the database contain the issuer name and serial number of each key recovery agent certificate for key recovery agent identification purposes during recovery.

The recovery BLOB consists of wrapping the encrypted PKCS #7 certificate in the database in another signed PKCS #7 certificate. This enables a number of certificates to be included in the recovery BLOB. The returned certificates include the full chain of the user certificate that is to be recovered, the chain of the signing CA certificate (which might differ from the CA certificate under which the user certificate was issued), and the key recovery agent certificates to which the key was encrypted.

Related Information

The following resource contains additional information that is relevant to this section:

• Certificates Technical Reference