How Certificates Work

Artigo
10/29/2008

How Certificates Work

In this section

Certificate Architecture
Certificate Processes and Interactions
Related Information

Digital certificates are electronic credentials that are used to assert the online identities of individuals, computers, and other entities on a network. Digital certificates function similarly to identification cards such as passports and drivers licenses. They are issued by certification authorities (CAs) that must validate the identity of the certificate-holder both before the certificate is issued and when the certificate is used. Common uses include business scenarios requiring authentication, encryption, and digital signing.

The following sections provide an in-depth view of how certificates work in an optimal environment. An optimal environment for certificates includes the following:

A public key infrastructure (PKI) that has been designed, planned, and deployed with appropriate security measures to minimize the risk that CAs can be compromised.
Certificate configurations have been planned so that only intended users can initiate certificate use, and certificates can only be used for the purposes intended.

Certificate Architecture

A digital certificate binds a user, computer, or service’s identity to a public key by providing information about the subject of the certificate, the validity of the certificate, and applications and services that can use the certificate. Certificates issued in Windows Server 2003 and earlier PKIs are structured to meet these objectives based on standards established by the Public-Key Infrastructure (X.509) Working Group (PKIX) of the Internet Engineering Tasks Force (IETF). The following figure shows the contents of X.509 version 3 certificates as implemented in Windows Server 2003.

X.509 Version 3 Certificate

Certificado X.509 versão 3

X.509 version 3 certificates are the current certificate format in a Windows Server 2003 PKI. Version 3 certificates support the following fields that have been supported since X.509 version 1:

Subject. Provides the name of the computer, user, network device, or service that the CA issues the certificate to. The subject name is commonly represented by using an X.500 or Lightweight Directory Access Protocol (LDAP) format.
Serial Number. Provides a unique identifier for each certificate that a CA issues.
Issuer. Provides a distinguished name for the CA that issued the certificate. The issuer name is commonly represented by using an X.500 or LDAP format.
Valid From. Provides the date and time when the certificate becomes valid.
Valid To. Provides the date and time when the certificate is no longer considered valid.
Note
- The date when an application or service evaluates the certificate must fall between the Valid From and Valid To fields of the certificate for the certificate to be considered valid.
Public Key. Contains the public key of the key pair that is associated with the certificate.

In addition to the version 1 fields, X.509 version 3 certificates include extensions that provide additional functionality and features to the certificate. These extensions are optional and are not necessarily included in each certificate that the CA issues:

Subject alternative name. A subject can be presented in many different formats. For example, if the certificate must include a user’s account name in the format of an LDAP distinguished name, e-mail name, and a user principal name (UPN), you can include the e-mail name or UPN in a certificate by adding a subject alternative name extension that includes these additional name formats.
CRL distribution points (CDP). When a user, service, or computer presents a certificate, an application or service must determine whether the certificate has been revoked before its validity period has expired. The CDP extension provides one or more URLs where the application or service can retrieve the certificate revocation list (CRL) from.
Authority Information Access (AIA). After an application or service validates a certificate, the certificate of the CA that issued the certificate — also referred to as the parent CA — must also be evaluated for revocation and validity. The AIA extension provides one or more URLs from where an application or service can retrieve the issuing CA certificate.
Enhanced Key Usage (EKU). This attribute includes an object identifier (OID) for each application or service a certificate can be used for. Each OID is a unique sequence of numbers from a worldwide registry.
Certificate policies. Describes what measures an organization takes to validate the identity of a certificate requestor before it issues a certificate. An OID is used to represent the validation process and can include a policy-qualified URL that fully describes the measures taken to validate the identity.

Certificate Templates

Windows 2000 and Windows Server 2003 Enterprise CAs use certificate templates, stored in the Active Directory directory service, to provide the default attributes for a certificate. These attributes include authorized uses for the certificate, the cryptographic algorithms used with the certificate, the format of the subject, the public key length, issuance requirements, and the certificate lifetime.

Certificate templates are configured on an enterprise CA and are applied to accept or reject incoming certificate requests. Only enterprise CAs can issue certificates based on certificate templates. Certificate template information is stored in Active Directory in the container

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

where ForestRootNameDN is the LDAP distinguished name of the forest root domain.

Computers running Windows Server 2003 support two types of certificate templates: version 1 and version 2. Servers running Windows 2000 only support the issuance of certificates that are based on version 1 certificate templates.

When the first enterprise CA is installed in the forest, version 1 templates are created by default. Unlike version 2 templates, these cannot be modified or removed. In Windows 2000, certificate management was very limited because only the templates’ security permissions could be set.

Version 1 templates are provided for backward compatibility, and support many general needs for subject certification. For example, there are certificates that allow Encrypting File System (EFS) encryption, client authentication, smart card logon, or server authentication.

Version 2 certificate templates allow you to define specific attributes for certificates that meet your organization’s business needs. Version 2 template definitions are stored in Active Directory, although you can create and modify version 2 templates at any computer running Windows Server 2003 or Windows XP Professional with the Windows Server 2003 Administration pack installed. Certificates based on version 2 templates can only be issued by a CA running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.

Types of Certificate Templates

Only a few certificate templates are assigned to a fresh CA installation by default. Several predefined certificate templates and custom certificate templates must be assigned explicitly if needed.

There are two categories of certificate templates: certificate templates issued to users and certificate templates issued to computers. Only computers can use certificates that are issued to computers; likewise, only users can use certificates that are issued to users. Another way to distinguish between certificate templates is based on how they are used:

Single function. A certificate template can be highly restricted and only be used for a single function. For example, you can use a Basic EFS certificate template only to encrypt and decrypt files that are protected by using EFS.
Multiple functions. You can use a certificate template for multiple functions. For example, you can use a user certificate template to encrypt and decrypt files, authenticate with a server, and send and receive secure e-mail by using the same certificate.

After the upgrade to Windows Server 2003 certificate templates is completed, the following preconfigured certificate templates are listed in the Certificate Templates Microsoft Management Console (MMC).

Windows Server 2003 Certificate Templates

Name	Description	Key Usage	Subject Type	Published to Active Directory
Administrator	Allows trust list signing and user authentication	Signature and encryption	User	Yes
Authenticated Session	Subject can authenticate to a Web server	Signature	User	No
Basic EFS	Used by EFS to encrypt data	Encryption	User	Yes
CA Exchange	Used to store keys that are configured for private key archival	Encryption	Computer	No
CEP Encryption	Allows the holder to act as a registration authority (RA) for simple certificate enrollment protocol (SCEP) requests	Encryption	Computer	No
Code Signing	Used to digitally sign software	Signature	User	No
Computer	Allows a computer to authenticate itself on the network	Signature and encryption	Computer	No
Cross-Certification Authority	Used in cross-certification and qualified subordination	Signature	CrossCA	Yes
Directory E-mail Replication	Used to replicate e-mail within Active Directory	Signature and encryption	DirEmailRep	Yes
Domain Controller	All-purpose certificates held by domain controllers	Signature and encryption	DirEmailRep	Yes
Domain Controller Authentication	Used to authenticate Active Directory computers and users	Signature and encryption	Computer	No
EFS Recovery Agent	Allows the subject to decrypt files previously encrypted with EFS	Encryption	User	No
Enrollment Agent	Used to request certificates on behalf of another subject	Signature	User	No
Enrollment Agent (Computer)	Used to request certificates on behalf of another computer subject	Signature	Computer	No
Exchange Enrollment Agent (Offline request)	Used to request certificates on behalf of another subject and supply the subject name in the request	Signature	User	No
Exchange Signature Only	Used by Microsoft Exchange Key Management Service to issue certificates to Exchange users for digitally signing e-mail	Signature	User	No
Exchange User	Used by Microsoft Exchange Key Management Service to issue certificates to Exchange users for encrypting e-mail	Encryption	User	Yes
IPSEC	Used by IP Security (IPSec) to digitally sign, encrypt, and decrypt network communication	Signature and encryption	Computer	No
IPSEC (Offline request)	Used by IP Security (IPSec) to digitally sign, encrypt, and decrypt network communication when the subject name is supplied in the request	Signature and encryption	Computer	No
Key Recovery Agent	This certificate can recover private keys archived on the certification authority.	Encryption	KRA	Yes
Root Certification Authority	Used to prove the identity of the root certification authority	Signature	CA	Yes
Router (Offline request)	Used by a router when requested through SCEP from a CA that holds a CEP Encryption certificate	Signature and encryption	Computer	No
Smartcard Logon	Allows the holder to authenticate using a smart card	Signature and encryption	User	No
Smartcard User	Allows the holder to authenticate and protect e-mail using a smart card	Signature and encryption	User	Yes
Subordinate Certification Authority	Used to prove the identity of the root certification authority, issued by the parent or root certification authority	Signature	CA	Yes
Trust List Signing	The holder can digitally sign a trust list.	Signature	User	No
User	Certificate to be used by users for e-mail, EFS, and client authentication	Signature and encryption	User	Yes
User Signature Only	Allows users to digitally sign data	Signature	User	No
Router (Offline request)	Used by a router when requested through SCEP from a CA that holds a CEP Encryption certificate	Signature and encryption	Computer	No
Smartcard Logon	Allows the holder to authenticate using a smart card	Signature and encryption	User	No
Smartcard User	Allows the holder to authenticate and protect e-mail using a smart card	Signature and encryption	User	Yes
Subordinate Certification Authority	Used to prove the identity of the root certification authority, issued by the parent or root certification authority	Signature	CA	Yes
Trust List Signing	The holder can digitally sign a trust list.	Signature	User	No
User	Certificate to be used by users for e-mail, EFS, and client authentication	Signature and encryption	User	Yes

