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.

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

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

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.

• 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

  • 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.

• 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.

  • 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.

  • 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.

  • 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, [email protected] would

not be allowed to request a certificate with a subject name of

[email protected].

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.

  • 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 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.

• 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

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
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
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.

• 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

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.

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.

  • 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
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
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
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 

CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT	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)
	The subject alternative name must include the directory GUID
	The subject alternative name requires SPN

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

Private Key Flags 

CT_FLAG_ALLOW_PRIVATE_KEY_ARCHIVAL	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 

CT_FLAG_MACHINE_TYPE	This is a machine certificate
CT_FLAG_IS_CA	This is a CA certificate
CT_FLAG_IS_CROSS_CA 0x00000800	This is a cross-CA certificate
CT_FLAG_IS_DEFAULT	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.

• 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.
RSA public key exchange algorithm
RC2 block encryption algorithm	Key length: 40 bits.	Key length: 128 bits.	Key length: 128 bits.  Salt length: Settable.
RC4 stream encryption algorithm
DES	Key length: 56 bits.
Triple DES (2-key)	Not supported.	Key length: 112 bits.
Triple DES (3-key)		Key length: 168 bits.
SHA1	Key length: 160 bits.
Message Digest 2 (MD2)	Key length: 128 bits.
Message Digest 4 (MD4)
Message Digest 5 (MD5)
SSL3 (SHAMD5)	Key length: 288 bits.
Message Authentication Code (MAC)	Key length: 512 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.

  • 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.

  • 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.

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

  • 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.

• 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.

  • 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:

1. 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.

• 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.

1. Verify that the response indicates the certificate is valid. A valid

   response indicates that the certificate has not been revoked.

2. 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.

• 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.

• 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.

• 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

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

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.

Cryptographic Operations	Intended use
	Data signing, authentication, nonrepudiation
	Data encryption and decryption
	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

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

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

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).