Certificates

The role of digital certificates is growing rapidly on individual computers and networks and across the Internet. Although certificates can be used with little or no user intervention, it can also be important to view and understand certificate contents, and to manage their use. You can accomplish these goals by using the Certificates snap-in.

  • What is the Certificates Snap-in?

  • Certificates Overview

  • Add the Certificates Snap-in to an MMC

  • Manage Certificates

  • Troubleshoot Certificate-Related Problems

  • Resources for Certificates


What is the Certificates Snap-in?

The Certificates snap-in is the primary tool for users and administrators to view and manage certificates for a user, computer, or service.

The Certificates snap-in allows the user to request, renew, find, view, move, copy, and delete certificates.

Why use the Certificates snap-in

The Certificates snap-in is a versatile tool for managing certificates for a user, computer, or service. It can be used to find out what certificates are stored on a computer, where they are stored, or the configuration options for those certificates.

In addition, using the Certificates snap-in, the user can launch wizards that simplify the tasks of:

  • Enrolling for new certificates

  • Renewing existing certificates

  • Finding certificates

  • Importing certificates

  • Exporting or backing up certificates

In most cases, users do not have to personally manage their certificates and their certificate stores. That can be accomplished by administrators, by policy settings, and through programs that use certificates.

Administrators are the primary users of the Certificates snap-in and, as such, they are able to perform a wide variety of certificate management tasks in their personal certificate store as well as the certificate stores for any computer or service that they have the right to administer. Users can only manage certificates in their personal store.

For information about certificates and how to use the Certificates snap-in, see the following topics:

  • Certificates Overview

  • Add the Certificates Snap-in to an MMC

  • Manage Certificates

  • Troubleshoot Certificate-Related Problems

  • Resources for Certificates


Certificates Overview

A public key certificate, usually just called a certificate, is a digitally signed statement that binds the value of a public key to the identity of the person, device, or service that holds the corresponding private key. One of the main benefits of certificates is that hosts no longer have to maintain a set of passwords for individual subjects who need to be authenticated as a prerequisite to access. Instead, the host merely establishes trust in a certificate issuer.

Most certificates in common use are based on the X.509 v3 certificate standard.

Typically, certificates contain the following information:

  • The subject's public key value.

  • The subject's identifier information, such as the name and e-mail address.

  • The validity period (the length of time that the certificate is considered valid).

  • Issuer identifier information.

  • The digital signature of the issuer, which attests to the validity of the binding between the subject's public key and the subject's identifier information.

A certificate is valid only for the period of time specified within it; every certificate contains Valid From and Valid To dates, which set the boundaries of the validity period. Once a certificate's validity period has passed, a new certificate must be requested by the subject of the now-expired certificate.

  • Using Certificates

  • Public and Private Keys

  • Certificate File Formats


Using Certificates

Certificates can be used for:

  • Authentication, which verifies the identity of someone or something.

  • Privacy, which ensures that information is only available to the intended audience.

  • Encryption, which disguises information so that unauthorized readers are unable to decipher it.

  • Digital signatures, which provide nonrepudiation and message integrity.

These services can be important to the security of your communications. In addition, many applications use certificates, such as e-mail applications and Web browsers.

Authentication

Authentication is crucial in making communication more secure. Users must be able to prove their identity to those with whom they communicate and must be able to verify the identity of others. Authentication of identity on a network is complex because the communicating parties do not physically meet as they communicate. This can allow an unethical person to intercept messages or to impersonate another person or entity.

Privacy

Whenever sensitive information is transmitted between computing devices on any type of network, users should generally use some sort of encryption to keep their data private.

Encryption

Encryption can be thought of as locking something valuable into a strong box with a key. Conversely, decryption can be compared to opening the box and retrieving the valuable item. On computers, sensitive data in the form of e-mail messages, files on a disk, and files being transmitted across the network can be encrypted using a key. Encrypted data and the key used to encrypt data are both unintelligible.

For more information about encryption and certificates, see Resources for Certificates.

Digital signatures

A digital signature is a way to ensure the integrity and origin of data. A digital signature provides strong evidence that the data has not been altered since it was signed and it confirms the identity of the person or entity who signed the data. This enables the important security features of integrity and nonrepudiation, which are essential for secure electronic commerce transactions.

Digital signatures are typically used when data is distributed in plaintext, or unencrypted form. In these cases, while the sensitivity of the message itself might not warrant encryption, there could be a compelling reason to ensure that the data is in its original form and has not been sent by an impostor because, in a distributed computing environment, plaintext can conceivably be read or altered by anyone on the network with the proper access, whether authorized or not.

Additional references

  • Certificates Overview


Public and Private Keys

In public key encryption, two different keys are used to encrypt and decrypt information. The private key is a key that is known only to its owner, while 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 within a certificate in a folder so that it is accessible to other people in the organization. The sender of a message can retrieve the user's certificate from Active Directory Domain Services, obtain the public key from the certificate, and then encrypt the message by using the recipient's 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 recipient of the message.

Additional references

  • Certificates Overview

  • Cryptographic Service Providers


Certificate File Formats