Certificate Template Options

The following sections detail the specific information that can be configured for a version 2 certificate template by using the Certificate Templates Microsoft Management Console (MMC) snap-in.

Note

Because certificate templates exist only once within a forest, all changes made to the templates apply on a forest-wide level. If several CAs exist within one forest, templates can be assigned to CAs. Nevertheless, all CAs within a forest use one set of templates.

The General tab is the first tab that appears when a certificate template is duplicated. The General tab allows administrators to configure the following attributes of the certificate template:

Template display name, The display name shown in the Certificate Templates, Certificates, and Certification Authority snap-ins.
Template name. The name of the certificate template object created in the CN=Certificate Templates,CN=Public Key Services,CN=Services,DC=ForestRootDomain container.
Validity period. Defines the validity period for an issued certificate. The validity period must not be greater than the validity period of the CA’s certificate.
Renewal period. The time before the validity period expires when the certificate will be renewed, if reenrollment is supported for the certificate template. By default, the minimum renewal period is 80 percent of the certificate lifetime or 6 weeks, whichever is greater.
Publish options. Determines whether the certificate can be published to Active Directory. Certificates are published as an attribute of the security principal contained in the subject of the issued certificate.
Reenrollment option. If the certificate template is published to Active Directory, this prevents reenrollment if a valid certificate of the same certificate template exists for the security principal indicated in the subject attribute of the certificate.
Note
- Re-enrollment settings mainly affect auto-enrollment design in a Windows Server 2003 network.

Request Handling

The options on the Request Handling tab define the purpose of the certificate template, the supported cryptographic service providers (CSPs), minimum key length, exportability, auto-enrollment settings, and whether strong private key protection should be required.

Certificate Purposes

The certificate purpose defines the intended primary use of the certificate. The certificate purpose can be one of four settings:

Encryption. A certificate with this purpose will contain cryptographic keys for encryption and decryption.
Signature. A certificate with this purpose will contain cryptographic keys for signing data only.
Signature and encryption. A certificate with this purpose covers all primary uses of a certificate’s cryptographic key, including encryption of data, decryption of data, initial logon, or digitally signing data.
Signature and smartcard logon. A certificate with this purpose allows for initial logon with a smart card, and digitally signing data; it cannot be used for data encryption.

Archive Settings

When subject’s lose their private keys due to the user profile becoming corrupted or being lost, or when a computer is stolen, any information that was persistently encrypted by using the corresponding public key is inaccessible. To help avoid this, Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition make it possible for a subject’s encryption keys to be archived in the CA database when certificates are issued. If subject’s lose their encryption keys, the information can be retrieved from the database and securely provided to the subject’s. This allows the encrypted information to be recovered instead of lost.

Note

Signing keys cannot be archived. If signing keys are lost, the user must request a new set of signing keys.

The following key archival settings are defined on the Request Handling tab:

Archive subject’s encryption private key. If the issuing Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition CA is configured for key archival, the subject’s encryption key will be archived.
Allow private key to be exported. When this option is specified, the subject’s private key can be exported for backup or transportation.
Deleting revoked or expired certificates (do not archive). If a certificate is renewed with autoenrollment due to expiration or revocation, the previously issued certificate is removed from the subject’s certificate store. By default, the certificate is archived.
Include symmetric algorithms allowed by the subject. When the subject requests the certificate, they can supply a list of supported symmetric algorithms. This option allows the issuing CA to include those algorithms in the certificate, even if they are not recognized or supported by that server. The algorithms are used by applications like secure e-mail.

To enable key archival and recovery, the following configuration options must be set in the certificate template and at the Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition CA:

The specific certificate template must be configured to allow key archival.
One or more key recovery agents must be identified on the CA, and key recovery agent certificates must be issued to those agents.
Key archival must be configured on the CA.

User Input Settings

The Request Handling tab also allows several user input settings to be defined for a certificate template. These settings can be used to implement strong private key protection. These settings include:

Enroll subject without requiring any user input. This option allows auto-enrollment without any user interaction and is the default setting for both computer and user certificates. This option must not be enabled for computer certificates.
Prompt the user during enrollment. Although useful when testing initial auto-enrollment deployments, typically, this option is disabled. By disabling this option, users do not have to provide any input for the installation of a certificate based on the certificate template.
Prompt the user during enrollment and require user input when the private key is used. This option enables the user to set a strong private key protection password on the user’s private key when the key is generated, and requires the user to use it whenever the certificate and private key are used. This option must not be enabled for computer certificates or smart card user certificates.
Note
- To enable smart card auto-enrollment, the Prompt the user during enrollment check box must be selected so that the user is prompted to insert the smart card in the smart card reader when required.

Other Request Handling Settings

In addition to key archival settings, some general options that affect all certificates, including those that do not enable key archival, can be defined. These include:

Minimum key size. This specifies the minimum size, in bits, of the key that will be generated for this certificate.
Cryptographic service providers. This is a list of CSPs that will be used to enroll certificates for the given template. The list is compiled from all CSPs that are available on the computer that is used to maintain the certificate template. Selecting one or more CSPs configures the certificate to only work with those CSPs. If you do not select a specific CSP, the certificate enrollment will work with any installed CSP, but will use the first CSP from the enumeration list. The CSP must be installed on the client workstation for the CSP to be used during enrollment. If a specific CSP is chosen and not available on a client computer, enrollment will fail. If you need to restrict the CSP choice to a specific third party CSP, you must have the CSP installed on the computer that is used to configure the certificate template.
Note
- For more information, see “CSPs” later in this section.

Subject Name

When configuring a certificate template, subject name guidelines must be defined. The subject name of a certificate identifies the user, computer, or service that the certificate represents. This is included in the issued certificate template and must uniquely identify the subject. The subject name can either be built automatically during the certificate request by using the authentication name of the subject or explicitly defined by the subject and included in the certificate request. Windows obtains the attributes as defined in the CA’s registry from Active Directory for automatic building. To provide the name manually, the subject supplies that information in the certificate request, for example by using the Web-based enrollment pages.

A number of options can be included with the subject name, in addition to specific configuration settings for the subject name when the subject name is built from Active Directory information during the certificate request process. The format of the subject name can be defined as:

None. Does not enforce any name format for this field.
Common name. The CA creates the subject name from the common name (CN) of the requestor obtained from Active Directory. These should be unique within a domain, but might not be unique within an enterprise.
Fully distinguished name. The CA creates the subject name from the fully distinguished name obtained from Active Directory. This guarantees that the name is unique within an enterprise.

In addition, you can choose to include the e-mail name in the subject name. This information is populated from the e-mail attribute of an account, and is included with either the CN or fully distinguished name as part of the subject name.

In addition to the subject name, you can also choose which name formats are included in the alternate subject name attributes of issued certificates. The alternate subject name formats that are available include:

E-mail name. If the e-mail name field is populated in the Active Directory user object, that e-mail name will be used for user accounts.
Note
- The e-mail name is required for user certificates. If the e-mail name is not populated for a user in Active Directory, the certificate request by that user will fail.
Domain Name System (DNS) name. The FQDN of the subject that requested the certificate is used for computer accounts.
User principal name (UPN). The UPN is part of the Active Directory user object and will be used for user accounts.
Service principal name (SPN). The SPN is part of the Active Directory computer object and will be used for computer accounts.

Usually, a subject cannot request a certificate that uses a nonmatching subject name. For example, user1@example.com would not be allowed to request a certificate with a subject name of user2@example.com.

The only subject that can request a certificate for another user is one who holds a certificate based on the Enrollment Agent template. That subject can request certificates on behalf of any other subject. For example, an enrollment agent can request Smart Card User or Smart Card Logon certificates on behalf of other users.

The only case in which a subject can request a certificate with a different subject name is when the request holds a certificate based on the Enrollment Agent template. The Enrollment Agent template allows a subject to request a certificate on behalf of another subject.

Issuance Requirements

The Issuance Requirements tab allows higher assurance-level certificates to be placed in a pending state until the certificate is reviewed before it is issued. The following settings configure the authentication and signature requirements for issuance certificates that are based on a template:

CA certificate manager approval. All certificate requests are placed into the pending container of the CA for a certificate manager to issue or deny. Any defined certificate manager can issue or deny a certificate request of this type.
This number of authorized signatures. This setting requires the Certificate Management Messages over CMS (CMC) certificate request to be digitally signed by one or more authorized parties before it can be issued.
Note
- Defining the number of authorized signatures enables several other configuration parameters.
Policy type required in signature. This option is only enabled when the This number of authorized signatures value is set. This option defines which specific application policy, issuance policy, or both are required in the signing certificate. This is how the CA determines whether the signature is appropriate for authorizing the issuance of the subject’s certificate.
Application policy. This option specifies the application policy that must be included in the signing certificate used to sign the certificate request. It is enabled when Policy type required in signature is set to either Application policy or Both application and issuance policy.
Issuance policy. This option specifies the issuance policy that must be included in the signing certificate used to sign the certificate request. This option is enabled when Policy type required in signature is set to either Issuance policy or Both application and issuance policy.

Superseded Templates

The Superseded Templates tab allows existing certificate templates to be superseded with a modified version 2 certificate template. The following scenarios are supported:

A version 2 certificate template can supersede a version 1 certificate template.
A version 2 certificate template can supersede a version 2 certificate template.
A common version 2 certificate template can supersede multiple existing certificate templates.

Extensions

The Extensions tab allows an administrator to define specific application policies, issuance policies, certificate subject types, and key usage attributes for a certificate template. The following sections detail the specifics on each form of extension defined in a certificate template.

Application Policies

Application policies are settings that inform a target that the subject holds a certificate that can be used to perform a specific task. They are represented in a certificate by an OID that is defined for a given application. This OID is included in the issued certificate. When a subject presents its certificate, the certificate can be examined by the target to verify the application policy and determine whether the subject can perform the requested action.

The following table shows some of the more commonly used application policies and their related OIDs.

Commonly Used Application Policies and OIDs

Application Policy	OID
Client Authentication	1.3.6.1.5.5.7.3.2
CA Encryption Certificate	1.3.6.1.4.1.311.21.5
Smart Card Logon	1.3.6.1.4.1.311.20.2.2
Document Signing	1.3.6.1.4.1.311.10.3.12
File Recovery	1.3.6.1.4.1.311.10.3.4.1
Key Recovery	1.3.6.1.4.1.311.10.3.11
Microsoft Trust List Signing	1.3.6.1.4.1.311.10.3.1
Qualified Subordination	1.3.6.1.4.1.311.10.3.10
Root List Signer	1.3.6.1.4.1.311.10.3.9
Encrypting file system	1.3.6.1.4.1.311.10.3.4

By restricting which application policies are defined in a certificate template, a certificate cannot be used for undesired transactions. For example, a certificate with the Secure E-mail OID cannot be used for client authentication.

Because some implementations of PKI applications might not understand application policies, both application policies and EKU fields appear in certificates that a Microsoft CA issues. EKU is similar to application policy in that EKU also defines the functions of certificate.

Certificate Policies

Certificate policies, also referred to as issuance policies, define the measures that are used to identify the subject of the certificate and thereby define the level of assurance for an issued certificate. For example, your organization might require a face-to-face meeting before the certificate is issued to provide for a higher level of assurance for the issued certificate.

Note

Certificate policies refer to the certificate policies extension identifier described in RFC 2459.

Issuance policies are represented in a certificate by an OID that is defined at the CA. This OID is included in the issued certificate. When a subject presents its certificate, the certificate can be examined by the target to verify the issuance policy and determine whether that level of issuance policy is sufficient for the subject to perform the requested action.

The following table describes the three default certificate policy OIDs included in Windows Server 2003.

Default certificate policy OIDs in Windows Server 2003.

OID type	Description
Low assurance	Provides no additional mechanism to identify the subject of the certificate. For example, a certificate that is issued based only on the credentials provided can be a low assurance certificate.
Medium assurance	Requires additional validation of the certificate’s subject. For example, a smart card certificate might require an administrator to have a face-to-face meeting with an employee before issuing the smart card to an employee.
High assurance	Requires research into the subject’s identity. For example, a high assurance certificate might require that an organization perform a background check on an employee before issuing the certificate.

Note

The low, medium, and high assurance OIDs are unique for each Active Directory forest.

One or more issuance policies can be set for a certificate template. Because these issuance policies are simply text labels with an associated OID, no options are associated with them. The only special issuance policy is All issuance policies, which indicates that this policy includes all others. This is normally reserved for certificates held by CAs.

Issuance policies are often used when configuring qualified subordination (cross-certification) between PKI hierarchies to ensure that certificates that are recognized by another organization’s PKI meet your organization’s issuance requirements.

You can also configure a certificate template to increase the issuance security of a certificate by requiring the user or computer to provide additional forms of identification for the certificate request. The additional forms of identification can include providing photo identification, meeting face to face with a local registration authority, or signing the certificate request with a previously issued signing certificate. These can be implemented by using the following issuance options:

Certificate Manager Approval. This setting sets all certificate requests to a pending state until a certificate manager issues or denies the certificate request. The certificate manager must first validate the identity of the certificate requestor before issuing or denying the certificate request. In some cases, the certificate manager will record any forms of identification that the user presents into a custom certificate issuance database application.
Signing Requests. An existing certificate can sign a certificate request to increase the issuance security. You can configure a certificate template to require a signature by using a certificate request with a specific application policy OID, certificate policy OID, or combination of application and certificate policy OIDs. The assumption here is that the possession of the private key associated with the signing certificate increases the issuance security of the certificate request.

Certificate Template Information

The certificate template information, also referred to as the certificate subject type, defines the purpose of a certificate template. Six subject types are recognized by Windows Server 2003 CAs:

Key recovery agent
Directory e-mail replication
Cross-certified CA
CA
Computer
User

The certificate template information extension cannot be edited. If an administrator requires a specific subject type to be applied to a certificate, the administrator should clone from a certificate template that includes the required subject type.

Key Usage

A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. Key usage is a restriction method that determines what a certificate can be used for. It allows the administrator to issue certificates that can only be used for specific tasks or certificates that can be used for a broad range of functions. If no key usage is specified, the certificate can be used for any purpose.

For signatures, key usage can be limited to one or more of the following purposes:

Digital signature
Signature is a proof of origin (nonrepudiation)
Certificate signing
CRL signing

For encryption key usage, the following options are available:

Key exchange without key encryption
Key exchange only with key encryption

Security

The Security tab allows you to define the discretionary access control list (DACL) for a specific certificate template. The permissions that can be assigned to a certificate template include:

Full Control. This permission allows a security principal to modify all attributes of a certificate template, including the permissions for the certificate template.
Read. This permission allows a security principal to see the certificate template when enrolling for certificates. It is required for a security principal to enroll or auto-enroll a certificate; it is required by the certificate server to find the certificate templates in Active Directory.
Write. This permission allows a security principal to modify the attributes of a certificate template, including the permissions assigned to the certificate template.
Enroll. This permission allows a security principal to enroll for a certificate based on the certificate template. To enroll for a certificate, the security principal must also have Read permissions for the certificate template.
Autoenroll. This permission allows a security principal to receive a certificate through the auto-enrollment process. Auto-enrollment permissions require that the user has both Read and Enroll permissions in addition to the Auto-enroll permission.
Note
- It is recommended that certificate template permissions be assigned only to global groups or universal groups. Because the certificate template objects are stored in the Configuration naming context, you cannot assign permissions using domain local groups. To simplify administration, it is never recommended to assign certificate template permissions to individual user or computer accounts.

Certificate Template Objects Defined in the Windows Schema

The Certificate Templates container contains the certificate templates that are defined within an Active Directory forest. Each certificate template is of the class pKICertificate.

Each template is stored in the following location in the Configuration naming context:

CN=<name of template>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC= ForestRootDomain

The following version 1 attributes are defined in the Active Directory schema.

Version 1 Attributes

Attribute Name	Description
cn	Common name of the certificate type
distinguishedName	The common name of the certificate type
displayName	The display name of a certificate type
pKIExtendedKeyUsage	An array of extended key usage object identifiers (OIDs) for a certificate type
pKIDefaultCSPs	The list of default CSPs for this certificate type
pKICriticalExtensions	The list of critical extensions
revision	The major version of the template
templateDescription	The description of the template
flags	General enrollment flags (see below)
pKIDefaultKeySpec
NTSecurityDescriptor	Security Descriptor name
pKIKeyUsage	Key Usage extension
pKIMaxIssuingDepth	Basic Constraints
pKIExpirationPeriod	Certificate validity period
pKIOverlapPeriod	Certificate renewal period

The following version 2 attributes are defined in the Active Directory schema.

Version 2 Attributes

