A certification authority (CA) processes each certificate request by using a defined set of rules. Certificate templates can be customized with a number of extensions that regulate their use. These extensions can include:

  • Issuance policies. An issuance policy (also known as an enrollment or certificate policy) is a group of administrative rules that are implemented when issuing certificates. They are represented in a certificate by an object identifier (also known as an OID) that is defined at the CA. This object identifier is included in the issued certificate. When a subject presents its certificate, it can be examined by the target to verify the issuance policy and determine if that level of issuance policy is sufficient to perform the requested action. For more information, see Issuance Requirements.

  • Application policies. Application policies give you the important ability to decide which certificates can be used for certain purposes. This allows you to issue certificates widely without being concerned that they are misused for an unintended purpose. Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of public key infrastructure (PKI) applications cannot interpret application policies, both application policies and enhanced key usage sections appear in certificates issued by a Windows Server–based CA. For more information, see Application Policy.

  • Key usage. A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. Key usage is a restriction method and determines what a certificate can be used for. This allows the administrator to issue certificates that can only be used for specific tasks or to issue certificates that can be used for a broad range of functions. For more information, see Key Usage.

  • Key archival. When subjects lose their private keys, any information that was persistently encrypted with the corresponding public key is inaccessible. To help prevent this, key archival allows you to encrypt and archive a subject's keys in the CA database when certificates are issued. If a subject loses its keys, the information can be retrieved from the database and provided to the subject. This allows the encrypted information to be recovered instead of lost. For more information, see Request Handling.

  • Basic constraints. Basic constraints are used to ensure that CA certificates are only used in certain applications. An example is the path length that can be specified as a basic constraint. A path length defines the number of CAs that are permitted below the current CA. This path length constraint ensures that CAs at the end of this path can only issue end-entity certificates, not CA certificates. For more information, see Basic Constraints.

  • OCSP No Revocation Checking. This extension appears only in the new OCSP Response Signing certificate template and duplicates derived from this template. It cannot be added to any other certificate templates. This extension instructs the CA to include the OCSP No Revocation Checking (id-pkix-ocsp-nocheck) extension in the issued certificate and not to include the authority information access and certificate revocation list (CRL) distribution point extensions in the certificate. This is because OCSP Response Signing certificates are not checked for revocation status. This extension only applies if the certificate request contains OCSP Response Signing in the enhanced key usage and application policies.