Certificate import and export operations support four file formats. Choose the format that meets your specific requirements.

  • Personal Information Exchange (PKCS #12)

    The Personal Information Exchange format (PFX, also called PKCS #12) supports secure storage of certificates, private keys, and all certificates in a certification path.

    The PKCS #12 format is the only file format that can be used to export a certificate and its private key.

  • Cryptographic Message Syntax Standard (PKCS #7)

    The PKCS #7 format supports storage of certificates and all certificates in the certification path.

  • DER-encoded binary X.509

    The Distinguished Encoding Rules (DER) format supports storage of a single certificate. This format does not support storage of the private key or certification path.

  • Base64-encoded X.509

    The Base64 format supports storage of a single certificate. This format does not support storage of the private key or certification path.

Additional references

  • Certificates Overview

  • Import a Certificate

  • Export a Certificate

  • Export a Certificate with the Private Key

  • View the Certificates in a PKCS #7 file


Add the Certificates Snap-in to an MMC

You can use the Certificates snap-in to manage certificates for a user, computer, or service account. To switch between managing certificates for your user account, a computer, or a service, you must add separate instances of the Certificates snap-in to the console.

  • For a user account

  • For a computer account

  • For a service

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add the Certificates snap-in to an MMC for a user account

  1. Click Start, type mmc in the Search programs and files box, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Under Available snap-ins, double-click Certificates, and then:

    • If you are logged on as an administrator, click My user account, and then click Finish.

    • If you are logged on as a user, the Certificates snap-in automatically opens.

  4. If you have no more snap-ins to add to the console, click OK.

  5. To save this console, on the File menu, click Save.

Additional considerations

  • User certificates can be managed by the user or by an administrator.

Local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add the Certificates snap-in to an MMC for a computer account

  1. Click Start, type mmc in the Search programs and files box, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Under Available snap-ins, double-click Certificates.

  4. Select Computer account, and then click Next.

  5. Do one of the following:

    • To manage certificates for the local computer, click Local computer, and then click Finish.

    • To manage certificates for a remote computer, click Another computer, and then type the name of the computer, or click Browse to select the computer name, and then click Finish.

  6. If you have no more snap-ins to add to the console, click OK.

  7. To save this console, on the File menu, click Save.

Additional considerations

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

  • To manage certificates for another computer, you can either create another instance of the Certificates snap-in, or right-click Certificates (Computer Name), and then click Connect to Another Computer.

Local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To add the Certificates snap-in to an MMC for a service

  1. Click Start, type mmc in the Search programs and files box, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Under Available snap-ins, double-click Certificates.

  4. Select Service account, and then click Next.

  5. Do one of the following:

    • To manage certificates for services on your local computer, click Local computer, and then click Next.

    • To manage certificates for service on a remote computer, click Another computer, and then type the name of the computer, or click Browse to select the computer name, and then click Next.

  6. Select the service for which you are managing certificates.

  7. Click Finish, and then click Close.

  8. If you have no more snap-ins to add to the console, click OK.

  9. To save this console, on the File menu, click Save.

Additional considerations

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. As a security best practice, consider using Run as to perform this procedure.

  • To manage certificates for a service on another computer, you can either create another instance of the Certificates snap-in, or right-click Certificates - Service (Service Name) on Computer Name, and then click Connect to Another Computer.


Manage Certificates

Certificates are typically issued to a particular computer, user, or service, for specific purposes, for specific durations, and often for specific recipients. As a result, at times you might need to obtain additional certificates, renew existing certificates, examine or modify the properties of a certificate, or move certificates. Although many of these tasks can be performed for a single user, computer, or service, other tasks are best performed automatically by an administrator from a server. The following sections describe common certificate management tasks and the procedure to complete them.

  • Obtain a Certificate

  • Renew a Certificate

  • View Certificates

  • Modify the Properties of a Certificate

  • Delete a Certificate

  • Find Certificates

  • Move Certificates

  • Automate Certificate Management


Obtain a Certificate

To enroll for a certificate, a certificate request must be made by the user, computer, or service that has access to the private key associated with the public key that will be part of the certificate. Users, computers, and services can autoenroll for certificates without user intervention, depending upon the public key policies established by your system administrator.

Users can also obtain certificates by:

  • Initiating autoenrollment from the Certificates snap-in.

  • Requesting certificates by using the Certificate Request Wizard.

  • Requesting a certificate over the Web.

In addition, administrators can request smart card user certificates and smart card certificates for logging on to the system on behalf of other users by using their enrollment agent certificate.

The following topics contain procedures to use for obtaining certificates:

  • Autoenroll for a Certificate from the Certificates Snap-in

  • Request Certificates by Using the Certificate Request Wizard

  • Request a Certificate Over the Web

  • Enroll for Certificates on Behalf of Other Users

Additional references

  • Manage Certificates


Autoenroll for a Certificate from the Certificates Snap-in

Many organizations will use Group Policy to automatically enroll users, computers, or services for certificates. With automatic enrollment, a user might see a reminder with a prompt to complete the enrollment. However, there might also be times when a user or administrator wants to verify that all pending automatic enrollment requests are processed. The following procedure describes how to complete this task.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To autoenroll for a certificate by using the Certificates snap-in

  1. Open the Certificate snap-in for a user or computer.

  2. In the console tree, click Certificates - Current User or Certificates (Local Computer).

  3. On the Action menu, point to All Tasks, and then click Automatically Enroll Certificates.

  4. Click Next. Select the certificates that you want to obtain, and then click Enroll. When the enrollment process is complete, click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

Additional references

  • Obtain a Certificate


Request Certificates by Using the Certificate Request Wizard

When you request certificates from a Windows-based enterprise certification authority (CA), you can use the Certificate Request Wizard located in the Certificates snap-in. This wizard guides you through the following steps:

  • Selecting the CA to which you will submit the request.

  • Selecting the appropriate certificate template to use for the new certificate.

    Certificate templates are predefined configurations that provide common settings for the certificate request. Certificate templates describe the purpose for which the requested certificate is to be used. The list of certificate templates that is available to you is determined by the certificate types that the CA is configured to issue and whether you have been granted the access rights to the certificate template by the system administrator.

  • (Optional) Using Advanced Options in the Certificate Request Wizard to select the cryptographic service provider (CSP) for the key pair associated with the certificate request.

For instructions about opening and using the Certificate Request Wizard, see Request a Certificate.

You can also use the Certificate Request Wizard to request a new certificate from an enterprise CA by using an existing key pair that is already associated with another certificate.

Additional references

  • Request a Certificate

  • Create a Custom Certificate Request

  • Save a Certificate Request in a File

  • Sign Certificate Requests

  • Obtain a Certificate


Request a Certificate

You can use the Certificates snap-in to request certificates. You can request any type of certificate that has been preconfigured and made available by an administrator of the certification authority (CA) that will process the certificate request.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To request a certificate

  1. Open the Certificates snap-in for a user or computer.

  2. In the console tree, click Certificates - Current User or Certificates (Local Computer). Select the Personal certificate store.

  3. On the Action menu, point to All Tasks, and then click Request New Certificate to start the Certificate Enrollment wizard. Click Next.

  4. Select the types of certificates that you want to request.

  5. You can click Details to review additional information about each certificate.

    If a caution symbol appears below the certificate, you might need to provide additional information before requesting that type of certificate. Click the More information is required to enroll for this certificate. Click here to configure message and provide the requested information, such as a subject name or the location of a valid signing certificate.

  6. To finish, click Enroll.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • You can use this procedure to request certificates from an enterprise CA only. To request certificates from a stand-alone CA, you need to request certificates by using Web pages. The Web page for a Windows-based CA is located at http://servername/certsrv, where servername is the name of the server hosting the CA.

  • If the requested certificate type requires approval before it is issued, you need to retrieve the completed certificate via Web pages.

  • In order to request a Digital Signature Standard (DSS) certificate from an enterprise CA, you must select the User Signature Only certificate template in the Certificate Request Wizard.

Additional references

  • Subject Names

  • Certificate Extensions

  • Cryptographic Service Providers

  • Guidelines for Using Alternate Signature Formats


Subject Names

The holder of the private key associated with a certificate is known as the subject. This can be a user, a program, or virtually any object, computer, or service.

Because the subject name can vary greatly depending on who or what the subject is, some flexibility is needed when providing the subject name in the certificate request. Windows can build the subject name automatically from subject information stored in Active Directory Domain Services (AD DS) or the subject name can be supplied manually by the subject (for example, by using certificate enrollment Web pages to create and submit a certificate request).

Enterprise certification authorities (CAs) include the Certificate Templates snap-in to configure certificate templates. Use the Subject Name tab on the certificate template properties sheet to configure subject name options.

Supply in the request

When the Supply in the request option is selected, the Use subject information from existing certificates for autoenrollment renewal requests option is available to simplify the task of adding the subject name to the certificate renewal request and to allow computer certificates to be renewed automatically. Subject information from existing certificates is not used for automatic renewal of user certificates.

The Use subject information from existing certificates for autoenrollment renewal requests option causes the certificate enrollment client to read subject name and subject alternative name information from an existing computer certificate based on the same certificate template when creating renewal requests automatically or using the Certificates snap-in. This applies to computer certificates that are expired, revoked, or within their renewal period.

Build from AD DS

When the Build from this Active Directory information option is selected, the following additional options can be configured.

Subject name format

Setting | Description
Common name | The CA creates the subject name from the common name (CN) obtained from AD DS. This should be unique within a domain but might not be unique within an enterprise.
Fully distinguished name (DN) | The CA creates the subject name from the fully distinguished name obtained from AD DS. This ensures that the name is unique within an enterprise.
Include e-mail name in subject name | If the E-mail name field is populated in the Active Directory user object, this e-mail name will be included with either the common name or fully distinguished name as part of the subject name.
None | A name value is not required for this certificate.

Include this information in alternate subject name

Setting | Description
E-mail name | If the E-mail name field is populated in the Active Directory user object, this e-mail name will be used.
DNS name | This is the fully qualified domain name (FQDN) of the subject that requested the certificate. This is most frequently used in computer certificates.
User principal name (UPN) | The user principal name is part of the Active Directory user object and will be used.
Service principal name (SPN) | The service principal name is part of the Active Directory computer object and will be used.


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

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 object identifier that is defined for a given application. This object identifier 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.

Issuance policies

Issuance policies, also referred to as certificate 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 subject type

The certificate subject type, also referred to as the certificate template information, defines the purpose of a certificate or certificate template.

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

Key usage

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

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

  • Digital signature

  • Signature is a proof of origin (nonrepudiation)

  • Certificate signing

  • CRL signing

For encryption key usage, the following options are available:

  • Key exchange without key encryption

  • Key exchange only with key encryption

Attributes

In addition to the information required by the certification authority (CA) to construct the requested certificate, a certificate request also includes attributes that describe how the certificate request was created. The certificate request attributes include the operating system version and application used to create the request, the cryptographic service provider used to generate the key pair, the certificate template the request is based on, and other details.

Attributes are automatically added to certificate requests that are created by using the Certificates snap-in and are stored in the CA database with each certificate request.

Additional references

  • Request a Certificate


Cryptographic Service Providers

A cryptographic service provider (CSP) is the program that performs authentication, encoding, and encryption services that Windows-based applications access through the Microsoft Cryptography application programming interface (CryptoAPI). Each CSP provides a different implementation of the CryptoAPI. Some provide stronger cryptographic algorithms, while others use hardware components, such as smart cards.

When you generate a request for a new certificate, the information in that request is first sent from the requesting program to CryptoAPI. CryptoAPI provides the proper data to a CSP that is installed on your computer or on a device that is accessible to your computer. If the CSP is software-based, it generates a public key and a private key, often referred to as a key pair, on your computer. If the CSP is hardware-based, such as a smart card CSP, it instructs a piece of hardware to generate the key pair.

After the keys are generated, a software-based CSP encrypts and then secures the private key. A smart card CSP stores the private key on a smart card. The smart card then controls access to the key.

The public key is sent to the certification authority (CA), along with the certificate-requester information. After the CA verifies the certificate request according to its policies, it uses its own private key to create a digital signature in the certificate and then issue it to the requester. The CA presents the certificate to the certificate requester along with the option to install it in the appropriate certificate store on the computer or hardware device.

For more information, see Request a Certificate and Guidelines for Using Alternate Signature Formats.


Create a Custom Certificate Request

Administrators usually configure certificate templates in advance so that the templates can be used to request or enroll for certificates. Custom requests can be used to modify a certificate template to meet special requirements, or to create a new certificate not based on a template. They can also be used to save a certificate request to a file for processing at a different time or on a different computer.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To create a custom certificate request

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, double-click Personal, and then click Certificates.

  3. On the Action menu, point to All Tasks, point to Advanced Operations, and then click Create Custom Request to start the Certificate Enrollment wizard. Click Next.

  4. On the Custom request page, in the Templates list, do one of the following:

    • If you know what kind of certificate you want and want to accept the default configuration options, select the appropriate certificate template.

    • If you need a completely customized certificate, select (No template) CNG key or (No template) Legacy key.

    Note

    CNG keys might not be compatible with all applications.

  5. Each certificate template includes a standard set of extensions that can indicate additional subject identification information, or it can indicate key usage information, which specifies the tasks (such as signature or encryption) for which a key can be used. If you want to use only the custom extensions that you specify, select the Suppress default extensions check box.

  6. Select the file format you want to use for your certificate request:

    • PKCS #10 is a widely used format for certificate requests.

    • CMC can be used to prepare requests that will be submitted to a non-Microsoft certification authority.

  7. Click Next.

  8. Click Details to view details of the certificate request. If you want to customize the request further, click Properties and fill in the desired options. When you are finished, click OK to close Certificate Properties, and then click Next.

  9. Enter a file name and path, and then click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

Additional references

  • Request Certificates by Using the Certificate Request Wizard


Save a Certificate Request in a File

You can prepare a certificate request for use later, or to retain a copy of the request even if it is processed at the same time as it is saved.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To save a certificate request in a PKCS #10 or CMC file

  1. Open a Web browser.

  2. Open http://servername/certsrv, where servername is the name of the Web server hosting the certification authority (CA) Web enrollment pages.

  3. Click Request a certificate, and under Advanced certificate request, click Create and submit a request to this CA.

  4. Enter any identifying information requested and any other options you require.

  5. Under Additional Options, select the file format you want to use.

  6. In Full path name, type a path and file name.

  7. Click Submit. The file is saved to your computer's desktop.

  8. If you are finished using the Web enrollment pages, close the Web browser.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • The component that enables Web enrollment in this version of Windows is different from the component that enables Web enrollment in Windows Server 2003 and Windows XP. Windows Server 2003 CA Web enrollment pages must be updated to support computers running Windows Vista or Windows 7 operating systems. For more information, see the Microsoft Help and Support Web site (http://go.microsoft.com/fwlink/?LinkId=85331).

Additional references

  • Request Certificates by Using the Certificate Request Wizard


Sign Certificate Requests

In some cases, certificate requests must be digitally signed by using a valid Enrollment Agent or Signing certificate before a certification authority (CA) will process the request.

Important

Once someone has an Enrollment Agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Because of the powerful capability of the Enrollment Agent certificate, it is strongly recommended that your organization maintain very strong security policies for these certificates.

One scenario to minimize risk of Enrollment Agent certificate misuse is to have one subordinate CA with very tight administrative controls in your organization that is only used to issue Enrollment Agent certificates. Once the initial Enrollment Agent certificates have been issued, the administrator of the CA can disable the issuance of Enrollment Agent certificates until it is needed again.

By restricting the administrators who can operate the CA service on the subordinate CA, the service can be kept online for the generation and distribution of certificate revocation lists (CRLs) if necessary.

Other CAs in the hierarchy can still issue Enrollment Agent certificates if their policy settings are changed, but you can determine whether inappropriate Enrollment Agent certificates are issued by checking the Issued Certificates log for each CA regularly.

Additional references

  • Request Certificates by Using the Certificate Request Wizard


Certificate Enrollment Policy Web Service Overview

The Certificate Enrollment Policy Web Service is an Active Directory Certificate Services (AD CS) role service that enables users and computers to obtain certificate enrollment policy information. Together with the Certificate Enrollment Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

The Certificate Enrollment Policy Web Service uses the HTTPS protocol to communicate certificate policy information to network client computers. The Web service uses the LDAP protocol to retrieve certificate policy from Active Directory Domain Services (AD DS) and caches the policy information to service client requests. In previous versions of AD CS, certificate policy information can be accessed only by domain client computers that are using the LDAP protocol. This limits policy-based certificate issuance to the trust boundaries established by AD DS forests.

Publishing enrollment policy over HTTPS enables the following new deployment scenarios:

  • Certificate enrollment across forest boundaries to reduce the number of certification authorities (CAs) in an enterprise.

  • Extranet deployment to issue certificates to mobile workers and business partners.

Additional references

  • Certificate Enrollment Web Service Overview


Certificate Enrollment Web Service Overview

The Certificate Enrollment Web Service is an Active Directory Certificate Services (AD CS) role service that enables users and computers to perform certificate enrollment by using the HTTPS protocol. Together with the Certificate Enrollment Policy Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

The Certificate Enrollment Web Service uses the HTTPS protocol to accept certificate requests from and return issued certificates to network client computers. The Certificate Enrollment Web Service uses the DCOM protocol to connect to the certification authority (CA) and complete certificate enrollment on behalf of the requester. In previous versions of AD CS, policy-based certificate enrollment can be completed only by domain member client computers that are using the DCOM protocol. This limits certificate issuance to the trust boundaries established by Active Directory domains and forests.

Certificate enrollment over HTTPS enables the following new deployment scenarios:

  • Certificate enrollment across forest boundaries to reduce the number of CAs in an enterprise.

  • Extranet deployment to issue certificates to mobile workers and business partners.

Additional references

  • Certificate Enrollment Policy Web Service Overview


Certificate Enrollment Policy Servers

Certificate enrollment policy provides the locations of certification authorities (CAs) and the types of certificates that can be requested. Organizations that are using Active Directory Domain Services (AD DS) can use Group Policy to provide certificate enrollment policy to domain members by using the Group Policy Management Console to configure the certificate enrollment policy settings. The Certificates snap-in can be used to configure certificate enrollment policy settings for individual client computers unless the Group Policy setting is configured to disable user-configured enrollment policy.

Use the following procedures to configure certificate enrollment policy settings:

  • Manage Certificate Enrollment Policy by Using Group Policy

  • Manage Certificate Enrollment Policy by Using the Certificates Snap-in

Additional references

  • Certificate Enrollment Policy Web Service Overview


Manage Certificate Enrollment Policy by Using Group Policy

This topic describes the procedures and applications used to configure the certificate enrollment policy settings.

Configuring certificate enrollment policy settings by using Group Policy

Domain Admins is the minimum group membership required to complete this procedure.

To configure certificate enrollment policy settings in Group Policy

  1. Click Start, type gpmc.msc in the Search programs and files box, and press ENTER.

  2. In the console tree, expand the forest and domain that contain the policy that you want to edit, and click Group Policy Objects.

  3. Right-click the policy that you want to edit, and then click Edit.

  4. In the console tree under Computer Configuration\Policies\Windows Settings\Security Settings, click Public Key Policies.

  5. Double-click Certificate Services Client – Certificate Enrollment Policy. For more information about the settings in this dialog box, see the "Certificate Services Client – Certificate Enrollment Policy Properties dialog box" table later in this topic.

  6. Click Add to open the Certificate Enrollment Policy Server dialog box. For more information about the settings in this dialog box, see the "Certificate Enrollment Policy Server dialog box" table later in this topic.

  7. Do one of the following:

    • To add the enrollment policy provided by Active Directory Domain Services (AD DS), select the Use default Active Directory domain controller URI check box.

    • In the Enter enrollment policy server URI box, type a certificate enrollment policy server URI.

  8. In the Authentication type list, select the authentication type required by the enrollment policy server.

  9. Click Validate, and review the messages in the Certificate enrollment policy server properties area. The Add button is available only when the enrollment policy server URI and authentication type are valid.

  10. Click Add.
Note

If the added enrollment policy server supports an enrollment policy that is already displayed in Certificate enrollment policy list, then the added server will not be displayed separately. Click Properties to verify that the added enrollment policy server is displayed in the Enrollment policy servers list. For more information about the settings in this dialog box, see the "Certificate Enrollment Policy Server Properties dialog box" table later in this topic.

User interface reference

The following tables describe the settings available in the Certificate Services Client – Certificate Enrollment Policy Properties dialog box, the Certificate Enrollment Policy Server dialog box, and the Certificate Enrollment Policy Server Properties dialog box.

Certificate Services Client – Certificate Enrollment Policy Properties dialog box

Setting | Description
Configuration Model | Specifies whether the policy setting is enabled in Group Policy.
Certificate enrollment policy list | Displays the list of enrollment policies that are included in the policy setting. One of the displayed policies must be specified as the default policy by selecting the Default check box.
Add | Opens the Certificate Enrollment Policy Server dialog box, which is used to add an enrollment policy server.
Remove | Removes the selected enrollment policy and all associated enrollment policy servers from the list.
Properties | Opens the Certificate Enrollment Policy Server Properties dialog box, which displays the policy details and list of enrollment policy servers for the selected enrollment policy.
Disable user configured enrollment policy | Disables the enrollment policy configured by users and applications. Only an enrollment policy configured in Group Policy is used.

Certificate Enrollment Policy Server dialog box

Setting Description

Use default Active Directory domain controller URI

Specifies the default enrollment policy server LDAP URI and the Windows integrated authentication type.

Configure Friendly Name

This button is available only when Use default Active Directory domain controller URI is selected.

Used to configure a name for the enrollment policy that is displayed instead of the default policy name or enrollment policy identifier. The specified name is seen by users in the Certificate Enrollment wizard and other applications.

Note

If more than one enrollment policy server supports the same enrollment policy, then each server should be configured to use the same enrollment policy friendly name. In enrollment policy Web services, the friendly name value is an application setting that is configured by using Server Manager. If the friendly name setting is already configured in each enrollment policy Web service, then add the enrollment policy Web service URIs before adding the domain controller LDAP URI. This will ensure that the friendly name values are the same.

Enter enrollment policy server URI

Specifies the URI of the Certificate Enrollment Policy Web Service. The URI must use HTTPS.

Authentication type

Specifies the type of authentication that is used to connect to the specified URI. The specified authentication type must match the authentication type that is required by the Certificate Enrollment Policy Web Service.

The following authentication types are available:

  • Anonymous. No credentials are provided when connecting to the certificate enrollment policy server.

  • Windows integrated. Windows integrated authentication uses the Kerberos protocol and is appropriate for AD DS domain members.

  • Username/password. During certificate enrollment, users will be prompted to enter a user name and password.

  • X.509 Certificate. During certificate enrollment, users will be prompted to select a certificate for authentication.

Validate

Connects to the specified URI by using the specified authentication type to verify the following details:

  • An SSL connection to the enrollment policy server exists.

  • A valid enrollment policy is returned by the enrollment policy server.

  • The enrollment policy is not already included in the Group Policy setting.

Validation is required for an enrollment policy server URI before it can be added. If the specified URI and authentication type are valid, the enrollment policy identifier and friendly name are displayed. Warning or error messages are displayed if there is a problem with validation.

Add

Adds the enrollment policy server URI and validated enrollment policy to the Group Policy setting. The Add button is available only after the enrollment policy server URI and authentication type are validated.

Certificate Enrollment Policy Server Properties dialog box

Setting | Description
Enrollment policy servers list | Displays the list of enrollment policy servers that support the enrollment policy.
Remove | Removes the selected enrollment policy server. If all enrollment policy servers are removed, the enrollment policy will also be removed.
Enable for automatic enrollment and renewal | Specifies that the enrollment policy is used for autoenrollment when autoenrollment is enabled. On computers running Windows 7 that are not members of a domain, autoenrollment is enabled by default. On computers that are members of a domain, autoenrollment must be enabled in Group Policy. See Managing Certificate Enrollment (http://go.microsoft.com/fwlink/?LinkId=143282) for autoenrollment configuration procedures.
Require strong validation during enrollment | Specifies that enrollment clients require validation of the issuing CA's certification path during enrollment.

Additional references

  • Certificate Enrollment Policy Servers

  • Certificate Enrollment Policy Web Service Overview

  • Manage Certificate Enrollment Policy by Using the Certificates Snap-in

  • Managing Certificate Enrollment (http://go.microsoft.com/fwlink/?LinkId=143282)


Manage Certificate Enrollment Policy by Using the Certificates Snap-in

This topic describes the procedures and applications used to add enrollment policy servers and manage enrollment policies by using the Certificates snap-in. These procedures can be used to configure enrollment policies that enable users to request certificates from commercial certification authorities (CAs) offering certificate enrollment services on the Internet or enterprise CAs within an organization.

Configuring certificate enrollment policy settings

The Certificate Enrollment Policy Server dialog box is used to add enrollment policy servers and can be opened by using either the Manage Enrollment Policies dialog box or the Certificate Enrollment wizard.

To configure certificate enrollment policy settings

  1. Click Start, type certmgr.msc in the Search programs and files box, and press ENTER.

  2. In the console tree, click Personal.

  3. Do one of the following:

    • On the Action menu, point to All Tasks, point to Advanced Operations, and then click Manage Enrollment Policies. Under Certificate enrollment policy list, click Add. For more information about the settings in this dialog box, see the "Manage Enrollment Polices dialog box" table later in this topic.

    • On the Action menu, point to All Tasks, and then click Request New Certificate to start the Certificate Enrollment wizard. Click Next, and then on the Select Certificate Enrollment Policy page, click Add New. For more information about the settings in this dialog box, see the "Certificate Enrollment Policy Server dialog box" table later in this topic.

  4. In the Enter enrollment policy server URI box, type a certificate enrollment policy server URI.

  5. In the Authentication type list, select the authentication type required by the enrollment policy server.

  6. Click Validate, and then review the messages in the Certificate enrollment policy server properties area. The Add button is available only after the enrollment policy server URI and authentication type are validated.

  7. Click Add.
Note

If the added enrollment policy server supports an enrollment policy that is already displayed in Certificate enrollment policy list, then the added server will not be displayed separately. Click Properties to verify that the added enrollment policy server is displayed in the Enrollment policy servers list. For more information about the settings in this dialog box, see the "Certificate Enrollment Policy Server Properties dialog box" table later in this topic.

User interface reference

The following tables describe the settings available in the Manage Enrollment Polices dialog box, the Certificate Enrollment Policy Server dialog box, and the Certificate Enrollment Policy Server Properties dialog box.

Manage Enrollment Policies dialog box

Setting | Description
Certificate enrollment policy list | Displays the list of enrollment policies that are included in the policy setting. One of the displayed policies must be specified as the default policy by selecting the Default check box.
Add | Opens the Certificate Enrollment Policy Server dialog box, which is used to add an enrollment policy server.
Remove | Removes the selected enrollment policy and all associated enrollment policy servers from the list.
Properties | Opens the Certificate Enrollment Policy Server Properties dialog box, which displays the policy details and list of enrollment policy servers for the selected enrollment policy.

Certificate Enrollment Policy Server dialog box

Setting Description

Enter enrollment policy server URI

Specifies the URI of the Certificate Enrollment Policy Web Service. The URI must use HTTPS.

Authentication type

Specifies the type of authentication that is used to connect to the specified URI. The specified authentication type must match the authentication type that is required by the Certificate Enrollment Policy Web Service.

The following authentication types are available:

  • Anonymous. No credentials are provided when connecting to the certificate enrollment policy server.

  • Windows integrated. Windows integrated authentication uses the Kerberos protocol and is appropriate for AD DS domain members.

  • Username/password. During certificate enrollment, users will be prompted to enter a user name and password.

  • X.509 Certificate. During certificate enrollment, users will be prompted to select a certificate for authentication.

Validate

Connects to the specified URI by using the specified authentication type to verify the following details:

  • An SSL connection can be made to the enrollment policy server.

  • A valid enrollment policy is returned by the enrollment policy server.

  • The enrollment policy is not already included in the Group Policy setting.

Validation is required for an enrollment policy server URI before it can be added. If the specified URI and authentication type are valid, the enrollment policy identifier and friendly name are displayed. Warning or error messages are displayed if there is a problem with validation.

Add

Adds the enrollment policy server URI and validated enrollment policy to the Group Policy setting. The Add button is available only after the enrollment policy server URI and authentication type are validated.

Certificate Enrollment Policy Server Properties dialog box

Setting | Description
Enrollment policy servers list | Displays the list of enrollment policy servers that support the enrollment policy.
Remove | Removes the selected enrollment policy server. If all enrollment policy servers are removed, the enrollment policy will also be removed.
Enable for automatic enrollment and renewal | Specifies that the enrollment policy is used for autoenrollment when autoenrollment is enabled. On computers running Windows 7 that are not members of a domain, autoenrollment is enabled by default. On computers that are members of a domain, autoenrollment must be enabled in Group Policy. See Managing Certificate Enrollment (http://go.microsoft.com/fwlink/?LinkID=143282) for autoenrollment configuration procedures.
Require strong validation during enrollment | Specifies that enrollment clients require validation of the issuing CA's certification path during enrollment.

Additional references

  • Certificate Enrollment Policy Servers

  • Certificate Enrollment Policy Web Service Overview

  • Manage Certificate Enrollment Policy by Using Group Policy

  • Managing Certificate Enrollment (http://go.microsoft.com/fwlink/?LinkID=143282)


Request a Certificate Over the Web

Certification authorities (CAs) can be accessed by using CA Web enrollment pages, which can be used to perform a variety of tasks related to requesting certificates. The default location of the CA Web enrollment pages is http://servername/certsrv, where servername is the name of the server that hosts the CA Web enrollment pages.

Additional references

  • Submit a User Certificate Request over the Web

  • Submit an Advanced Certificate Request over the Web

  • Request a Certificate by Using a PKCS #10 or PKCS #7 File

  • Check on a Pending Certificate Request

  • Obtain a Certificate


Submit a User Certificate Request over the Web

When you request certificates from a Windows-based stand-alone certification authority (CA), you use the CA Web enrollment pages. Web enrollment pages can also be used to request certificates from enterprise CAs if you want to set optional request features that are not available in the Certificate Request Wizard, such as marking the keys as exportable, setting key length, choosing the hash algorithm, or saving the request to a file.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To submit a user certificate request over the Web

  1. Open a Web browser.

  2. Open https://servername/certsrv, where servername is the name of the server hosting the CA Web enrollment pages.

  3. Click Request a certificate.

  4. On Request a Certificate, select the type of certificate you want:

    1. If the CA is an enterprise CA, click User Certificate.

    2. If the CA is a stand-alone CA, select either Web Browser Certificate or E-Mail Protection Certificate.

  5. On the Identifying Information page, enter your identifying information for the certificate request, if needed.

  6. (Optional) Click More Options to specify the cryptographic service provider (CSP) and whether you want to enable strong private key protection. (This means that you will receive a prompt every time that the private key is used.)

  7. Click Submit.

  8. Do one of the following:

    • If the Certificate Pending Web page appears, see Check on a Pending Certificate Request for the procedure to check on a pending certificate.

    • If the Certificate Issued Web page appears, click Install this certificate.

Additional considerations

  • In order for a user to obtain a certificate by using Web enrollment, an administrator must set the appropriate permissions on the certificate templates on which the requested certificate is based.

Additional references

  • Request a Certificate Over the Web

  • Check on a Pending Certificate Request


Submit an Advanced Certificate Request over the Web

The policy of a certification authority (CA) determines the types of certificates a user can request and the options they can configure. If enabled, you can use the Advanced Certificate Request Web page to set the following options for each certificate requested:

  • Certificate template (from an enterprise CA) or Type of certificate needed (from a stand-alone CA). Indicates what applications the public key in the certificate can be used for, such as client authentication or e-mail.

  • Cryptographic service provider (CSP). A CSP is responsible for creating keys, destroying them, and using them to perform a variety of cryptographic operations. Each CSP provides a different implementation of the CryptoAPI. Some provide stronger cryptographic algorithms, while others use hardware components, such as smart cards.

  • Key size. The length, in bits, of the public key on the certificate. In general, longer keys are more difficult for a malicious user to break than shorter keys.

  • Hash algorithm. A good hash algorithm makes it computationally infeasible to construct two independent inputs that have the same hash. Typical hash algorithms include MD2, MD4, MD5, and SHA-1.

  • Key usage. How the private key can be used. Exchange means that the private key can be used to enable the exchange of sensitive information. Signature means that the private key can be used only to create a digital signature. Both means that the key can be used for both exchange and signature functions.

  • Create new key set or Use existing key set. You can use an existing public and private key pair stored on your computer or create a new public and private key pair for a certificate.

  • Enable strong private key protection. When you enable strong private key protection, you will be prompted for a password every time the private key needs to be used.

  • Mark keys as exportable. When you mark keys as exportable, you can save the public key and the private key to a PKCS #12 file. This is useful if you change computers and want to move the key pair, or if you want to remove the key pair and secure them in another location.

  • Store certificates in the local computer certificate store. Select this option if the computer will need access to the private key associated with the certificate when other users are logged on. Select this option when requesting certificates intended to be issued to computers (such as Web servers) instead of certificates issued to users.

  • Request format. This section can be used to select either PKCS #10 or CMC formats. If you want to submit the request later, you can also select Save request to file.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To submit an advanced certificate request over the Web

  1. Open a Web browser.

  2. Open https://servername/certsrv, where servername is the name of the Web server hosting the CA Web enrollment pages.

  3. Click Request a certificate.

  4. Click Advanced certificate request.

  5. Click Create and submit a certificate request to this CA.

  6. Fill in any identifying information requested and any other options you require.

  7. Click Submit.

  8. Do one of the following:

    • If the Certificate Pending Web page appears, see Check on a Pending Certificate Request for the procedure to check on a pending certificate.

    • If the Certificate Issued Web page appears, click Install this certificate.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • In order for a user to obtain a certificate by using Web enrollment, an administrator must set the appropriate permissions on the certificate templates on which the requested certificate is based.

Additional references

  • Check on a Pending Certificate Request

  • Request a Certificate Over the Web


Request a Certificate by Using a PKCS #10 or PKCS #7 File

It is not always possible to submit a certificate request online to a certification authority (CA). In these instances, you might still be able to submit a certificate request in the form of a PKCS #7 or PKCS #10 file. In general, you use a PKCS #10 file to submit a request for a new certificate and a PKCS #7 file to submit a request to renew an existing certificate.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To request a certificate by using a PKCS #10 or PKCS #7 file

  1. Open a Web browser.

  2. Open https://servername/certsrv, where servername is the name of the Web server hosting the CA Web enrollment pages.

  3. Click Request a certificate, and then click Advanced certificate request.

  4. Click Submit a certificate request using a base-64-encoded CMC or PKCS #10 file or Submit a renewal request by using a base-64-encoded PKCS #7 file.

  5. In Notepad, click File, click Open, select the PKCS #10 or PKCS #7 file, click Edit, click Select all, click Edit, and then click Copy. On the Web page, click in the Saved request box. Click Edit, and then click Paste to paste the contents of the certificate request into the box.

  6. If you are connected to an enterprise CA, choose the certificate template that you want to use.

  7. If you have any attributes to add to the certificate request, enter them into Additional Attributes.

  8. Click Submit.

  9. Do one of the following:

    • If the Certificate Pending Web page appears, see Check on a Pending Certificate Request.

    • If the Certificate Issued Web page appears, click Download certificate chain. Save the file to your hard disk, and then import the certificate into your certificate store. For the procedure to import a certificate, see Import a Certificate.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • The Web server for the CA must be configured to use HTTPS authentication.

  • If you submit the request and immediately get a message asking you if you want to submit the request even though it does not contain a BEGIN or END tag, click OK.

Additional references

  • Check on a Pending Certificate Request

  • Import a Certificate

  • Export a Certificate

  • Save a Certificate Request in a File

  • Request a Certificate Over the Web


Check on a Pending Certificate Request

When you submit a certificate request to a Windows-based enterprise certification authority (CA), it is immediately processed and will either be issued or denied, unless the certificate template has been configured to require approval by a certificate manager.

When you submit a certificate request to a Windows-based stand-alone CA, it will either be immediately processed or, by default, it will be considered pending until the administrator of the CA approves or rejects the request. In the case of a pending request, the certificate requester will have to use the CA Web enrollment pages to check the status of pending certificates.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To check on a pending certificate request

  1. Open a Web browser.

  2. Open https://servername/certsrv, where servername is the name of the Web server hosting the CA Web enrollment pages.

  3. Click View the status of a pending certificate request.

  4. If there are no pending certificate requests, you will see a message to that effect. Otherwise, select the certificate request you want to check, and then click Next.

  5. Check the pending certificate requests:

    • Still pending. You must wait for the administrator of the CA to issue the certificate. To remove the certificate request, click Remove.

    • Issued. To install the certificate, click Install this certificate.

    • Denied. Contact the administrator of the CA for further information.

  6. If you are finished using the CA Web enrollment pages, close the Web browser.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

Additional references

  • Request a Certificate Over the Web


Enroll for Certificates on Behalf of Other Users

It is not always possible for users to enroll for a certificate on their own behalf. This can be the case for a user smart card certificate. By default, only domain administrators are granted permission to request a certificate on behalf of another user. However, a user other than a domain administrator can be granted permission to become an enrollment agent. A user becomes an enrollment agent by enrolling for an Enrollment Agent certificate.

Important

Once someone has an Enrollment Agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Because of the powerful capability of the Enrollment Agent certificate, it is strongly recommended that your organization maintain very strong security policies for these certificates.

Membership in the Users group and an Enrollment Agent certificate are the minimum requirements to complete this procedure. Review the details in "Additional considerations" in this topic.

To enroll for a certificate on behalf of other users

  1. Open the Certificates snap-in for a user.

  2. In the console tree, expand the Personal store, and then click Certificates.

  3. On the Action menu, point to All Tasks, point to Advanced Operations, and then click Enroll on behalf of to open the Certificate Enrollment wizard. Click Next.

  4. Browse to the Enrollment Agent certificate that you will use to sign the certificate request that you are processing. Click Next.

  5. Select the type of certificate that you want to enroll for. When you are ready to request a certificate, click Enroll.

  6. After the Certificate Renewal Wizard has successfully finished, click Close.

Additional considerations

  • User certificates can be managed by a user or by an administrator. To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

Additional references

  • Obtain a Certificate

  • Registration Authorities


Registration Authorities

A registration authority is a computer that is configured for an administrator to request and retrieve issued certificates on behalf of other users.

A registration authority does not have to be installed on the same computer as the certification authority for which it processes certificate requests.

Additional references

  • Enroll for Certificates on Behalf of Other Users


Renew a Certificate

Every certificate has a validity period. After the end of the validity period, the certificate is no longer considered an acceptable or usable credential. The Certificates snap-in enables you to renew a certificate issued from a Windows enterprise certification authority (CA) before or after the end of its validity period by using the Certificate Renewal Wizard.

You can either renew the certificate with the same key set that you used before, or you can renew a certificate with a new key set. This decision can be based on a number of factors, including the lifetime of the certificate, the length of the existing or future key, the value of the data protected by the key pair, and the possibility that a private key has been obtained by a malicious user.

Before you renew a certificate, you need to know:

  • The issuing CA.

  • (Optional) If you want a new public key and private key pair for the certificate, the cryptographic service provider (CSP) that should be used to generate the key pair.

Windows provides an expiration notification to let you know that specific user or computer certificates have expired or are about to expire. In most cases, autoenrollment will automatically renew these certificates the next time you are connected to the network and log on to the computer.

The following topics contain procedures to use for renewing certificates:

  • Renew a Certificate with a New Key

  • Renew a Certificate with the Same Key

In addition, you can renew certificates issued from both Windows enterprise CAs and Windows stand-alone CAs with the CA Web enrollment pages by pasting the contents of a PKCS #7 file. For more information, see the following topic:

  • Request a Certificate by Using a PKCS #10 or PKCS #7 File

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can be managed only by an administrator or a user who has been given the appropriate permissions.


Renew a Certificate with the Same Key

Renewing a certificate with the same key provides maximum compatibility with past uses of the accompanying key pair, but it does not enhance the security of the certificate and key pair.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To renew a certificate with the same key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, expand the Personal store, and click Certificates.

  3. In the details pane, select the certificate that you are renewing.

  4. On the Action menu, point to All Tasks, point to Advanced Operations, and then click Renew this certificate with the same key to start the Certificate Renewal Wizard.

  5. If more than one certificate is listed in the Request Certificates window, select the certificate that you want to renew. Do one of the following:

    • Use the default values to renew the certificate.

    • Click Details, and then click Properties to provide your own certificate renewal settings. You need to know the certification authority (CA) issuing the certificate.

  6. Click Enroll. After the Certificate Renewal Wizard has successfully finished, click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • Once renewed, the old certificate will be archived.

  • You can use this procedure to request certificates from an enterprise CA only. To request certificates from a stand-alone CA, you need to request certificates by using Web pages. The Web pages for a Windows-based CA are located at http://servername/certsrv, where servername is the name of the server that hosts the CA.


Renew a Certificate with a New Key

Renewing a certificate with a new key allows you to continue using an existing certificate and its associated data, while enhancing the strength of the key associated with the certificate. This can be desirable if using a new certificate would cause disruption and the existing certificate has not been compromised.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To renew a certificate with a new key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, expand the Personal store, and then click Certificates.

  3. In the details pane, select the certificate that you are renewing.

  4. On the Action menu, point to All Tasks, and then click Renew Certificate with New Key to open the Certificate Renewal Wizard.

  5. In the Certificate Renewal Wizard, do one of the following:

    • Use the default values to renew the certificate.

    • (For advanced users only) Click Details, and then click Properties to provide your own certificate renewal settings. You need to know the cryptographic service provider (CSP) and the certification authority (CA) issuing the certificate.

      You need to select the key length (measured in bits) of the public key associated with the certificate.

      You can also choose to enable strong private key protection. Enabling strong private key protection ensures that you are prompted for a password every time the private key is used. This is useful if you want to ensure that the private key is not used without your knowledge.

  6. When you are ready to request a certificate, click Enroll. After the Certificate Renewal Wizard has successfully finished, click Close.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • Once renewed, the old certificate and key pair will be archived.

  • You can use this procedure to request certificates from an enterprise CA only. To request certificates from a stand-alone CA, you need to request certificates by using Web pages. The Web pages for a Windows-based CA are located at http://servername/Certsrv, where servername is the name of the server that hosts the CA.


View Certificates

Certificates can be issued and used for many purposes. It can be useful to examine certificate stores, certificate information and properties, and information about archived and revoked certificates.

  • Display Certificate Stores

  • View Certificate Information

  • View Certificate Properties

  • View the Certificates in a PKCS #7 file

  • Display Archived Certificates

  • View Certificate Revocation List Details


Display Certificate Stores

Using the Certificates snap-in, you can display the certificate store for a user, a computer, or a service according to the purpose for which the certificates were issued or by using their logical storage categories. When you display certificates according to their storage categories, you can also choose to display the physical stores, showing the certificate storage hierarchy. (This is recommended for advanced users only.)

If you have the user rights to do so, you can import or export certificates from any of the folders in the certificate store. Additionally, if the private key associated with a certificate is marked as available for export, you can export both into a PKCS #12 file.

Windows can also publish certificates to Active Directory Domain Services (AD DS). Publishing a certificate in AD DS enables all users or computers with adequate permissions to retrieve the certificate as needed.

Certificate stores

Certificates can be displayed by purpose or by logical stores, as shown in the following table. Displaying certificates by logical stores is the default in the Certificates snap-in.

Note

The list of certificate purpose stores does not include all the possible purpose stores.

Display by Folder name Contents

Logical store

Personal

Certificates associated with private keys to which you have access. These are the certificates that have been issued to you or to the computer or service for which you are managing certificates.

Trusted Root Certification Authorities

Implicitly trusted certification authorities (CAs). Includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates from your organization and Microsoft.

If you are an administrator and want to add non-Microsoft CA certificates to this store for all computers in an Active Directory domain, you can use Group Policy to distribute trusted root certificates to your organization.

Enterprise Trust

A container for certificate trust lists. A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.

Intermediate Certification Authorities

Certificates issued to subordinate CAs. If you are an administrator, you can use Group Policy to distribute certificates to the Intermediate Certification Authorities store.

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. If you are a domain administrator, you can use Group Policy to distribute certificates to the Trusted People store.

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 such as Encrypting File System (EFS), where certificates are used for creating authorization for decrypting an encrypted file.

Trusted Publishers

Certificates from CAs that are trusted by software restriction policies. If you are a domain administrator, you can use Group Policy to distribute certificates to the Trusted Publishers store.

Disallowed Certificates

These are certificates that you have explicitly decided not to trust either by using software restriction policies or by choosing not to trust a certificate when the decision is presented to you in e-mail or a Web browser. If you are a domain administrator, you can use Group Policy to distribute certificates to the Disallowed Certificates store.

Third-Party Root Certification Authorities

Trusted root certificates from CAs other than Microsoft and your organization. You cannot use Group Policy to distribute certificates to the Third-Party Root Certification Authorities store.

Certificate Enrollment Requests

Pending or rejected certificate requests.

Active Directory User Object

Certificates associated with your user object and published in AD DS.

Purpose

Server Authentication

Certificates that server programs use to authenticate themselves to client computers.

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

File Recovery

Certificates associated with key pairs that encrypt and decrypt the symmetric key used for recovering encrypted data by EFS.

When you view certificates by logical store, you will occasionally see what appears to be two copies of the same certificate in the store. This occurs because the same certificate is stored in separate physical stores under a logical store. When the contents of the physical certificate stores are combined into one logical store view, both instances of the same certificate are displayed.

You can verify this by setting View Options to show the Physical certificate stores and then noting that the certificate is stored in separate physical stores under the same logical store. You can verify that it is the same certificate by comparing the serial numbers.

Additional references

  • Learn More About Certificate Stores

  • Display Certificates by Logical Certificate Stores

  • Display Certificates by Certificate Purpose

  • Display Archived Certificates

  • Move Certificates


Learn More About Certificate Stores

Windows stores a certificate locally on the computer or device that requested it or, in the case of a user, on the computer or device that the user used to request it. The storage location is called the certificate store. A certificate store often has numerous certificates, possibly issued from a number of different certification authorities.

You can view certificates based on their purpose (such as Client Authentication and Code Signing) or based on logical roles (such as Personal, Trusted Publishers, and Trusted Root Certification Authorities).

In addition, you can also use certificate store options to view archived certificates and the certificate stores storage structure.

Additional references

  • Display Certificates by Logical Certificate Stores

  • Display Certificates by Certificate Purpose


Display Certificates by Logical Certificate Stores

Logical certificate stores organize certificates in logical, functional categories for users, computers, and services. The use of logical certificate stores eliminates the need to store duplicates of common public key objects, such as trusted root certificates, certificate trust lists (CTLs), and certificate revocation lists (CRLs) for users, computers, and services.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To display certificates by logical certificate stores

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, click Certificates – Current, Certificates – (Local Computer), or Certificates – Service.

  3. On the View menu, click Options.

  4. Under Organize view mode by, click Logical certificate stores, and then click OK. The Logical Store Name column heading will appear in the details pane.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • When you view certificates by logical store, you will occasionally see what appear to be two copies of the same certificate in the store. This occurs because the same certificate is stored in separate physical stores under a logical store. When the contents of the physical certificate stores are combined into one logical store view, both instances of the same certificate are displayed.

    You can verify this by setting the view option to show the physical certificate stores and then noting that the certificate is stored in separate physical stores under the same logical store. You can verify that it is the same certificate by comparing the serial numbers.

Additional references

  • Display Certificate Stores


Display Certificates by Certificate Purpose

You can view and inspect certificates based on what they are intended to be used for, such as client authentication or key recovery, rather than on their logical roles.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To display certificates by certificate purpose

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, click Certificates - Current User , Certificates (Local Computer), or Certificates - Service.

  3. On the View menu, click Options.

  4. Under Organize view mode by, click Certificate purpose, and then click OK. The Intended Purposes column heading will appear in the details pane.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

Additional references

  • Display Certificate Stores


View Certificate Information

Double-click a certificate to view its properties and intended uses. This information is displayed on three tabs: General, Details, and Certification Path.

  • General Tab

  • Details Tab

  • Certification Path Tab


General Tab

You can view information about the fields, extensions, and properties that define an issued certificate by double-clicking any certificate displayed in the certificate store.

Clicking the General tab provides a general overview of the certificate, including the following information:

  • Supported uses of the certificate. Summary information, such as the applications, signing, encryption, or authentication, for which the certificate can be used. This section also explains if a certificate has expired or is not valid.

  • Entity to which the certificate was issued. The name of recipient of the certificate. Recipients can include end users, computers, or entities such as certification authorities (CAs).

  • The issuer of the certificate. The name of the CA that issued the certificate.

  • Validity period of the certificate. This includes the date the certificate becomes valid to the date that the certificate expires.

  • Issuer statement. Clicking the Issuer Statement button opens a separate window that contains additional information about the certificate or a URL where additional information can be obtained.

Additional references

  • View Certificate Information


Details Tab

The Details tab provides the following information about the certificate:

  • Version. The X.509 version number.

  • Serial number. The unique serial number that the issuing certification authority (CA) assigns to the certificate. The serial number is unique for all certificates issued by a given CA.

  • Signature algorithm. The hash algorithm that the CA uses to digitally sign the certificate.

  • Issuer. Information regarding the CA that issued the certificate.

  • Valid from. The beginning date for the period in which the certificate is valid.

  • Valid to. The final date for the period in which the certificate is valid.

  • Subject. The name of the individual, computer, device, or CA to whom the certificate is issued. If the issuing CA exists on a domain member server in your enterprise, this will be a distinguished name within the enterprise. Otherwise, this may be a full name and e-mail name or other personal identifier.

  • Public key. The public key type and length associated with the certificate.

  • Thumbprint algorithm. The hash algorithm that generates a digest of data (or thumbprint) for digital signatures.

  • Thumbprint. The digest (or thumbprint) of the certificate data.

  • Friendly name. (Optional) A display name to use instead of the name in the Subject field.

  • Enhanced key usage. (Optional) The purposes for which this certificate can be used.

There are additional X.509 v3 extensions that can be used in a certificate. If they are present, they will be displayed.

Additional references

  • Certificate Validity Periods

  • Hash Algorithms

  • Cryptographic Service Providers

  • Guidelines for Using Alternate Signature Formats


Certificate Validity Periods

The Certificates snap-in enables you to renew a certificate issued from a Windows-based enterprise certification authority (CA) before or after the end of its validity period by using the Certificate Renewal Wizard.

About certificate validity

Every certificate has a validity period. After the end of the validity period, the certificate is no longer considered an acceptable or usable credential.

You can renew the certificate either with the same key set that you used before or with a new key set.

Before you renew a certificate, you must know the issuing CA. Optionally, if you want a new public key and private key pair for the certificate, you must know the cryptographic service provider (CSP) that should be used to generate the key pair.

For more information, see Renew a Certificate with a New Key and Renew a Certificate with the Same Key.

In addition, you can renew certificates issued from both enterprise CAs and stand-alone CAs with the CA Web enrollment pages by pasting the contents of a PKCS #7 file. For more information, see Request a Certificate by Using a PKCS #10 or PKCS #7 File.


Hash Algorithms

A hash algorithm is an algorithm that produces a hash value of a piece of data, such as a message or session key. With a good hash algorithm, changes in the input data can alter every bit in the resulting hash value. For this reason, hashes are useful in detecting any modification in a data object, such as a message. Furthermore, a good hash algorithm makes it computationally infeasible to construct two independent inputs that have the same hash. Typical hash algorithms include MD5, SHA-1, and SHA-256.

Additional references

  • Details Tab


Certification Path Tab

Using the Certification Path tab, you can view the path from the selected certificate to the certification authorities (CAs) that issue the certificate.

Before a certificate is trusted, Windows must verify that the certificate comes from a trusted source. This verification process is called path validation.

Path validation involves processing public key certificates and their issuer certificates in a hierarchical fashion until the certification path terminates at a trusted, self-signed certificate. Typically, this is a root CA certificate. If there is a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is considered a non-trusted certification path.

A typical certification path includes a root certificate and one or more intermediate certificates. By clicking View Certificate, you can also learn more about the certificates for each CA in the path.

Additional references

  • View Certificate Information


View Certificate Properties

The Certificate Properties dialog box displays certificate property values on four tabs.

  • Certificate Properties General Tab

  • Certificate Properties Cross-Certificates Tab

  • Certificate Properties OCSP Tab

  • Certificate Properties Extended Validation Tab


Certificate Properties General Tab

The General tab can be used to provide a display name and description that can be used to differentiate between two certificates that are similar, such as two unique signing certificates.

You can also use the General tab to enable or disable specific purposes or uses for the certificate.

Note

You can only add purposes that are permitted under the guidelines and restrictions imposed when the certificate was first issued.

Additional references

  • View Certificate Properties


Certificate Properties Cross-Certificates Tab

Cross-certificates are used to establish trust between separate certification hierarchies, such as in separate networks or portions of a network. In these cases, cross-certificates are typically configured to:

  • Define the namespaces for which certificates issued in one certification hierarchy can be used and accepted in the second hierarchy.

  • Specify the acceptable uses of certificates issued by a cross-certified certification authority (CA).

  • Define the issuance practices that must be followed for a certificate issued by the cross-certified CA in order for them to be considered valid in the other hierarchy.

  • Create a managed trust between separate certification hierarchies.

The Cross-Certificates tab can be used to add cross-certificate download locations.

When cross-certificates are used, the information on the Cross-Certificates tab describes which of these types of restrictions, if any, have been applied.

Cross-certificates can be used in both intranet and extranet environments.

Additional references

  • View Certificate Properties


Certificate Properties OCSP Tab

The OCSP tab is used by administrators to add Online Certificate Status Protocol (OCSP) responder URLs to issuing certification authority (CA) certificates, which are distributed by Group Policy to Active Directory domain members. This enables organizations to add OCSP responders to an existing public key infrastructure (PKI) without reissuing the CA certificate or any certificates previously issued by the CA. OCSP responder URLs provided in this way are used to verify certificate revocation status of certificates issued by the CA.

Enterprise Admins is the minimum group membership required to complete this procedure.

To add an OCSP responder URL to a CA certificate

  1. Click Start, and then click Run. Type gpmc.msc, and click OK to open the Group Policy Management Console (GPMC).

  2. In the console tree, expand the forest and domain containing the policy that you want to edit, and then click Group Policy Objects.

  3. Right-click the policy that you want to edit, and then click Edit.

  4. In the console tree, under Computer Configuration, expand Policies, Windows Settings, Security Settings, Public Key Policies, and Intermediate Certification Authorities.

  5. If no CA certificates are displayed, export the CA certificate from the issuing CA, and import the certificate into Intermediate Certification Authorities. See Export a Certificate.

  6. Right-click the CA certificate, click Properties, and then click the OCSP tab.

  7. Type an OCSP responder URL, and click Add URL.

  8. If you want to prevent domain members from downloading CRLs from CRL distribution point locations specified in issued certificates, select the Disable Certificate Revocation List (CRL) check box.

    Caution

    Disabling CRLs is not recommended. OCSP takes precedence over CRLs when URLs for both are provided. However, the revocation checking process determines when downloading and caching a single CRL is more efficient than multiple OCSP requests.

  9. Click OK to save changes.
Note

Changes in Group Policy are applied by domain members periodically based on the Group Policy refresh interval, during computer startup, and during user logon. The default refresh interval is 90 minutes. To immediately refresh Group Policy on a domain member, run the Gpupdate command.

Additional references

  • Setting Up Online Responder Services in a Network (http://go.microsoft.com/fwlink/?LinkId=143098)

  • View Certificate Properties


Certificate Properties Extended Validation Tab

The Extended Validation tab is used by administrators to add an Extended Validation (EV) certificate policy to root certificates that are distributed by Group Policy. Adding the EV certificate policy to root certificates and certificates issued to intranet Web sites provides a visual indicator that a site is trustworthy.

These procedures must be completed to use EV certificates for intranet Web sites.

  1. Add an EV certificate policy to a certificate template.

  2. Add an EV certificate policy to a root certificate.

  3. Issue EV certificates to intranet Web sites.

Adding an EV certificate policy to a certificate template

In addition to the root certificate, the EV certificate policy must also be included in certificates issued to intranet Web sites and all issuing certification authority (CA) certificates in the certification path.

In this procedure, you can modify a certificate template that is used to issue Web server certificates in your organization or any certificate template that meets the following requirements:

  • The certificate template is version 2 or version 3.

  • The certificate purpose includes signature and encryption.

  • The application policy extension includes server authentication.

The issuing CA must meet the following requirements:

  • The certification path of the issuing CA certificate includes a root certificate that includes an EV certificate policy.

  • The issuing CA certificate includes the All Issuance policy or an EV certificate policy.

  • The issuing CA is an enterprise CA.

Enterprise Admins is the minimum group membership required to complete this procedure.

To add an EV certificate policy to a certificate template

  1. On the issuing CA, open Server Manager. In the console tree, expand Roles, expand Active Directory Certificate Services, then click Certificate Templates.

  2. Double-click a template that is used to issue certificates to intranet Web sites.

  3. Click the Extensions tab.

  4. Click Application Policies, and then click Edit to open the Edit Application Policies Extension dialog box.

  5. Click Add to open the Add Application Policy dialog box.

  6. Click New to open the New Application Policy dialog box.

  7. Type a name for the EV certificate policy. The name will be displayed in the extensions of issued certificates and in the template properties in the Certificate Templates snap-in.

  8. A unique object identifier (also known as OID) value is automatically generated. Copy the object identifier value for use in the following procedure. Click OK.

  9. In the Application policies list, select the policy that you created. Click OK.

  10. Click OK to save the application policy extension. On the Extensions tab, verify that the EV certificate policy is displayed in the Description of Application Policies box.

  11. Click the Security tab. Verify that the groups or users who request certificates for intranet Web sites have Read and Enroll permissions.

  12. Click OK to save the certificate template.

  13. In the console tree, double-click the CA.

  14. In the console tree, right-click Certificate Templates, click New, and then click Certificate Template to Issue to open the Enable Certificate Templates dialog box.

  15. Select the certificate template with the EV certificate policy, and click OK.

Adding an EV certificate policy to a root certificate

Enterprise Admins is the minimum group membership required to complete this procedure.

To add an EV certificate policy to a root certificate

  1. Click Start, and then click Run. Type gpmc.msc, and click OK to open the Group Policy Management Console (GPMC).

  2. In the console tree, expand the forest and domain containing the policy that you want to edit, and then click Group Policy Objects.

  3. Right-click the policy that you want to edit, and then click Edit.

  4. In the console tree, under Computer Configuration, expand Policies, Windows Settings, Security Settings, Public Key Policies, and Trusted Root Certification Authorities.

  5. If no root certificates are displayed, export the CA certificate from the root CA, and import the certificate into Trusted Root Certification Authorities. See Export a Certificate.

  6. Right-click the root certificate, click Properties, and then click the Extended Validation tab.

  7. Type an object identifier value that represents the EV certificate policy in your organization. If you created the EV certificate policy by using the previous procedure, use the same object identifier value.

  8. Click Add OID, and then click OK to save changes.
Note

Changes in Group Policy are applied by domain members periodically based on the Group Policy refresh interval, during computer startup, and during user logon. The default refresh interval is 90 minutes. To immediately refresh Group Policy on a domain member, run the Gpupdate command.

Issuing EV certificates

Follow the procedures in these related topics to request and install an EV certificate on your intranet Web server:

  • On an intranet Web server, open the Certificates snap-in for the local computer. See Add the Certificates Snap-in to an MMC.

  • Request an EV certificate. See Request Certificates by Using the Certificate Request Wizard.

  • Configure a Web site binding. See Add or Edit Site Binding Dialog Box (http://go.microsoft.com/fwlink/?LinkId=143106).

Additional references

  • Extended Validation SSL Certificates (http://go.microsoft.com/fwlink/?LinkId=142392)

  • View Certificate Properties


View the Certificates in a PKCS #7 file

If multiple certificates are exported and saved as PKCS #7 files, or if some time has passed since the file was created, it may not be obvious what certificates a PKCS #7 file contains. The following procedure allows you to inspect the certificates contained in a PKCS #7 file.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To view the certificates in a PKCS #7 file

  1. Open Windows Explorer.

  2. Locate the PKCS #7 file that contains the certificates you want to view.

  3. In the details pane, double-click the PKCS #7 file.

  4. In the console tree, double-click the folder containing the PKCS #7 file, and then click Certificates. The certificates contained in the PKCS #7 file are displayed in the details pane.

Additional considerations

  • A PKCS #7 file typically has a .p7b file name extension, but this is not always the case. As with any other data file, the creator of the file has control over the name and whether or not the .p7b extension is used.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Display Archived Certificates

Archived certificates are certificates that have expired or have been renewed. In many cases, it is good practice to retain archived certificates instead of deleting them. For example, you might keep an archived certificate to verify digital signatures on old documents that were signed by using the key on the now-expired or renewed certificate.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To display archived certificates

  1. Open the Certificates snap-in for a user, computer, or service.

  2. On the View menu, click Options.

  3. Under Show the following, select the Archived certificates check box, and then click OK.

  4. Click one of the certificate stores. In the details pane, archived certificates are identified with an A attribute in the Status column.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


View Certificate Revocation List Details

Certificate revocation lists (CRLs) are used to distribute information about revoked certificates to individuals, computers, and applications attempting to verify the validity of certificates.

The Revocation List tab lists the serial numbers of certificates that have been revoked and the date they were revoked. The Revocation entry field may also provide information about the reason a certificate was revoked.

The General tab provides additional information about the CRL itself, including the CA that issued the CRL, when the CRL was issued, the date the next CRL will be issued, and the name of the CRL distribution point.

Additional references

  • View Certificates


Modify the Properties of a Certificate

You can modify the properties of a certificate for a number of reasons:

  • Adding or modifying a display name to help differentiate it from other similar certificates.

  • Changing the purpose of the certificate by adding or disabling purposes.

  • Specifying cross-certificate download locations.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To modify the properties of a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree under the logical store that contains the certificate to modify, click Certificates.

  3. In the details pane, click the certificate that you want to modify.

  4. On the Action menu, click Properties.

  5. Make the desired changes:

    1. To change the display name of the certificate, in Friendly name, type the new name.

    2. To change the description of the certificate, in Description, type the new description.

    3. To enable all available purposes for the certificate, in Certificate purposes, click Enable all purposes for this certificate.

    4. To disable all available purposes for the certificate, in Certificate purposes, click Disable all purposes for this certificate.

    5. To designate specific purposes for the certificate, in Certificate purposes, click Enable only the following purposes, and select the appropriate check boxes.

    6. To modify cross-certificate properties, click the Cross-Certificates tab, click Specify additional Cross-Certificate download locations, enter the URL where the cross-certificates can be obtained, and click Add URL.

    7. Click OK to accept all changes.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Delete a Certificate

Certificates can become obsolete for a number of reasons, such as when they are compromised, become corrupted, or are replaced by a new certificate. However, even when a certificate is deleted, the corresponding private key is not deleted.

Important

Before deleting a certificate, be sure that you will not need it later for purposes such as reading old documents that were encrypted with the certificate's private key.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To delete a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree under the logical store that contains the certificate to delete, click Certificates.

  3. In the details pane, click the certificate that you want to delete. (To select multiple certificates, hold down CTRL and click each certificate.)

  4. On the Action menu, click Delete.

  5. Click Yes if you are sure that you want to permanently delete the certificate.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • You might want to back up the certificate by exporting it before you delete it. For the procedure to export a certificate, see Export a Certificate.


Find Certificates

The Find Certificates dialog box allows you to locate certificates based on criteria that you specify.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To find a certificate

  1. In the console tree, click the top Certificates node for a user, computer, or service.

  2. On the Action menu, click Find Certificates.

  3. Fill in the requested information. The following options are available:

    • Find in. Search in a specific certificate store, or search in all certificate stores.

    • Look in field. Allows you to limit a search to one of the following fields:

      • Issued By. The name or a portion of the name of the issuer.

      • Issued To. The name or a portion of the name of the entity to which the certificate was issued.

      • MD5 Hash. The thumbprint value or a portion of thumbprint value of the MD5 hash used for this certificate.

      • Serial Number. The serial number or a portion of the serial number of the certificate.

      • SHA1 Hash. The thumbprint value or a portion of thumbprint value of the SHA1 hash used for this certificate.

    • Contains. The name, portion of a name, serial number, portion of a serial number, thumbprint value, or portion of a thumbprint value that you want to search for.

  4. After you have entered the appropriate information, click Find Now.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Move Certificates

Many applications look for a certificate in only one certificate store. If a certificate is not in the certificate store that you need, you can move it from one store to another.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To move a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. Under the logical store that contains the certificate to move, click Certificates.

  3. In the details pane, click the certificate that you are moving. (To select more than one certificate, hold down CTRL and click each certificate.)

  4. On the Action menu, click Cut.

  5. In the console tree, click the logical store where you want to move the certificate.

  6. On the Action menu, click Paste.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • In the Certificates snap-in, you can only move an object within certificate stores. For example, you cannot move an object to a folder in Windows Explorer. To move a certificate to or from a folder on the file system or a removable storage device, see Import a Certificate, Export a Certificate, and Export a Certificate with the Private Key.


Import a Certificate

You should only import certificates obtained from trusted sources. Importing an unreliable certificate could compromise the security of any system component that uses the imported certificate.

You can import a certificate into any logical or physical store. In most cases, you will import certificates into the Personal store or the Trusted Root Certification Authorities store, depending on whether the certificate is intended for you or if it is a root certification authority (CA) certificate.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To import a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree, click the logical store where you want to import the certificate.

  3. On the Action menu, point to All Tasks, and then click Import to start the Certificate Import Wizard.

  4. Type the file name containing the certificate to be imported. (You can also click Browse and navigate to the file.)

  5. If it is a PKCS #12 file, do the following:

    • Type the password used to encrypt the private key.

    • (Optional) If you want to be able to use strong private key protection, select the Enable strong private key protection check box.

    • (Optional) If you want to back up or transport your keys at a later time, select the Mark key as exportable check box.

  6. Do one of the following:

    • If the certificate should be automatically placed in a certificate store based on the type of certificate, click Automatically select the certificate store based on the type of certificate.

    • If you want to specify where the certificate is stored, select Place all certificates in the following store, click Browse, and choose the certificate store to use.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • Enabling strong private key protection will ensure that you are prompted for a password every time the private key is used. This is useful if you want to make sure that the private key is not used without your knowledge.

  • The file from which you import certificates will remain intact after you have completed importing the certificates. You can use Windows Explorer to delete the file if it is no longer needed.


Export a Certificate

You can export a certificate in order to import a copy on a different computer or device or to store a copy in a secure location.

If you are exporting certificates for import onto a computer running Windows, PKCS #7 format is the preferred export format. This format preserves the chain of certification authorities (CAs), or the certification path, of any certificate that includes countersignatures associated with signatures.

If you are exporting certificates for import onto a computer running another operating system, it is possible that the PKCS #7 format is supported. If it is not supported, the DER-encoded binary format or the Base64-encoded format is provided for interoperability.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To export a certificate

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree under the logical store that contains the certificate to export, click Certificates.

  3. In the details pane, click the certificate that you want to export.

  4. On the Action menu, point to All Tasks, and then click Export.

  5. In the Certificate Export Wizard, click No, do not export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.)

  6. Provide the following information in the Certificate Export Wizard:

    • Click the file format that you want to use to store the exported certificate: a DER-encoded file, a Base64-encoded file, or a PKCS #7 file.

    • If you are exporting the certificate to a PKCS #7 file, you also have the option to include all certificates in the certification path.

  7. If required, in Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.

  8. In File name, type a file name and path for the PKCS #7 file that will store the exported certificate and private key. Click Next, and then click Finish.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.

  • After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the new file. If you want to remove the certificate from the certificate store, you must delete it.


Export a Certificate with the Private Key

In some cases, you may want to export a certificate with its private key to store on removable media or to use on a different computer. There are some restrictions to this procedure:

  • A private key is exportable only when it is specified in the certificate request or certificate template that was used to create the certificate.

  • Strong protection (also known as iteration count) is enabled by default in the Certificate Export Wizard when you export a certificate with its associated private key. Strong protection is not compatible with some programs, so you should clear the Enable strong protection check box if you will use the private key with any program that does not support strong protection.

Users or local Administrators is the minimum group membership required to complete this procedure. Review the details in "Additional considerations" in this topic.

To export a certificate with the private key

  1. Open the Certificates snap-in for a user, computer, or service.

  2. In the console tree under the logical store that contains the certificate to export, click Certificates.

  3. In the details pane, click the certificate that you want to export.

  4. On the Action menu, point to All Tasks, and then click Export.

  5. In the Certificate Export Wizard, click Yes, export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.)

  6. Under Export File Format, do any of the following, and then click Next.

    • To include all certificates in the certification path, select the Include all certificates in the certification path if possible check box.

    • To delete the private key if the export is successful, select the Delete the private key if the export is successful check box.

    • To export the certificate's extended properties, select the Export all extended properties check box.

  7. In Password, type a password to encrypt the private key you are exporting. In Confirm password, type the same password again, and then click Next.

  8. In File name, type a file name and path for the PKCS #12 file that will store the exported certificate and private key. Click Next, and then click Finish.

After the Certificate Export Wizard is finished, the certificate will remain in the certificate store in addition to being in the newly created file. If you want to remove the certificate from the certificate store, you will need to delete it.

Additional considerations

  • User certificates can be managed by the user or by an administrator. Certificates issued to a computer or service can only be managed by an administrator or user who has been given the appropriate permissions.

  • To open the Certificates snap-in, see Add the Certificates Snap-in to an MMC.


Automate Certificate Management

Managing certificates individually can be a laborious, if not impossible, task. Many organizations will manage certificates by using Group Policy settings configured on a server and applied to client computers in a domain, group, or organizational unit. The following options can be viewed on a client computer, although they are typically configured on a server.

  • Credential Roaming

  • Certificate Path Validation


Credential Roaming

Credential roaming allows organizations to store certificates and private keys in Active Directory Domain Services (AD DS) separately from application state or configuration information.

How credential roaming works

Credential roaming uses existing logon and autoenrollment mechanisms to securely download certificates and keys to a local computer whenever a user logs on and, if desired, remove them when the user logs off. In addition, the integrity of these credentials is maintained under any conditions, such as when certificates are updated and when users log on to more than one computer at a time.

The following steps describe how digital credential roaming works.

  1. A user logs on to a client computer that is connected to an Active Directory domain.

  2. As part of the logon process, credential roaming Group Policy is applied to the user's computer.

  3. If this is the first time that credential roaming is being used, the certificates in the user's store on the client computer are copied to AD DS.

  4. If the user already has certificates in AD DS, the certificates in the user's certificate store on the client computer are compared to the certificates stored for the user in AD DS.

  5. If the certificates in the user's certificate store are current, then no further action is taken. However, if more recent certificates for the user are stored in AD DS, then these credentials are copied to the client computer. If more recent certificates for the user are stored on the client computer, then these credentials are copied to AD DS.

  6. If additional certificates are needed on the client computer, outstanding certificate autoenrollment requests are processed.

    Note

    Newly issued certificates are stored in the certificate store on the client computer and replicated to AD DS.

  7. When the user logs on to another client computer connected to the domain, the same Group Policy setting is applied, and credentials are once again replicated from AD DS. Credential roaming synchronizes and resolves any conflicts between certificates and private keys from any number of client computers that the user logs on to, as well as in AD DS.

    Important

    In multi-domain environments and domains with multiple domain controllers, credentials may not be immediately available when a user logs on to the network by using one domain controller shortly after being issued a certificate on a computer that validates the user's identity against a different domain controller. The credentials will only become available after replication has been completed between the two domains or domain controllers.

  8. When the user's certificate expires, the old certificate is automatically archived in the user's profile on the computer and in AD DS.

Credential roaming is triggered any time a private key or certificate in the user's local certificate store changes, whenever the user locks or unlocks the computer, and whenever Group Policy is refreshed.

All certificate-related communication between components on the local computer and between the local computer and AD DS is signed and encrypted.


Certificate Path Validation

As certificate use for secure communication and data protection is increasing, administrators can use certificate trust policy to enhance their control of certificate use and public key infrastructure performance by using certificate path validation settings.

Certificate path validation settings in Group Policy allow administrators to:

  • Manage Trusted Root Certificates. These policy settings control which root certification authority (CA) certificates and peer trust certificates in the user certificate and root certificate stores can be trusted.

  • Manage Trusted Publishers. These policy settings control which code signing (Authenticode) certificates can be accepted for use in the organization and blocks certificates that are not trusted according to policy.

  • Manage Network Retrieval and Path Validation. These policy settings can be used to compensate for situations in which downloads of a certificate revocation list (CRL) fail because the CRL is too large and network conditions are not optimal.

  • Manage Revocation Checking Policy. These policy settings can be used to coordinate use of CRLs and Online Responders during revocation checking. This option also allows an administrator to extend the lifetime of responses received from an Online Responder or CRL.


Manage Trusted Root Certificates

Because of the growing variety of certificates in use today and the growing number of certificate issues, some organizations may want to manage certificate trust and prevent users in the domain from configuring their own set of trusted root certificates. In addition, some organizations may want to identify and distribute specific trusted root certificates to enable business scenarios where additional trust relationships are needed.

This topic includes procedures for the following tasks:

  • Managing trusted root certificates for a local computer

  • Managing trusted root certificates for a domain

  • Adding certificates to the Trusted Root Certification Authorities store for a local computer

  • Adding certificates to the Trusted Root Certification Authorities store for a domain

Managing trusted root certificates for a local computer

Administrators is the minimum group membership required to complete this procedure.

To manage trusted root certificates for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Under Available snap-ins, click Local Group Policy Object Editor, click Add, select the computer whose local Group Policy object (GPO) you want to edit, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. In the console tree, go to Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  6. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  7. Select the Define these policy settings check box.

  8. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates check boxes.

  9. Under Root certificate stores, select the root CAs that the client computers can trust, and then click OK to apply the new settings.

Managing trusted root certificates for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To manage trusted root certificates for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  8. Select the Define these policy settings check box.

  9. Under Per user certificate stores, clear the Allow user trusted root CAs to be used to validate certificates and Allow users to trust peer trust certificates option in the Per User Certificate Stores check boxes.

  10. Under Root certificate stores, select the root CAs that the client computers can trust, and then click OK to apply the new settings.

Adding certificates to the Trusted Root Certification Authorities store for a local computer

Administrators is the minimum group membership required to complete this procedure.

To add certificates to the Trusted Root Certification Authorities store for a local computer

  1. Click Start, click Start Search, type mmc, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Under Available snap-ins, click Certificates, and then click Add.

  4. Under This snap-in will always manage certificates for, click Computer account, and then click Next.

  5. Click Local computer, and click Finish.

  6. If you have no more snap-ins to add to the console, click OK.

  7. In the console tree, double-click Certificates.

  8. Right-click the Trusted Root Certification Authorities store.

  9. Click Import to import the certificates and follow the steps in the Certificate Import Wizard.

Adding certificates to the Trusted Root Certification Authorities store for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To add certificates to the Trusted Root Certification Authorities store for a domain

  1. Open Server Manager, and under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  2. After the Installation Results page shows that the installation of the GPMC was successful, click Close.

  3. Click Start, point to Administrative Tools, and then click Group Policy Management.

  4. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  5. Right-click the Default Domain Policy GPO, and then click Edit.

  6. In the GPMC, go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  7. Right-click the Trusted Root Certification Authorities store.

  8. Click Import and follow the steps in the Certificate Import Wizard to import the certificates.

Additional references

  • Certificate Path Validation


Manage Trusted Publishers

Software signing is being used by a growing number of software publishers and application developers to verify that their applications come from a trusted source. However, many users do not understand or pay little attention to the signing certificates associated with applications that they install.

The policy settings in the Trusted Publishers tab of the certificate path validation policy allows administrators to control which certificates can be accepted as coming from a trusted publisher.

This topic includes procedures for the following tasks:

  • Configuring the trusted publishers policy settings for a local computer

  • Configuring the trusted publishers policy settings for a domain

  • Allowing only administrators to manage certificates used for code signing for a local computer

  • Allowing only administrators to manage certificates used for code signing for a domain

Configuring the trusted publishers policy settings for a local computer

Administrators is the minimum group membership required to complete this procedure.

To configure the trusted publishers policy settings for a local computer

  1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.

  2. In the console tree under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  3. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  4. Select the Define these policy settings check box, select the policy settings that you want to apply, and then click OK to apply the new settings.

Configuring the trusted publishers policy settings for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To configure the trusted publishers policy settings for a domain

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  3. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  4. Click Start, point to Administrative Tools, and then click Group Policy Management.

  5. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  6. Right-click the Default Domain Policy GPO, and then click Edit.

  7. In the console tree under Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  8. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  9. Select the Define these policy settings check box, select the policy settings that you want to apply, and then click OK to apply the new settings.

Allowing only administrators to manage certificates used for code signing for a local computer

Administrators is the minimum group membership required to complete this procedure.

To allow only administrators to manage certificates used for code signing for a local computer

  1. Click Start, type gpedit.msc in the Search programs and files, and then press ENTER.

  2. In the console tree under Default Domain Policy or Local Computer Policy, double-click Computer Configuration, Windows Settings, and Security Settings, and then click Public Key Policies.

  3. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  4. Select the Define these policy settings check box.

  5. Under Trusted publisher management, click Allow only all administrators to manage Trusted Publishers, and then click OK to apply the new settings.

Allowing only administrators to manage certificates used for code signing for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To allow only administrators to manage certificates used for code signing for a domain

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  3. After the Installation Results page shows that the installation of the GPMC was successful, click Close.

  4. Click Start, point to Administrative Tools, and then click Group Policy Management.

  5. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  6. Right-click the Default Domain Policy GPO, and then click Edit.

  7. In the console tree under Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  8. Double-click Certificate Path Validation Settings, and then click the Trusted Publishers tab.

  9. Select the Define these policy settings check box, implement the changes you want, and then click OK to apply the new settings.

Additional references

  • Certificate Path Validation


Manage Network Retrieval and Path Validation

To be effective, certificate-related data such as trusted root certificates, cross- certificates, and certificate revocation lists (CRLs) must be updated in a timely manner. Network retrieval and path validation settings allow administrators to:

  • Automatically update certificates in the Microsoft Root Certificate Program.

  • Configure retrieval timeout values for CRLs and path validation (larger default values may be useful if network conditions are not optimal).

  • Enable issuer certificate retrieval during path validation.

  • Define how frequently cross-certificates are downloaded.

This topic includes procedures for the following tasks:

  • Increasing the retrieval timeout option for large CRLs for a local computer

  • Increasing the retrieval timeout option for large CRLs for a domain

Managing CRL retrieval

Obtaining timely certificate revocation data is an important element in secure certificate use. However, problems can arise if validation checking and retrieval of certificate revocation data and cross-certificates time out because more data is being transferred than originally anticipated.

Network retrieval options in public key Group Policy allow administrators to manage network retrieval timeout values.

Increasing the retrieval timeout option for large CRLs for a local computer

Administrators is the minimum group membership required to complete this procedure.

To increase the retrieval timeout option for large CRLs for a local computer

  1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.

  2. In the console tree under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  3. Double-click Certificate Path Validation Settings, and then click the Network Retrieval tab.

  4. Select the Define these policy settings check box.

  5. Under Default retrieval timeout settings, enter a timeout value in the Default URL retrieval timeout (in seconds) box, and then click OK to apply the new settings.

Increasing the retrieval timeout option for large CRLs for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To increase the retrieval timeout option for large CRLs for a domain

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  3. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  4. Click Start, point to Administrative Tools, and then click Group Policy Management.

  5. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  6. Right-click the Default Domain Policy GPO, and then click Edit.

  7. In the console tree under Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  8. Double-click Certificate Path Validation Settings, and then click the Network Retrieval tab.

  9. Select the Define these policy settings check box.

  10. Under Default retrieval timeout settings, enter a timeout value in the Default URL retrieval timeout (in seconds) box, and then click OK to apply the new settings.

Additional references

  • Certificate Path Validation


Manage Revocation Checking Policy

Revocation of a certificate invalidates a certificate as a trusted security credential prior to the scheduled expiration of its validity period. A public key infrastructure (PKI) depends on distributed verification of credentials in which there is no need for direct communication with the central trusted entity that vouches for the credentials.

To effectively support certificate revocation, the client computer must determine whether the certificate is valid or has been revoked. To support a variety of scenarios, Active Directory Certificate Services supports industry-standard methods of certificate revocation. These include publication of certificate revocation lists (CRLs) and delta CRLs in several locations for clients to access, including Active Directory Domain Services, Web servers, and network file shares. In Windows, revocation data can also be made available in a variety of settings through Online Certificate Status Protocol (OCSP) responses.

Note

CRLs are published to specified network locations on a periodic basis where they can be downloaded by client computers. OCSP responses are digitally signed responses indicating whether an individual certificate has been revoked or suspended, or if its status is unknown. OCSP responders get their data from published CRLs, or they can be updated directly from the certificate status database of a certification authority (CA).

In addition, public key Group Policy allows administrators to enhance the use of CRLs and OCSP responders, particularly in situations where extremely large CRLs or network conditions detract from performance.

This topic includes procedures for the following tasks:

  • Configuring revocation settings on a local computer

  • Configuring revocation settings for a domain

  • Extending the validity period for CRL and OCSP responses for a local computer

  • Extending the validity period for CRL and OCSP responses for a domain

Configuring revocation settings on a local computer

Administrators is the minimum group membership required to complete this procedure.

To configure revocation settings on a local computer

  1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.

  2. In the console tree under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  3. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  4. Select the Define these policy settings check box, select the policy settings that you want to apply, and then click OK to apply the new settings.

Configuring revocation settings for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To configure revocation settings for a domain

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  3. After the Installation Results page shows that the installation of the Group Policy Management Console (GPMC) was successful, click Close.

  4. Click Start, point to Administrative Tools, and then click Group Policy Management.

  5. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  6. Right-click the Default Domain Policy GPO, and then click Edit.

  7. In the console tree under Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  8. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  9. Select the Define these policy settings check box, select the policy settings that you want to apply, and then click OK to apply the new settings.

Extending the validity period for CRL and OCSP responses for a local computer

Administrators is the minimum group membership required to complete this procedure.

To extend the validity period for CRL and OCSP responses for a local computer

  1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.

  2. In the console tree under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  3. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  4. Select the Define these policy settings check box, and then select the Allow CRL and OCSP responses to be valid longer than their lifetime check box.

  5. In the Default time the validity period can be extended box, enter a value of time (in hours), and then click OK to apply the new settings.

Extending the validity period for CRL and OCSP responses for a domain

Domain Admins is the minimum group membership required to complete this procedure.

To extend the validity period for CRL and OCSP responses for a domain

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Features Summary, click Add Features. Select the Group Policy Management check box, click Next, and then click Install.

  3. After the Installation Results page shows that the installation of the GPMC was successful, click Close.

  4. Click Start, point to Administrative Tools, and then click Group Policy Management.

  5. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy GPO that you want to edit.

  6. Right-click the Default Domain Policy GPO, and then click Edit.

  7. In the console tree under Computer Configuration\Windows Settings\Security Settings, click Public Key Policies.

  8. Double-click Certificate Path Validation Settings, and then click the Revocation tab.

  9. Select the Define these policy settings check box, and then select the Allow CRL and OCSP responses to be valid longer than their lifetime check box.

  10. In the Default time the validity period can be extended box, enter a value of time (in hours), and then click OK to apply the new settings.

Additional references

  • Certificate Path Validation


Troubleshoot Certificate-Related Problems

This section lists a few common issues you may encounter when using the Certificates snap-in or working with certificates.

What problem are you having?

  • I cannot enroll for a new certificate by using the Certificate Request Wizard.

  • I get a message indicating that I need to enroll for a new certificate, but the enrollment process fails.

  • I cannot enroll for a new certificate over the Web.

  • I am no longer able to use my certificate.

I cannot enroll for a new certificate by using the Certificate Request Wizard.

Cause: The type of certificate you are requesting is not available.

Solution: Contact your administrator.

I get a message indicating that I need to enroll for a new certificate, but the enrollment process fails.

Cause: In order for clients to receive certificates, they need to be able to contact the certification authority (CA) that will process the request.

Solution: If a CA is intended to be offline, the certificate request must be processed manually by copying it to removable media and physically carrying it to the CA for processing. Otherwise, wait until the CA is once again online and try again.

Cause: If the CA is online but enrollment still fails, autoenrollment permissions might have been configured incorrectly.

Solution: An administrator must modify the access control list on the certificate template to grant Read, Enroll, and Autoenroll permissions for the intended recipients of the certificate.

I cannot enroll for a new certificate over the Web.

Cause: The CA Web Enrollment pages on the server that you are attempting to contact need to be updated to process certificate requests from this version of Windows.

Solution: Contact your administrator.

I am no longer able to use my certificate.

Cause: The certificate has expired or is not valid for the intended purpose.

Solution: View the certificate to determine its expiration date. If it has expired, use the Certificate Renewal Wizard to renew the certificate. If it has not expired, verify that the certificate is valid for your desired purpose. If it is not, request a new certificate for the desired purpose.

Additional references

  • Resources for Certificates


Resources for Certificates

For more information about certificates, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?LinkID=143356).


Guidelines for Using Alternate Signature Formats

Selecting the option Use alternate signature formats implements the PKCS #1 v2.1 signature format for certificates.

For certificates based on RSA algorithms, PKCS #1 v2.1 specifies separate object identifiers for the hash algorithm and for the asymmetric algorithm. (In PKCS #1 v.1.5, only one object identifier is used to identify both the hash and asymmetric algorithms.) In addition, if you select the alternate signature format for certificates based on RSA algorithms, an enhanced cryptographic formula is used to create the signature.

For certificates not based on RSA algorithms, selecting Use alternate signature formats specifies separate object identifiers for the hash algorithm and for the asymmetric algorithm.

Before using the alternate signature format in your certificates, you need to verify that certification authorities (CAs) and client computers can accept these signature formats. Versions of Windows earlier than Windows Server 2008 cannot validate certificates that use the alternate signature format. In addition, certificates issued by using the alternate signature format might not be compatible with CAs or client computers that are not running Windows.

For more information about PKCS #1 v.2.1, see PKCS #1: RSA Cryptography Standard (http://go.microsoft.com/fwlink/?LinkId=66621) on the RSA Laboratories Web site.

For more information about the RSA implementation of the signature format, see Raising the Standard for RSA Signatures: RSA-PSS (http://go.microsoft.com/fwlink/?LinkId=66622) on the RSA Laboratories Web site.


BitLocker Certificates

Recovery of a BitLocker-protected drive can be accomplished by a data recovery agent that has been configured with the proper certificate. Before a data recovery agent can be configured for a drive, you must add the data recovery agent from Public Key Policies in either the Group Policy Management Console (GPMC) or the Local Group Policy Editor. You must also enable and configure the Provide the unique identifiers for your organization policy setting to associate a unique identifier to a new drive that is enabled with BitLocker. Identification fields are required for management of data recovery agents on BitLocker-protected drives. BitLocker will only manage and update data recovery agents when an identification field is present on a drive and is identical to the value configured on the computer.

Certificate requirements

A certificate must meet the following key usage and enhanced key usage requirements before it can be used to encrypt a drive with BitLocker:

  • The key usage attribute must be either none, Key Encipherment, or one of the following key usage values:

    CERT_DATA_ENCIPHERMENT_KEY_USAGE

    CERT_KEY_AGREEMENT_KEY_USAGE

    CERT_KEY_ENCIPHERMENT_KEY_USAGE

  • The enhanced key usage attribute must be either none or one of the following:

    1.3.6.1.4.1.311.67.1.1

    Any enhanced key usage object identifier supported by your certification authority

The BitLocker object identifier is set to 1.3.6.1.4.1.311.67.1.1 by default. You can use Group Policy to change this value if, for example, you want to share an existing certificate with BitLocker. If the certificate belongs to a data recovery agent and is only used to recover BitLocker-protected data, it is recommended that it also have one of these attributes, but it is not mandatory. No certificate validation occurs when adding a data recovery agent to a drive.

Configuring a data recovery agent and an identification field for BitLocker

The following procedures describe how to configure a data recovery agent and an identification field for BitLocker.

Local Administrators is the minimum group membership required to complete these procedures.

To configure a data recovery agent

  1. Open either the GPMC or the Local Group Policy Editor.

  2. In the console tree under Computer Configuration\Windows Settings\Security Settings\Public Key Policies, right-click BitLocker Drive Encryption.

  3. Click Add Data Recovery Agent to start the Add Recovery Agent Wizard. Click Next.

  4. On the Select Recovery Agents page, click Browse Folders, and select a .cer file to use as a data recovery agent. Once the file is selected, it will be imported and will appear in the Recovery agents list in the wizard. Multiple data recovery agents can be specified. After you have specified all the data recovery agents that you want to use, click Next.

  5. The Completing the Add Recovery Agent page of the wizard displays a list of the data recovery agents that will be added to the Group Policy. Click Finish to confirm the data recovery agents, and close the wizard.

After the wizard closes, the data recovery agents appear in the details pane.
To configure an identification field

  1. In the GPMC or Local Group Policy Editor, expand the console tree to Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption, and then click BitLocker Drive Encryption to show the policy settings.

  2. In the details pane, double-click the Provide the unique identifiers for your organization policy setting.

  3. Click Enable. In BitLocker Identification Field, enter the identification field for your organization.

  4. Click OK to apply and close the policy setting.
Note

Drives that were encrypted with BitLocker before an identification field was configured will not have data recovery agents assigned to them due to the absence of an identification field. It is possible to use Windows Management Instrumentation (WMI) or the Manage-bde command-line tool to set an identification field on a previously encrypted drive. When using Manage-bde, the identification field will be set to the value specified in the Provide the unique identifiers for your organization policy setting. For more information about using WMI or Manage-bde, see http://go.microsoft.com/fwlink/?LinkId=143347.


Public Key Infrastructures

A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), and registration authorities that verify and authenticate the validity of each entity that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For more information about planning a PKI and using public key cryptography, see Active Directory Certificate Services Resources.

The Microsoft PKI supports a hierarchical CA model that is scalable and provides consistency with a growing number of commercial and other CA products.

In its simplest form, a certification hierarchy consists of a single CA. However, a hierarchy frequently contains multiple CAs with clearly defined parent/child relationships. In this model, the child subordinate CAs are certified by their parent CA-issued certificates, which bind a CA's public key to its identity. The CA at the top of a hierarchy is referred to as the root CA. The child CA of a root CA is called a subordinate CA. For more information, see Types of Certification Authorities.

In Windows, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA that has a valid CA certificate in the hierarchy. Thus, a root CA is a very important point of trust in an organization and should be secured accordingly. For more information, see CA Certificates.

There are several practical reasons for setting up multiple subordinate CAs, including:

  • Usage. Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.

  • Organizational divisions. There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.

  • Geographic divisions. Organizations may have entities at multiple physical sites. Network connectivity between these sites may require individual subordinate CAs for many or all sites.

  • Load balancing. If your PKI will be used to issue and manage a large number of certificates, having only one CA can result in considerable network load for that single CA. Using multiple subordinate CAs to issue the same kind of certificates divides the network load between CAs.

  • Backup and fault tolerance. Multiple CAs increase the possibility that your network will always have operational CAs available to respond to user requests.

A CA hierarchy can also provide administrative benefits, including:

  • Flexible configuration of the CA security environment to tailor the balance between security and usability. For example, you may choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for subordinate CAs, due to cost or usability considerations.

  • The ability to "turn off" a specific portion of the CA hierarchy without affecting established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific business unit without affecting other parts of the organization.

Additional references

  • Active Directory Certificate Services Overview


Enterprise Certification Authorities

Enterprise certification authorities (CAs) can issue certificates for purposes such as digital signatures, secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a domain by using a smart card.

An enterprise CA has the following characteristics:

  • Requires access to Active Directory Domain Services (AD DS).

  • Uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain.

  • Publishes user certificates and certificate revocation lists (CRLs) to AD DS. In order to publish certificates to AD DS, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains.

Note

You must be a member of the Domain Admins group or be an administrator with Write access to AD DS to install an enterprise root CA.

An enterprise CA issues certificates based on a certificate template. The following functionality is possible when you use certificate templates:

  • Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in AD DS that determines whether the certificate requester is authorized to receive the type of certificate they have requested.

  • The certificate subject name can be generated automatically from the information in AD DS or supplied explicitly by the requester.

  • The policy module adds a predefined list of certificate extensions to the issued certificate. The extensions are defined by the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.

  • Autoenrollment can be used to issue certificates.

Additional references

  • Types of Certification Authorities


EFS Certificates

Encrypting File System (EFS) encryption is based on the key pairs associated with certificates. In most managed environments, certificates are issued by a certification authority (CA) running in the domain. Users can automatically be issued a certificate by the CA without manual intervention. The EFS certificates settings include a list of certificate templates available in the domain so that you can specify which certificate template to use for autoenrollment.

Note

The list includes all certificate templates present in the domain. An administrator must correctly configure the CA so that the certificates can be issued. Some displayed certificates might not be accessible.

In cases where a certificate cannot be issued by a CA, EFS can use a self-signed certificate created on the local computer. You can choose to disable this functionality or specify a default key length.

EFS templates

This identifies the name of the certificate template used to request an EFS certificate from a CA. The Basic EFS template is used by default. If you have created custom EFS templates for use in your organization, click Browse to locate and assign the template for use.

Self-signed certificates

The default setting allows EFS to generate self-signed certificates when a CA is not available. Some organizations do not allow self-signed certificates to be used because of concerns about information security risks. Disabling this setting will require that a user have been granted a certificate from a trusted CA before being able to use EFS.

If you allow the use of self-signed certificates, you can specify the encryption key length used when encrypting files and folders. By default, EFS uses the 2,048-bit key size for self-signed RSA certificates and the 256-bit key for elliptical curve cryptography (ECC) certificates (such as those required for Suite B compliance). The following RSA and ECC keys are available:

  • 1,024-bit RSA

  • 2,048-bit RSA

  • 4,096-bit RSA

  • 8,192-bit RSA

  • 16,384-bit RSA

  • 256-bit ECC

  • 384-bit ECC

  • 521-bit ECC

Long key sizes increase security but might cause encryption to be slower.


Encrypting File System (EFS)

Encrypting File System (EFS) is a core file encryption technology used to store encrypted files on NTFS file system volumes. Encrypted files cannot be used unless the user has access to the keys required to decrypt the information.

You do not have to manually decrypt an encrypted file before you can use it. You can open and change the file as you normally do. Once you encrypt a file or folder, you work with the encrypted file or folder just as you do with any other file or folder.

Using EFS is similar to using permissions on files and folders. Both methods can be used to restrict access to data. However, an intruder who gains unauthorized physical access to your encrypted files or folders will be prevented from reading them. If the intruder tries to open or copy your encrypted file or folder, he or she receives an access denied message. Permissions on files and folders do not protect against unauthorized physical attacks.

You encrypt or decrypt a folder or file by setting the encryption property for folders and files just as you set any other attribute such as read-only, compressed, or hidden. If you encrypt a folder, all files and subfolders created in the encrypted folder are automatically encrypted. We recommend that you encrypt at the folder level.

You can also encrypt or decrypt a file or folder by using the Cipher command.

When you work with encrypted files and folders, consider the following information:

  • Only files and folders on NTFS volumes can be encrypted. However, you can use Web distributed authoring and versioning (WebDAV), which also works with NTFS, to transfer files in encrypted form.

  • Files or folders that are compressed cannot also be encrypted. If the user marks a file or folder for encryption, that file or folder will be uncompressed.

  • Encrypted files are decrypted if you copy or move the file to a volume that is not an NTFS volume.

  • Moving unencrypted files into an encrypted folder will automatically cause those files to be encrypted in the new folder. However, the reverse operation will not automatically decrypt files. Files must be explicitly decrypted.

  • Files marked with the System attribute cannot be encrypted, nor can files in the system root directory structure.

  • Encrypting a folder or file does not protect against the deletion or listing of files or directories. Anyone with the appropriate permissions can delete or list encrypted folders or files. For this reason, using EFS in combination with NTFS permissions is recommended.

  • You can encrypt or decrypt files and folders located on a remote computer that has been enabled for remote encryption, but the data that is transmitted over the network by this process is not encrypted. Other protocols, such as Secure Socket Layer/Transport Layer Security (SSL/TLS) or Internet Protocol security (IPsec) must be used to encrypt data while it is in transmission over the network. (You can also use WebDAV, as described in the first bullet point, to transmit the file in encrypted form.)

EFS policy settings

You can use Group Policy to configure a number of EFS policy settings. These policy settings are located in Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Encrypting File System.

Allow or disallow EFS

You can choose to allow or disallow the use of EFS altogether. If you do not configure any policy settings for EFS, it is allowed.

If you choose to allow EFS, you can also select a number of options, such as whether to automatically encrypt a user's Documents folder, to require a smart card for use with EFS, to cache keys created based on a smart card, to create a caching-capable user key from a smart card, or to notify users to make backup copies of their encryption keys.

Allow or disallow Elliptic Curve Cryptography encryption

You can choose to allow or disallow the use of Elliptic Curve Cryptography (ECC) encryption with EFS. If you do not configure any policy settings for EFS, ECC encryption is allowed. ECC encryption enables organization to be compliant with Suite B encryption standards.

Suite B is a set of cryptographic algorithms. Suite B's components are: Advanced Encryption Standard (AES) with key sizes of 128 and 256 bits for symmetric encryption, Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures, Elliptic Curve Diffie-Hellman (ECDH) for key agreement, and Secure Hash Algorithm (SHA-256 and SHA-384) for message digest.


Types of Certification Authorities

A certification authority (CA) accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to apply its digital signature to the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a public key infrastructure (PKI). A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).

A CA can be an outside entity, such as VeriSign, or it can be a CA that you create for use by your organization by installing Active Directory Certificate Services (AD CS). Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a domain account, employee badge, driver's license, notarized request, or physical address. Identification checks such as this often warrant an onsite CA, so that organizations can validate their own employees or members.

Microsoft enterprise CAs use a person's user account credentials as proof of identity. In other words, if you are logged on to a domain and request a certificate from an enterprise CA, the CA can authenticate your identity based on your account in Active Directory Domain Services (AD DS).

Every CA also has a certificate to confirm its own identity, issued by another trusted CA or, in the case of root CAs, issued by itself. It is important to remember that anyone can create a CA. Therefore, a user or administrator must decide whether to trust that CA and, by extension, the policies and procedures that the CA has in place for confirming the identity of the entities that are issued certificates by that CA.

Root and subordinate CAs

A root CA is meant to be the most trusted type of CA in an organization's PKI. If the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization becomes vulnerable. Therefore, both the physical security and the certificate issuance policy of a root CA are normally more rigorous than those for subordinate CAs. While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.

A subordinate CA is a CA that has been issued a certificate by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other CAs that are more subordinate. Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.

For more information about certification hierarchies, see Public Key Infrastructures.

Enterprise and stand-alone CAs

This version of AD CS supports the installation of stand-alone CAs and enterprise CAs. For information about the operational characteristics of enterprise CAs and stand-alone CAs, see Enterprise Certification Authorities and Stand-Alone Certification Authorities.

Additional references

  • Active Directory Certificate Services Overview


Key Caching in Encrypting File System

To optimize performance, Encrypting File System (EFS) will cache keys used in the encryption or decryption process. You can control when these cached items are removed from memory.

Key caching

Windows optimizes the caching of user keys on a server that is being used for remote server encryption. By default, the server will cache up to 15 user key handles in memory to increase encryption performance on the server. However, the default can be changed by an administrator by editing the following registry value:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\UserCacheSize DWORD

The acceptable values are between 5 and 30 for this registry value.

Note

Private keys are not stored in cached memory; they are only stored as a handle to the CryptoAPI key container.

Changing key caching properties

You can change the performance of key caching by selecting options on the Cache tab of the Encrypting File System Properties page in Group Policy or the local computer policy.

For example, you can configure an automatic timeout value, and specify that the cache should be cleared when the user locks the workstation. The cache is also cleared when the user logs off or the computer is restarted.


View Security Catalog Details

A security catalog is a signed container that holds hashes of other files and additional details of the catalog file including the catalog file version, digital signature, and effective date.

The Security Catalog tab lists the files contained within the catalog and significant values associated with each file.

The General tab contains information about the security catalog itself, including the version number, effective date, algorithms, and subject usage.


View Certificate Trust List Details

A certificate trust list (CTL) enables you to limit the purpose and the validity period for which a certificate is trusted, even when it may have been issued for multiple purposes.

Typically, a CA can issue certificates for a wide variety of purposes, such as secure e-mail or client authentication. There might be situations in which you want to limit the trust of certificates that are issued by a particular CA, especially if the CA is outside your organization. In these situations, creating a CTL and distributing it by using Group Policy can be useful.

The Trust List tab lists the certificates contained within the CTL and significant values associated with each certificate.

The General tab contains information about the CTL itself, including the version number, effective date, algorithms, and subject usage.


CA Certificates

Certification authority (CA) certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship between the two CAs.

A certificate that is issued by a CA to itself is referred to as a trusted root certificate, because it is intended to establish a point of ultimate trust for a CA hierarchy.

Once the trusted root has been established, it can be used to authorize subordinate CAs to issue certificates on its behalf.

CA certificates can also be used to establish trust relationships between CAs in two different public key infrastructure (PKI) hierarchies.

In all of these cases, the CA certificate is critical to defining the certificate path and usage restrictions for all end-entity certificates issued for use in the PKI.

The appropriate configuration of CA certificates for the organization's needs is one of the most powerful tools that an organization has to implement appropriate PKI security. CA certificates contain special configuration data that regulate the CAs to which they are issued. These configuration options can:

  • Define the organizational namespace in which certificates issued by the subordinate CA can be issued and trusted.

  • Specify the acceptable uses of certificates issued by the subordinate CA.

  • Define the issuance guidelines that must be followed in order for a certificate issued by the subordinate CA to be considered valid.

  • Create a managed trust between separate certification hierarchies.


Active Directory Certificate Services Resources

  • For extensive evaluation, design, deployment, troubleshooting, and technical reference information, including white papers and Knowledge Base (KB) articles, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?LinkID=85613).

  • For information about developing applications that use Active Directory Certificate Services (AD CS), see Win32 and COM Security Development (http://go.microsoft.com/fwlink/?LinkId=92771).

  • For public information about public key infrastructures (PKIs), see the National Institute of Standards and Technology (NIST) PKI Web site (http://go.microsoft.com/fwlink/?LinkId=92772).

  • For information about the PKI X.509 (pkix) working group, see the Internet Engineering Task Force (IETF) Web site (http://go.microsoft.com/fwlink/?LinkID=29885).


Active Directory Certificate Services Overview

Active Directory Certificate Services (AD CS) role services can be set up on servers running operating systems including Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design requires careful planning and lab testing before you deploy AD CS in a production environment. Although you can deploy AD CS with a single server for a single certification authority (CA), deployments can involve multiple servers configured as root CAs, policy CAs, and issuing CAs, and other servers configured as Online Responders.

The following table lists the AD CS components that can be configured on different editions of Windows Server 2008 R2.

Components | Web edition | Standard edition | Enterprise edition | Datacenter edition
CA | No | Yes | Yes | Yes
Network Device Enrollment Service | No | No | Yes | Yes
Online Responder service | No | No | Yes | Yes
CA Web Enrollment | No | Yes | Yes | Yes
Certificate Enrollment Web Service | No | Yes | Yes | Yes
Certificate Enrollment Policy Web Service | No | Yes | Yes | Yes

The following features are available on servers running Windows Server 2008 R2 that have been configured as CAs.

AD CS features | Web edition | Standard edition | Enterprise edition | Datacenter edition
Customizable version 2 and version 3 certificate templates | No | Yes | Yes | Yes
Key archival | No | No | Yes | Yes
Role separation | No | No | Yes | Yes
Certificate manager restrictions | No | No | Yes | Yes
Delegated enrollment agent restrictions | No | No | Yes | Yes
Certificate enrollment across forest boundaries | No | No | Yes | Yes

Customizing AD CS

AD CS includes programmable interfaces so that developers can create support for additional transports, policies, and certificate properties and formats. For information about customizing AD CS, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

Managing AD CS

The following Microsoft Management Console (MMC) snap-ins can be used to manage AD CS:

  • Certification Authority. The primary tool for managing a CA, certificate revocation, and certificate enrollment.

  • Certificate Templates. Used to duplicate and configure certificate templates for publication to Active Directory Domain Services (AD DS) and for use with enterprise CAs.

  • Online Responder. Used to configure and manage Online Certificate Status Protocol (OCSP) responders.

  • Enterprise PKI. Used to monitor multiple CAs, certificate revocation lists (CRLs), and authority information access locations, and to manage AD CS objects that are published to AD DS.

  • Certificates. Used to view and manage certificate stores for a computer, user, or service.

Additional references

  • Public Key Infrastructures

  • Types of Certification Authorities

  • Certificate Enrollment Web Service Overview

  • Certificate Enrollment Policy Web Service Overview

  • Configuring Certificate Enrollment Web Services for Enrollment Across Forest Boundaries


Stand-Alone Certification Authorities

Stand-alone certification authorities (CAs) can issue certificates for purposes such as digital signatures, secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions), and authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

A stand-alone CA has the following characteristics:

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet.

  • When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. (This does not need to be done when submitting a request to an enterprise CA because the enterprise user's information is already in AD DS and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer's Security Accounts Manager database.

  • By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request. The administrator has to perform these tasks because the certificate requester's credentials are not verified by the stand-alone CA.

  • Certificate templates are not used.

  • The administrator has to explicitly distribute the stand-alone CA's certificate to the domain user's trusted root store, or users must perform that task themselves.

  • If a cryptographic provider supporting elliptic curve cryptography (ECC) is used, a stand-alone CA will honor every key usage for the ECC key. For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

When a stand-alone CA uses AD DS, the CA has these additional features:

  • If a member of the Domain Admins group or an administrator with Write access to a domain controller installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.

  • If a stand-alone CA is installed by a member of the Domain Admins group of the parent domain in the enterprise, or by an administrator with Write access to AD DS, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to AD DS.

Additional references

  • Types of Certification Authorities