Attribute name	Description
msPKI-Template-Schema-Version	The schema version of the template
msPKI-Template-Minor-Revision	The minor version of the template
msPKI-RA-Signature	The number of RA signatures required on a request referencing this template
msPKI-Minimal-Key-Size	The minimal key size required
msPKI-Template-Cert-Template-OID	The OID of this template
msPKI-Supersede-Templates	The OID of the template that this template supersedes
msPKI-RA-Policies	The RA issuer policy OIDs required in certificates used to sign a request
msPKI-RA-Application-Policies	The RA application policy OIDs required in certificates used to sign a request
msPKI-Certificate-Policy	The certificate issuer policy OIDs are placed in the OID_CERT_POLICIES extension by the policy module
msPKI-Certificate-Application-Policy	The certificate application policy OIDs are placed in the OID_APPLICATION_CERT_POLICIES extension by the policy module
msPKI-Enrollment-Flag	Enrollment flags (see below)
msPKI-Private-Key-Flag	Private key flags (see the following section)
msPKI-Certificate-Name-Flag	Subject name flags (see the following section)

Flags

The following enrollment flags are defined in the Active Directory schema.

Enrollment Flags

Flag	Description
CT_FLAG_INCLUDE_SYMMETRIC_ALGORITHMS 0x00000001	Include the S/MIME symmetric algorithms in the requests
CT_FLAG_PEND_ALL_REQUESTS 0x00000002	All certificate requests are pended
CT_FLAG_PUBLISH_TO_KRA_CONTAINER 0x00000004	Publish the certificate to the key recovery agent (KRA) container in the Active Directory
CT_FLAG_PUBLISH_TO_DS 0x00000008	Publish the resultant certificate to the userCertificate property on the user object in the Active Directory
CT_FLAG_AUTO_ENROLLMENT 0x00000020	This certificate can be issued through auto-enrollment
CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT 0x00000040	A previously issued certificate will validate subsequent enrollment requests
CT_FLAG_DOMAIN_AUTHENTICATION_NOT_REQUIRED 0x00000080	Domain authentication is not required
CT_FLAG_USER_INTERACTION_REQUIRED 0x00000100	User interaction is required to enroll using auto-enrollment
CT_FLAG_ADD_TEMPLATE_NAME 0x00000200	Add the szOID_CERTTYPE_EXTENSION (template name) extension Note: This flag will only be set on version 1 certificate templates and only for Windows 2000 CAs
CT_FLAG_REMOVE_INVALID_CERTIFICATE_FROM_PERSONAL_STORE 0x00000400	Remove invalid (expired or revoked) certificates from the personal store on local client computers during auto-enrollment

The following subject name flags are defined in the Active Directory schema.

Subject Name Flags

Flag	Description
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 0x00000001	The enrolling application must supply the subject name
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT_ALT_NAME 0x00010000	The enrolling application must supply the subjectAltName in the certificate request
CT_FLAG_SUBJECT_REQUIRE_DIRECTORY_PATH 0x80000000	The subject name should be the full distinguished name (DN) based on the Active Directory path
CT_FLAG_SUBJECT_REQUIRE_COMMON_NAME 0x40000000	The subject name should be the common name
CT_FLAG_SUBJECT_REQUIRE_EMAIL 0x20000000	The subject name must include the e-mail name
CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN 0x10000000	The subject name must include the DNS name as the common name
CT_FLAG_SUBJECT_ALT_REQUIRE_DNS 0x08000000	The subject alternative name must include the DNS name
CT_FLAG_SUBJECT_ALT_REQUIRE_EMAIL 0x04000000	The subject alternative name must include the e-mail name
CT_FLAG_SUBJECT_ALT_REQUIRE_UPN 0x02000000	The subject alternative name must include the UPN
CT_FLAG_SUBJECT_ALT_REQUIRE_DIRECTORY_GUID 0x01000000	The subject alternative name must include the directory GUID (used by domain controllers)
CT_FLAG_SUBJECT_ALT_REQUIRE_SPN 0x00800000	The subject alternative name must include the service principal name (SPN)
CT_FLAG_SUBJECT_ALT_REQUIRE_DIRECTORY_GUID 0x01000000	The subject alternative name must include the directory GUID
CT_FLAG_SUBJECT_ALT_REQUIRE_SPN 0x00800000	The subject alternative name requires SPN

The following private key flags are defined in the Active Directory schema.

Private Key Flags

Flag	Description
CT_FLAG_ALLOW_PRIVATE_KEY_ARCHIVAL 0x00000001	Archival of the private key is allowed or required
CT_FLAG_EXPORTABLE_KEY 0x00000010	Mark the private key as exportable

CT_FLAG_ALLOW_PRIVATE_KEY_ARCHIVAL

0x00000001

Archival of the private key is allowed or required

CT_FLAG_EXPORTABLE_KEY

0x00000010

Mark the private key as exportable

The following general flags are defined in the Active Directory schema.

General Flags

Flag	Description
CT_FLAG_MACHINE_TYPE 0x00000040	This is a machine certificate
CT_FLAG_IS_CA 0x00000080	This is a CA certificate
CT_FLAG_IS_CROSS_CA 0x00000800	This is a cross-CA certificate
CT_FLAG_IS_DEFAULT 0x00010000	Default certificate type that is set on all version 1 templates that cannot be modified
CT_FLAG_IS_MODIFIED 0x00020000	The certificate type has been modified (read only)
CT_MASK_SETTABLE_FLAGS 0x0000ffff	Flag that can be set for general flags

CSPs

Microsoft CryptoAPI provides a secure interface to the installable CSP modules that perform all cryptographic operations and manage private keys for all Windows Server 2003 cryptographic services, including Certificate Services.

Vendors can develop hardware or software CSPs that support a wide range of cryptographic operations and technologies. However, Microsoft must certify and digitally sign all CSPs. CSPs do not work in Windows Server 2003 unless they have been digitally signed by Microsoft.

Note

For more information about obtaining a Microsoft digital signature for a CSP, see the Platform Software Development Kit (SDK) on MSDN.

Windows Server 2003 includes the following Microsoft CSPs:

Microsoft Base Cryptographic Service Provider: The Base CSP provides a broad set of basic cryptographic functions. It is not subject to United States government cryptography export restrictions and can be exported to other countries (subject to general United States export restrictions in addition to the import restrictions of other countries). The Base CSP uses Rivest-Shamir-Adelman (RSA) technology, which is licensed from RSA Data Security, Inc.
Microsoft Strong Cryptographic Service Provider: The Strong CSP is an extension of the Base CSP available with Windows 2000 and Windows Server 2003. It supports all the algorithms in the Enhanced CSP, but the key lengths are the same as in the Base CSP. It supports RSA, Data Encryption Standard (DES), 3DES, RC2, and RC4 in addition to (Message-Digest Algorithm) MD5 and Secure Hash Algorithm 1 (SHA1).
Microsoft Enhanced Cryptographic Service Provider: The Enhanced CSP provides the same capabilities as the Base CSP, but enforces stronger security by supporting longer key lengths and additional cryptographic algorithms. The Enhanced CSP also uses RSA technology.

The following table highlights differences between the Base CSP and the Enhanced CSP. The public key lengths shown in the table are the default key lengths.

Comparison of Microsoft Base CSP and Microsoft Enhanced CSP

Algorithm	Base CSP	Strong CSP	Enhanced CSP
RSA public key signature algorithm	Key length: 512 bits.	Key length: 1,024 bits.	Key length: 1,024 bits.
RSA public key exchange algorithm	Key length: 512 bits.	Key length: 1,024 bits.	Key length: 1,024 bits.
RC2 block encryption algorithm	Key length: 40 bits.	Key length: 128 bits.	Key length: 128 bits. Salt length: Settable.
RC4 stream encryption algorithm	Key length: 40 bits.	Key length: 128 bits.	Key length: 128 bits. Salt length: Settable.
DES	Key length: 56 bits.	Key length: 56 bits.	Key length: 56 bits.
Triple DES (2-key)	Not supported.	Key length: 112 bits.	Key length: 112 bits.
Triple DES (3-key)	Not supported.	Key length: 168 bits.	Key length: 168 bits.
SHA1	Key length: 160 bits.	Key length: 160 bits.	Key length: 160 bits.
Message Digest 2 (MD2)	Key length: 128 bits.	Key length: 128 bits.	Key length: 128 bits.
Message Digest 4 (MD4)	Key length: 128 bits.	Key length: 128 bits.	Key length: 128 bits.
Message Digest 5 (MD5)	Key length: 128 bits.	Key length: 128 bits.	Key length: 128 bits.
SSL3 (SHAMD5)	Key length: 288 bits.	Key length: 288 bits.	Key length: 288 bits.
Message Authentication Code (MAC)	Key length: 512 bits.	Key length: 1,024 bits.	Key length: 1,024 bits.

Public keys used with the Base, Strong, and Enhanced CSPs for digital signatures can be up to 16,384 bits long. However, the public keys used for key encryption and key exchange (to protect secret keys) are limited to a maximum of 1,024 bits for the Base and Strong CSPs, and 16,384 bits for the Enhanced CSP. In addition, the symmetric keys for the encryption algorithms in the Base CSP are limited to shorter key lengths, resulting in significantly weaker cryptographic security. Overall, the key lengths and the encryption algorithms in the Enhanced CSP provide far stronger cryptographic security.

