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

Archive Settings

User Input Settings

Other Request Handling Settings

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

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

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

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

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

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

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

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

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

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

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

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.
  
  

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

Certificate Policies

Certificate Template Information

Key Usage

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

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

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.

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.

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.

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

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

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

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

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.

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

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

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

Note

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

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

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

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.

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.
   
   Note
   
   
   • Windows Server 2003, Windows 2000, and Windows XP can only verify a CRL that was signed by the same private key used to sign the issued certificate. These versions of Windows do not support CRLs signed by an entity other than the CA that signed the issued certificate.
     
     
2. 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.
   
   
3. 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 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.

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

Note

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

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

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

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

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

Note

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