For the Base, Strong, and Enhanced CSP, public keys used for signing or key exchange can be a minimum of 384 bits long. However, public keys of at least 1,024 bits are recommended, unless they adversely affect computer performance.

The default public key length of the Strong and Base CSPs is 512 bits, and the default public key length of the Enhanced CSPs is 1,024 bits. Windows Server 2003 Certificate Services uses the default public key lengths of the CSP, although any key length the CSP supports can be configured.

The Strong and Enhanced CSPs are compatible with the Base CSP except that the CSPs can generate only RC2 or RC4 keys of the default key length. The default symmetric key length for RC2 and RC4 in the Base CSP is 40 bits. The default symmetric length for RC2 and RC4 in the Strong and Enhanced CSP is 128 bits. Therefore, the Enhanced CSP cannot create keys with Base CSP–compatible key lengths. However, the Strong and Enhanced CSPs can import RC2 and RC4 keys of up to 128 bits. Therefore, the Strong and Enhanced CSPs can import and use 40-bit keys that were generated by using the Base CSP.

Other Microsoft CSPs include:

Microsoft Base DSS Cryptographic Service Provider. This CSP provides data signing and signature verification capability by using the SHA and Digital Signature Algorithm (DSA).
Microsoft Base DSS and Diffie-Hellman Cryptographic Service Provider. This CSP provides a superset of the DSS Cryptographic Provider and also supports Diffie-Hellman key exchange, hashing (message digests), data signing, and signature verification by using the SHA and DSA algorithms.
Microsoft Base DSS and Diffie-Hellman/Schannel Cryptographic Service Provider. This CSP offers various cryptographic services that are required for data integrity, session key exchange, and authentication during secure Web communications by using the SSL and Transport Layer Protocol (TLS) protocols.
Microsoft RSA/Schannel Cryptographic Provider: This CSP is similar to the Microsoft Base DSS and Diffie-Hellman/Schannel Cryptographic Provider in that it works with SSL3 and TLS1, but uses the RSA suite of algorithms rather than Diffie-Hellman.
Smart Card Cryptographic Service Providers: Windows Server 2003 includes smart card CSPs from a number of vendors, including Schlumberger, Gemplus, and Infineon.

Local Certificate Storage

In Windows Server 2003, public-key objects such as certificates, CRLs, and certificate trust lists (CTLs) are stored in certificate stores for use by users, services, and computers. The Windows Server 2003 certificate stores include physical stores and logical stores.

Physical certificate stores can be local or remote:

Local objects are stored in the registry of the computer.
The user object in Active Directory has a virtual store on the userCertificate attribute,

Many public key objects in the physical stores are shared among users, services, and computers through the use of logical certificate stores. These logical certificate stores group certificates together in logical, functional categories for users, computers, and services and provide pointers to the physical certificate stores. The use of logical certificate stores eliminates the need to store duplicates of common public key objects, such as trusted root certificates, CTLs, and CRLs for users, computers, and services.

However, some certificates, CTLs, or CRLs are issued for use only by an individual service, user, or local computer. Therefore, users, computers, and services also have individual stores that provide a place to store certificates, CTLs, or CRLs that are not shared in common. For example, a user can request and obtain a certificate or a CRL, which appears in the individual’s logical store and is physically stored in the user’s unique certificate store in the registry. Such individual user certificates and CRLs are not shared with local computers or with services.

In addition, some public-key objects, such as trusted root certificates and CTLs, can be distributed through Public Key Group Policy. Public key objects that are distributed through Group Policy are stored in special areas of the registry and appear in the logical stores for users, computers, and services. When you use Group Policy, separate CTLs can be created for users and computers. The CTLs for users are not shared with services or the computer. However, the CTLs for computers are shared with users and services.

The logical certificate stores include the following categories for users, computers, and services:

Personal Contains individual certificates for the user, service, or computer. For example, when an enterprise CA issues you a User certificate, the certificate is installed in the Personal store for your user account.
Trusted Root Certification Authorities Contains certificates for root CAs. Certificates with a certification path to a root CA certificate are trusted by the computer for all valid purposes of the certificate.
Disallowed Certificates These are certificates that a user has explicitly decided not to trust using either Software Restriction policy or by clicking “Do not trust this certificate” when the decision is presented in an e-mail application or a Web browser.
Third-Party Root Certification Authorities Trusted root certificates from certification authorities other than Microsoft and your organization.
Enterprise Trust Contains CTLs. Certificates with a certification path to a CTL are trusted by the computer for purposes specified in the CTL.
Intermediate Certification Authorities Contains certificates for CAs that are not trusted root certificates (for example, certificates of subordinate CAs), but that are required to validate certification paths. This store also contains CRLs for use by the user, service, or computer, and cross certificates..
Active Directory User Object Contains certificates that are published in Active Directory for the user. This store appears in the Certificates snap-in for users only, not for computers or services.
Request Contains pending or rejected certificate requests. This store appears only in the Certificates snap-in after a certificate request has been made for the user, computer, or service.
SPC Contains certificates for software publishers that are trusted by the computer. Software that has been digitally signed by publishers with certificates in this store is downloaded without prompting the user. By default, this store is empty. When Microsoft Internet Explorer downloads software that has been signed by a software publisher for the first time, users are prompted to choose whether they want to trust all software that is signed by this publisher. If a user chooses to trust all software signed by the publisher, the publisher’s software publisher certificate (SPC) is added to the SPC store. This store appears in the Certificates snap-in for the local computer only, not for users or services.
Trusted People Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.
Other People Certificates issued to people or end entities that are implicitly trusted. These certificates must be part of a trusted certification hierarchy. Most often these are cached certificates for services like Encrypting File System, where certificates are used for creating authorization for decrypting an encrypted file.
Certificate Enrollment Requests Pending or rejected certificate requests.
Server Authentication Certificates that server programs use to authenticate themselves to clients.
Client Authentication Certificates that client programs use to authenticate themselves to servers.
Code Signing Certificates associated with key pairs used to sign active content.
Secure E-mail Certificates associated with key pairs used to sign e-mail messages.
Encrypting File System Certificates associated with key pairs that encrypt and decrypt the symmetric key used for encrypting and decrypting data by the encrypting file system.
File Recovery Certificates associated with key pairs that encrypt and decrypt the symmetric key used for recovering encrypted data by the encrypting file system.
Note
- Other applications can also create their own certificate stores.

Changes to the logical certificate stores are made to the appropriate physical stores that are located in either the registry or Active Directory. Because you use only the logical certificate store for a user, service, or computer, you do not have to track where the certificates are actually stored or edit the registry to manage the certificate stores. However, it is a good idea to track changes made to the physical and logical stores; this information can be useful when you try to determine why certificate-enabled actions succeed or fail.

Viewing Physical and Logical Stores

Certificate management tools distinguish between the physical structure of certificate stores and their logical abstraction. The logical abstraction, which simplifies the physical structure, was implemented to group certificates by function or purpose and to enable administrators to understand certificate stores in a simpler way.

A number of tools are available to view the physical and logical stores:

Internet Explorer shows only the logical certificate stores.
The Certificates snap-in shows the logical structure by default; however, it is possible to view the physical structure. On the View menu, click Options, and then click Show the following: Physical certificate stores.
The Registry Editor (Regedit.exe) displays only the physical certificate store structure.
The Certutil command-line tool (Certutil.exe) refers to certificate stores by labels that are equal to the store names in the registry or LDAP directory.
Note
- For more information about the certificate management tools and registry stores for certificates, CRLs, and CTLs, see “Resource Kit Tools” in Tools and Settings Collection.

Private Keys Stored in User Profiles

Users’ private keys are stored on the local file system in the following locations:

$:\Documents and Settings\%UserName%\Application Data\Microsoft\Crypto\RSA
$:\Documents and Settings\%UserName%\Application Data\Microsoft\Crypto\DSS

Computer private keys are stored on the local file system in the following locations:

$:\Documents and Settings\All users\Application Data\Microsoft\Crypto\RSA\Machine Keys
$:\Documents and Settings\All users\Application Data\Microsoft\Crypto\DSS\Machine Keys

The Security properties page indicates who can access this private key.

Windows associates certificates with their owner. By default, every subject that has permissions to log on to the computer or run as a service owns a set of certificate stores.

The number of certificates per store is limited only by memory and hard disk space. For certificates that are stored in the registry, the limiting factor is the total size of the registry. For information about the physical store location, see the individual store description later in this section.

Personal Certificates Stored in User Profiles

Certificates that are stored in the personal certificate store belong to the current user. These certificates in appear in the file system in:

%USERPROFILE%\Application Data\Microsoft\Systemcertificates\My

Access to the personal certificate store is restricted to the user who owns the certificate.

The personal store receives certificates from auto-enrollment or when a user requests a certificate manually. If a user imports a personal certificate, the certificate is stored in the Personal container.

This store maintains certificates of any type. A user who owns an S/MIME certificate, an EFS, certificate and a client-authentication certificate, for example, will see these certificates in his or her personal certificate store.

For roaming profiles, the users certificates are located on the share that hosts the user’s profile. Because user certificates and private keys are part of the user’s profile, this information is transmitted over the network when a roaming profile is read from or written to the server share.

Certificate Processes and Interactions

Certificates are credentials, and like other forms of credentials they need to be created before they can be used. After they have been created, there needs to be a means of validating their authenticity and verifying that they can be used for the desired purpose. After certificates have been created and validation processes are in place, certificates can be used for the following basic cryptographic operations:

Public key encryption
Message digest functions
Digital signing

How Certificates Are Created

Certificates are issued by a CA, which can be any trusted service or entity willing to verify and validate the identities of those to whom it issues certificates and their association with specific keys. Companies might issue certificates to employees, schools might issue certificates to students, and so on. Of course, a CA’s public key must be trustworthy or the certificates it issues will not be trusted. Because anyone can become a CA, certificates are only as trustworthy as the authority that issues the underlying keys.

The following six steps describe the process of requesting and issuing a certificate.

Generate a key pair The applicant generates a public and private key pair or is assigned a key pair by some authority in his or her organization.
Collect required information The applicant collects whatever information the CA requires to issue a certificate. The information could include the applicant’s e-mail address, birth certificate, fingerprints, notarized documents — whatever the CA needs to be certain that the applicant is who he or she claims to be. CAs with stringent identification requirements produce certificates with high assurance — that is, their certificates generate a high level of confidence. CAs themselves are said to be of high, medium, or low assurance.
Request the certificate The applicant sends a certificate request, consisting of his or her public key and the additional required information, to the CA. The certificate request, which is signed with the client’s public key, can also be encrypted by using the CA’s public key. Many requests are made by using e-mail, but requests can also be sent by postal or courier service — for example, when the certificate request itself must be notarized.
Verify the information The CA applies whatever policy rules it requires to verify that the applicant should receive a certificate. As with identification requirements, a CA’s verification policy and procedures influence the amount of confidence generated by the certificates it issues.
Create the certificate The CA creates and signs a digital document containing the applicant’s public key and other appropriate information. The signature of the CA authenticates the binding of the subject’s name to the subject’s public key. The signed document is the certificate.
Send or post the certificate The CA sends the certificate to the applicant or posts the certificate in a directory, as appropriate.

How Certificates Are Validated

Before it trusts certificates, Windows performs a validation check to ensure that certificates are valid and that they have a valid certification path.

The status of a public key certificate is determined through three distinct, but interrelated, processes implemented in CryptoAPI:

Certificate discoveryThe process of collecting CA certificates from Group Policy, Enterprise Policy, and AIA pointers in issued certificates, and the process of enrolling certificates.
Path validationThe process by which public key certificates and their issuer certificates are processed in a hierarchical fashion until the certificate chain terminates at a trusted, self-signed certificate. Typically, this is a root CA certificate.
Revocation checkingEach certificate in the certificate chain is verified to ensure that none of the certificates are revoked. The revocation checking can take place either in conjunction with the chain building process or after the chain is built.

Chain Building

Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal.

The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate. The certificates are retrieved from the Intermediate Certification Authorities store, the Trusted Root Certification Authorities store, or from a URL specified in the AIA attribute of the certificate. If CryptoAPI discovers a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is discarded as a nontrusted certification path.

To improve performance, CryptoAPI will store subordinate CA certificates in the Intermediate Certification Authorities store so that future requests for the certificate can be satisfied from the store, rather than accessing the certificate through a URL.

Certificate Storage

Windows Server 2003 and Windows XP store certificates locally on the computer or hardware device that requested the certificate, or — in the case of a user — on the computer or device that the user used to request the certificate. There are separate stores known as the machine store, used by the computer, and the user store or My store used by the currently logged-on user. A certificate store will often contain numerous certificates, possibly issued from a number of different CAs.

Certificate chains are formed by looking at certificates available in multiple certificate stores. The certificate chain engine must determine what scope of certificate stores to search when building certificate chains. By default, the chain engine searches the ROOT, TRUST, CA, and MY certificate stores.

In addition to the default stores, the certificate chain engine can be configured to use different stores, such as restricted root, restricted trust, restricted other, and additional stores. For example, the Trusted People store is used by both Outlook and EFS when searching for certificates. Alternatively, an application can create its own store for certificate storage or even call additional revocation providers registered with CryptoAPI.

Purpose

The certificate chain engine builds all possible certificate chains. The entire graph of certificate chains is constructed and then ordered by the “quality” of the chain. The best-quality chain for a given end certificate is returned to the calling application as the default chain.

Each chain is built by using a combination of the certificates available in the certificate stores and certificates available from published URL locations. Each certificate in the chain is assigned a status code. The status code indicates whether the individual certificate is:

Signature-valid Is the signature valid?
Time-valid Are the certificate start and expiration dates properly configured, has the start date not occurred yet, or has the certificate expired?
Expired Has the certificate expired?
Revoked Has the certificate been revoked?
Time-nested Have any of the certificates that are higher in the PKI hierarchy expired?
Any other restrictions on the certificate For example, is the certificate being used for a purpose other than has been intended?

Each status code has a precedence assigned to it. For example, an expired certificate has a higher precedence than a revoked certificate. This is because an expired certificate should not be checked for revocation status.

If different status codes are assigned to the certificates in a certificate chain, the status code with the highest precedence is applied to the certificate chain and propagated into the certificate chain status.

Path validation

For each certificate in the chain, the certificate chain engine must select a certificate of the issuing CA. This process, known as path validation, is repeated until a self-signed certificate is reached (typically, this is a root CA certificate). CryptoAPI treats root certificates as the absolute determinant of trust in trust decisions.

There are different processes that can be used to select the certificate for an issuing CA. The actual process that is used is based on whether the certificate currently being investigated has the Authority Key Identifier (AKI) extension defined. Inspection of the AKI extension will lead to one of three matching processes being implemented:

Exact match If the AKI extension contains the issuer’s user name and issuer serial number, only certificates that match on user name and serial number will be chosen in the chain-building process. As a further test, the issuer name on the issued certificate must match the subject name on the issuer certificate.
Key match If the AKI extension only contains public key information, only certificates that contain the indicated public key in the Subject Key Identifier (SKI) extension will be chosen as valid issuers.
Note
- The public key information in the AKI extension and in the SKI extension is the hash of the public key. Therefore, both hashes must have been calculated by using the same algorithm. Otherwise, no key match will be determined even though the public key used for the hashes matches. The default hash algorithm used by the Microsoft CA and CryptoAPI is SHA-1 when no SKI exists in the certificate. However, when an SKI exists, both MD5 and SHA-1 algorithms are supported, but the AKI and SKI must use the same algorithm.
Name match. If no information exists in the AKI, or if the AKI does not exist in the certificate, the certificate will be marked as “name match.” In name matching, the subject name of a certificate must match the issuer name in the current certificate in order for the certificate to be chosen as a valid issuer. Because the data is stored in a binary format, the name-matching process is case-sensitive.

In all cases, even if a matching certificate is not found in the store, the current certificate will still be marked as “exact match”, “key match” or “name match,” because this describes the attempted match rather than the attained match.

Caching

To increase performance, the certificate chain engine uses a least recently used (LRU) caching scheme. This scheme creates a cache entry for each certificate it encounters as it builds the certificate chain. Each cache entry includes the status of the certificate, so the best certificate chain can be built from cached items on subsequent calls to the chaining API without having to determine the status of each certificate again. After a certificate has been added to the cache, it will not be removed until it expires or is revoked.

During the path validation process, valid cached certificates will always be selected. If valid cached certificates are not found, a store search will be performed. For issuer certificates and CRLs, URL retrieval can be required to download the certificates and CRLs from the distribution point indicated in the URL.

All certificates are stored in the cache when the certificates are selected from a store or from a URL. The only difference is the location where the cached certificates are stored. Certificates can be stored in the following locations:

CA store All certificates retrieved from any WinHTTP-supported URLs via the AIA extension are cached in the CA store.
Local file system If the retrieval URL begins with LDAP, FTP, or HTTP, the certificate (or CRL) is also cached in the local file system.

In some cases, the certificate might be cached in all three locations. For example, when a certificate is retrieved from an HTTP URL, the certificate will be cached in memory, the CA store, and in the local file system.

Revocation

The certificate chain engine performs basic revocation checking during chain building, but the process differs between Windows 2000 and Windows 2003 and Windows XP.

For Windows 2000, post-processing revocation is used. This means that the CRL checking is performed after the chain is built. The certificate chain engine will check each certificate in the chain to determine whether the certificate has been revoked and the reason for the revocation.

Windows XP and Windows Server 2003 use revocation checking while building the certificate chain. Rather than waiting until the chain is built, each certificate is examined as the chain is built. If a revoked certificate is discovered in the chain, the chain is assigned a lower quality value.

Note

The existence of a revoked certificate in a certificate chain does not preclude the chain from being presented to the calling application as the best-quality certificate chain. The best-quality chain might not necessarily be a trustworthy chain.

Certificate path validation

The path validation process ensures that a valid certification path can be established for a given end certificate. A valid certification path is defined as an end-user certificate that can be traced along a certificate chain to a trusted root CA. Each CA certificate in the path must be discovered and subsequently validated until a final authority such as a root CA is obtained. During the validation process, a certificate can be deemed invalid (or not trusted) for many reasons. The reasons include:

The time period configured in the certificate is not valid. This occurs when the start and expiration dates are improper, have not occurred yet, or are expired.
Note
- An expired CA certificate in the certification path reduces the quality of the path, but it does not invalidate the path. In a Windows Server 2003 PKI, a certification path can be valid as long as the CA certificate was valid at the time the certificate was issued. For example, a third-party CA might issue a certificate with a lifetime that extends past the CA’s certificate’s expiration date. After the CA’s certificate expires, the certification path for the certificate is still valid and the certificate is trusted as long as all other validation criteria are met. In Windows 2000, however, CryptoAPI enforces time nesting rules by default where a child certificate must have a validity period shorter than the parent. Signatures, however, might be considered valid past the date of the certificate lifetime.
The certificate is unrecognized. If the certificate format is improper, does not conform to the X.509 version 1 through version 3 standard for digital certificates, the certificate is discarded.
The information in certificate fields is improper or incomplete.
The certificate’s digital thumbprint and signature fail the integrity check, indicating that the certificate has been tampered with or corrupted.
The certificate’s status was determined to be revoked.
The issuing CA is not in either a trusted certification hierarchy or a CTL.
The root CA for the certification path is not in the Trusted Root Certification Authorities store.
The certificate is not permitted for the intended use as specified in a CTL.
The certificate contains a critical extension that is not understood by the application.

Critical extensions

The CryptoAPI engine does not enforce critical extensions in certificates, only CRLs. The CryptoAPI engine and programming model place the burden of parsing critical extensions on the calling application; therefore, an application must understand and enforce the critical extension when evaluating a certificate. The CryptoAPI revocation provider, however, does evaluate critical extensions in CRLs and therefore would reject a CRL with a critical extension that is not known or understood.

Certificate status checking

All certificates in a certificate chain can be processed to verify that none of the certificates has been revoked. Certificate chain validation is, of course, optional from an application standpoint and might not be enforced by CryptoAPI. Windows by default checks certificate revocation status via CRLs, because the CRL processing engine is the native revocation provider included with CryptoAPI. When this functionality has been invoked, each certificate in the certificate chain is checked against the CRL published in the CRL Distribution Point (CDP) extension in the certificate. If the certificate is found to be included in the CRL, the certificate is then considered revoked. Additionally, third-party revocation providers can be registered with CryptoAPI to add support for additional protocols that check revocation status including Online Certificate Status Protocol (OCSP), Simple Certificate Validation Protocol (SCVP), and XML Key Management Specification (XKMS).

When a certificate’s status is verified by using a CRL, several steps must be performed by an application to check the status of the certificates in the certificate chain. These steps are performed against each certificate in the chain. These steps include:

Verify the signature of the CRL. The CRL must be signed so that the application can determine whether it trusts the CRL issuer to issue CRLs.
Note
- Windows Server 2003, Windows 2000, and Windows XP can only verify a CRL that was signed by the same private key used to sign the issued certificate. These versions of Windows do not support CRLs signed by an entity other than the CA that signed the issued certificate.
Verify that the CRL has not expired. A CRL is considered expired if the current date is later than the date contained in the next update field of the CRL. If the certificate that is being checked has expired, the application must verify that the CRL’s issue date follows the effective date of the certificate, but precedes the certificate’s expiration date.
Search the list of revoked certificates to verify that either the target certificate is not included or its revocation date is later than the effective date.

When a third-party revocation provider supporting OCSP has been registered, an OCSP responder will be used for certificate status checking; in this case, the process is slightly modified.

Verify that the response indicates the certificate is valid. A valid response indicates that the certificate has not been revoked.
Verify the signature on the OCSP response. This activity includes developing and processing a path that establishes that the certificate issuer or a trust point trusted the responder for the express purpose of issuing responses.

Neither Windows XP nor Windows 2000 contains an OCSP client component by default. However, a third-party OCSP client can be installed as a revocation provider to CryptoAPI. OCSP responders can be located by using the AIA extension in the certificate as defined by RFC 2459. The Windows Server 2003 CA supports the OCSP responder location to be included in the AIA extension of certificates. Multiple revocation providers can be added to CryptoAPI depending on revocation requirements. For additional information about revocation providers, see the Platform SDK on MSDN.

No matter what process is used to verify certificate validity, if the status check fails any of the above checks for any certificate in the certificate chain, the certificate chain will be rejected.

Basic constraint validation

Basic constraints give an administrator the ability to designate whether an issued certificate is a CA certificate or an end certificate. This validation is used to verify that a CA certificate can be used by the certificate chain engine to build certification paths.

An additional use of the basic constraint extension is to limit the maximum number of CA certificates that can be included under a given CA. For example, a path length of zero only allows end certificates to be issued by that specific CA. Likewise; a path length of two in the basic constraints extension will only allow three CA certificates in a certification path. In this example, any certification paths discovered with more than three CAs in the path will be discarded.

Name constraint validation

A CA certificate can contain name constraints that are applied to all certificate requests made to the CA. Each request is compared to the list of permitted and excluded constraints to determine whether the certificate should be considered permitted, not permitted, excluded, or not defined.

Note

Name constraint validation can only be performed by Windows XP and Windows Server 2003 clients. Name constraints are not evaluated by Windows 2000 clients. If you require that name constraints be applied, you can indicate that the extensions are critical, which should result in the chain being discarded by an application conforming to RFC 2459.

For example, a permitted constraint could allow all DNS names that end in contoso.com. This would include DNS names such as contoso.com and xcontoso.com. If you only wanted DNS names from the contoso.com DNS name space, you could use the permitted constraint .contoso.com. This constraint would permit x.contoso.com but exclude xcontoso.com.

When name constraints are present in a CA certificate, the following rules are applied to the subject name and alternate subject name entries.

If the name constraints extension exists in a CA certificate, all name constraints should be present in the extension. Any name constraints that are not included are considered wildcards that will match all possibilities. For example, if the DNS name constraint were absent, the entry would be treated as DNS=.
All name constraints will be considered. There is no precedence applied to the listed name constraints. It is for this reason that name constraints that are not present are treated as wildcards.
An excluded name constraint will take precedence over a permitted name constraint
Name constraints are applied to the subject name extension and any existing subject alternate name extensions.
Name constraints apply to all names contained in an end certificate. Each name in the subject or subject alternate name extensions should match at least one of the name constraints listed for that name type. A subject name or subject alternate name that does not match a listed name type will be rejected. Note that most client name spaces are not included in a CA certificate and generally do not apply.
Name constraints are case-sensitive if the names are stored in ASCII or Unicode format.

Name restrictions must be enforced across the following alternative name information entries in the subject name: Other Name (NT Principal Name only); RFC 822 Name; DNS Name; URL; Directory Name, and IP address.

When the certificate chain engine validates an end certificate for name constraints, it will arrive at one of the following results:

Permitted The end certificate contains a name that is listed as permitted in an issuer’s name constraints extension.
Not permitted The end certificate contains a name that is not listed as permitted in an issuer’s name constraints extension.
Excluded The end certificate contains a name that is listed as excluded in an issuer’s name constraints extension
Not Defined The issuer certificate does not list a constraint for a specific name type (such as Directory Name or IP Address)

Policy constraint validation

A policy constraint allows a CA administrator to ensure that specific constraints are met when a certificate is issued or used by an application. The policy constraint ensures that all certificates issued by the CA implement the required policy constraints.

By definition, a root CA implements all policies. This applies to both enterprise and standalone CAs. At some point down the hierarchy, a CA can have one or more policies defined. After a CA certificate is encountered with any policy OIDs, all certificates below that CA in the hierarchy must also have a subset of those policy OIDs. A certificate chain with no valid policy set will be considered invalid, whereas one with no policy OIDs at all will be considered valid and matching the “any policy” OID. The above is valid only for application policies and not issuance polices. The absence of the certificatePolicies extension in a CA other than the root CA implies that there is no issuance policy.

There are two policies currently used with a Windows Server 2003 CA: issuance policy and application policy. The policy applied to a certificate affects how the validity of a certificate chain is determined.

Issuance policy

Issuance policies, referred to as the certificate policies extension in RFC 2459, allow a CA administrator to define the circumstances and requirements for certificate issuance. The assurances required for certificate issuance can vary based on certificate templates. An issuance policy defines a set of administrative rules that must be followed when issuing a certificate. The rules are defined in the certificate by an OID defined by the CA. Each certificate issued by the CA will include the OID. The OID is not defined in the CA, but instead in the certificate template.

Note

Issuance policy is only available to Windows Server 2003 and Windows XP clients. Issuance policy is not recognized by Windows 2000 clients.

When an entity presents a certificate to an application, the application can examine the certificate to verify the issuance policy and determine if the issuance policy is sufficient to perform the action requested by the subject.

Currently, two types of constraints are defined: Require explicit policy and Inhibit policy mapping.

Require explicit policy specifies the number of certificates that can exist in the hierarchy below the current certificate before an explicit policy must exist.
Inhibit policy mapping specifies the number of additional certificates that can appear in the path before policy mapping is no longer permitted.

Policies can also be mapped to other policies on a one-to-many basis. Policy mapping allows interoperability between two organizations that implement similar policies, but have deployed different OIDs. If one company’s policy OID (for example, 1.2.3.4) stands for a specific function and another company’s policy OID (for example, 11.22.33.44) stands for the same function, these two OIDs can be mapped. In this example, 11.22.33.44 can be mapped to 1.2.3.4.

Application policy

Certificates provide key information that is not specific to an application; however, the ability to decide which certificates can be used for certain functions is important. Application policy allows you to issue certificates widely and restrict their usage to only their intended purposes.

Application policies are settings that inform a target that the subject holds a certificate that can or cannot be used to perform a specific task. They are represented in a certificate by an OID that is defined by the CA. This OID is included in all issued certificates. When a subject presents its certificate, it can be examined by the target to verify the application policy and determine if it can perform the requested action.

Application policy is Microsoft-specific and is treated much like EKU

If a certificate has an extension containing an application policy and has an EKU extension, the EKU extension is ignored.
If there is only an EKU extension, it is treated like an application policy extension.

If there is an application policy extension (and no EKU extension) and an EKU property on the certificate, the intersection of the EKU property OIDs and the application policy OIDs is taken and the result is the effective policy for the certificate.

If the application policy extension is absent, CryptoAPI will function like any other RFC 2459–compliant client. If it is present, CryptoAPI will implement the application policy rules. It is recommended that implementers make the extension non-critical extension so that its presence should be benign to other clients.

Note

Policy mapping can only be used with the application policy extension. If the EKU extension is used, policy mapping is not possible because EKU does not support policy mapping. Non-Windows clients and applications might not understand this extension or use it as designed.

Basic Cryptographic Operations

A certificate contains information that identifies the certificate’s owner (called the subject) as an entity on the network. A certificate also contains the owner’s public key. Furthermore, a certificate identifies the CA (called the issuer) that issued the certificate.

A CA uses its private key to digitally sign each certificate it issues. To create the digital signature, the CA generates a message digest from the certificate, encrypts the digest with its private key, and includes the digital signature as part of the certificate. Anyone can use the message digest function and the CA’s public key to verify the certificate’s integrity. If a certificate becomes corrupted or someone tampers with it, the message digest for the altered certificate does not match the digest in the CA’s digital signature. The following figure shows how a certificate is signed by the issuing CA.

Digital Signature for a Certificate

Assinatura digital para um certificado

Information contained in the Subject Public-Key Value field of X.509 version 3 certificates specifies the cryptography operations for which the public key and private key set can be used. Public key security systems commonly support the following basic cryptography operations:

Digital signing of electronic data to verify data origin and the integrity of data.
Secret key encryption to protect symmetric secret encryption transmitted and shared over networks.

The following table briefly describes the certificate purposes.

Basic Cryptographic Operations

Cryptographic Operations	Intended use
Signature	Data signing, authentication, nonrepudiation
Encryption	Data encryption and decryption
Signature and encryption	Data encryption and decryption, digital data signing, authentication
Signature and smart card logon	Smart card logon, digital data signing

The public key and private key set can be used to provide a variety of specific security functions for information security technologies. These specific functions of certificates are listed in the keyUsage and EKU extensions. Common specific security functions for public key technology include the following:

Secure mail to provide authentication, confidentiality, integrity, and nonrepudiation for e-mail communications.
Secure Web communications to provide authentication, integrity, and confidentiality between Web clients and servers.
Code signing to provide integrity and nonrepudiation for executable code to be distributed on the Internet or intranets.
Local network logon or remote access logon to authenticate users of network resources.
IPSec authentication to authenticate clients that do not use Kerberos authentication or shared secret passwords for IPSec communications.

Public Key Encryption

In public key encryption, different keys are used to encrypt and decrypt information. The first key is a private key (a key that is known only to its owner), while the second key — called the public key — can be made known and available to other entities on the network.

The two keys are different but complementary in function. For example, a user’s public key can be published in a certificate in a directory so that it is accessible to other people in the organization. The sender retrieves the recipient’s certificate from Active Directory, retrieves the public key from the certificate, and then encrypts their communication by using this public key. Information that is encrypted with the public key can be decrypted only by using the corresponding private key of the set, which remains with its owner. The following figure shows basic encryption and decryption with asymmetric keys.

Encryption and Decryption with Asymmetric Keys

Encriptação e desencriptação com chaves assimétricas

Public key encryption plays an increasingly important role in providing strong, scalable security on intranets and the Internet. Public key encryption is commonly used to perform the following functions:

Encrypt symmetric secret keys to protect the symmetric keys during exchange over the network or while being used, stored, or cached by operating systems.
Create digital signatures to provide authentication and nonrepudiation for online entities.
Create digital signatures to provide data integrity for electronic files and documents.

The RSA digital signature process also uses private keys to encrypt information to form digital signatures. For RSA digital signatures, only the public key can decrypt information encrypted by the corresponding private key of the set.

Message Digest Functions

Message digest functions, also called hash functions, are frequently used in conjunction with asymmetric keys to further strengthen public key encryption. Message digests are commonly 128 bits to 160 bits in length and provide a unique digital identifier for each digital file or document. Two copies of a document will have the same message digest, but if even one of the bits for the document changes, the message digest changes. The following figure shows the basic message digest process.

Example of the Message Digest Process

Exemplo de um processo de digestão de mensagens

Message digests are commonly used in conjunction with public key technology to create digital signatures or “digital thumbprints” that are used for authentication, integrity, and nonrepudiation. Message digests also are commonly used with digital signing technology to provide data integrity for electronic files and documents.

For example, to provide data integrity for e-mail messages, message digests can be generated from the completed mail message, digitally signed with the originator’s private key, and then transmitted with the messages. The recipient of the message can then do the following to check the integrity of the message:

Use the same message digest function to compute a digest for the message.
Use the originator’s public key to verify the signed message digest.
Compare the new message digest to the original digest.

If the two message digests do not match, the recipient knows the message was altered or corrupted. The following figure shows a basic integrity check process with a digitally signed message digest.

Example of an Integrity Check with a Digitally Signed Message Digest

Verificação de integridade com uma mensagem assinada digitalmente

Because the message digest is digitally signed with the sender’s private key, it is not feasible for an intruder to intercept the message, modify it, and create a new valid encrypted message digest to send to the recipient.

Digital Signatures

A common use of public key encryption is to provide digital signatures. Just as handwritten signatures or physical thumbprints are commonly used to uniquely identify people for legal proceedings or transactions, so digital signatures are commonly used to identify electronic entities for online transactions. A digital signature uniquely identifies the originator of digitally signed data and also ensures the integrity of the signed data against tampering or corruption.

One possible method for creating a digital signature is for the originator of data to create the signature by encrypting all of the data with the originator’s private key and enclosing the signature with the original data. Anyone with the originator’s public key can decrypt the signature and compare the decrypted message to the original message. Because only someone with the private key can create the signature, the integrity of the message is verified when the decrypted message matches the original. Even if an intruder intercepts and alters the original message while it is in transit, the intruder cannot create a new valid signature. If an intruder alters the signature during transit, the signature will not be properly verified and therefore will be invalid.

However, encrypting all data to provide a digital signature is impractical for three reasons:

The cipher text signature is the same size as or greater than the corresponding plaintext, so message sizes are doubled, which consumes large amounts of bandwidth and storage space.
Public key encryption places heavy computational loads on computer processors, so network and computer performance can be significantly degraded.
Encrypting the entire contents of information produces large amounts of ciphertext, which can be used for cryptanalysis attacks, especially known plaintext attacks (where certain parts of the encrypted data, such as e-mail headers, are known beforehand to the attacker).

Digital signature algorithms use more efficient methods to create digital signatures. The most common types of digital signatures today are created by signing message digests with the originator’s private key to create a digital thumbprint of the data. Because only the message digest is signed, the signature is usually much shorter than the data that was signed. Therefore, digital signatures place a relatively low load on computer processors during the signing process, consume insignificant amounts of bandwidth, and produce small amounts of ciphertext for cryptanalysis.

The following resources contain additional information that is relevant to this section:

Logon and Authentication Technologies

Partilhar via

How Certificates Work