Certification Authority Web Enrollment Guidance

Applies To: Windows Server 2012 R2, Windows Server 2012

The Certification Authority (CA) Web Enrollment role service provides a set of web pages that allow interaction with the Certification Authority role service. These web pages are located at https:// /certsrv, where is the name of the server that hosts the hosts the CA Web Enrollment pages. The certsrv portion of the URL should always be in lowercase letters; otherwise, users may have trouble checking and retrieving pending certificates.

The CA Web Enrollment role service pages require that you secure them with secure sockets layer (SSL) / transport layer security (TLS)> If you do not, you will see an error: «In order to complete the certificate enrollment, the Web site for the CA must be configured to use HTTPS authentication.» To resolve this issue, you must configure HTTPS authentication, which is discussed in the TechNet Wiki article: Active Directory Certificate Services (AD CS): Error: «In order to complete certificate enrollment, the Web site for the CA must be configured to use HTTPS authentication».

The CA Web Enrollment role service pages allow you to connect to the CA by using a web browser and performing common tasks, such as:

Requesting certificates from the CA.

Requesting the CA’s certificate.

Submitting a certificate request by using a PKCS #10 file.

Retrieving the CA’s certificate revocation list (CRL).

CA Web Enrollment is useful when you interact with a stand-alone CA because the Certificates Microsoft Management Console (MMC) snap-in cannot be used to interact with a stand-alone CA. Enterprise CAs can accept certificate requests through the Certificates snap-in or the CA Web Enrollment role service pages.

Starting in Windows ServerВ® 2008, the CA Web Enrollment role service includes updated sample web pages for web-based certificate enrollment operations. These web pages are updated to work together with the CertEnroll component (available starting with Windows Vista). These web pages also work together with Xenroll.

The certificate enrollment Web pages starting in Windows Server 2008 detect the client operating system and then select the appropriate control.

If a client computer is running Windows Server 2003 or Windows XP, the certificate enrollment web pages use Xenroll.

If the client computer is running at least Windows VistaВ® or Windows Server 2008, the CA Web Enrollment role service uses CertEnroll.

In WindowsВ® 8, CA Web Enrollment pages will work only with Internet Explorer 10 for the desktop. Starting in Windows Server 2012 R2, client computers that run Windows XP are not supported for web enrollment.

For more information about CertEnroll and Xenroll, see the following:

CA for Web Enrollment

You can install CA Web Enrollment on a server that is not a CA to separate web traffic from the CA. Installing CA Web Enrollment configures the computer as an enrollment registration authority. You must select a CA to be used with the CA Web Enrollment pages. The CA that CA Web Enrollment uses is called the Target CA in the user interface. You can select the target CA by using the CA name or the computer name that is associated with the CA. Click the Select button to locate the CA that you want to use.

Web Enrollment Configuration

If you install the CA Web Enrollment pages on a computer that is not the target CA, the computer account where the CA Web Enrollment pages are installed must be trusted for delegation. See the following resources for more information:

If CA Web Enrollment pages installation fails on a migrated CA, it could be that the setup status in the registry is incorrectly set. For more information, see Certification Authority Web Enrollment Configuration Failed 0x80070057 (WIN32: 87)

Use the CA Web Enrollment pages

If you have been granted access permissions, you can perform the following tasks from the CA Web Enrollment pages:

Request a basic certificate.

Request a certificate with advanced options.

This gives you greater control over the certificate request. Some of the user-selectable options that are available in an advanced certificate request include:

Cryptographic service provider (CSP) options. The name of the cryptographic service provider, the key size (1024, 2048, and so on), the hash algorithm (such as SHA/RSA, SHA/DSA, MD2, or MD5) and the key specification (exchange or signature).

Key generation options. Create a new key set or use an existing key set, mark the keys as exportable, enable strong key protection, and use the local computer store to generate the key.

Additional options. Save the request to a PKCS #10 file or add specific attributes to the certificate.

Check a pending certificate request. If you have submitted a certificate request to a stand-alone certification authority, you need to check the status of the pending request to see if the certification authority has issued the certificate. If the certificate has been issued, it will be available for you to install it.

Retrieve the certification authority’s certificate to place in your trusted root store or install the entire certificate chain in your certificate store.

Retrieve the current base and delta CRLs.

Submit a certificate request by using a PKCS #10 file or a PKCS #7 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. Submitting requests with files is useful when the certificate requester is unable to submit a request online to the certification authority.

Request a basic certificate

To use Internet Explorer to request a basic certificate

In Internet Explorer, connect to https:// /certsrv, where is the host name of the computer running the CA Web Enrollment role service.

Click Request a certificate.

On Request a Certificate, click User Certificate.

On the User Certificate Identifying Information page, do one of the following:

Comply to the message «No further identifying information is required. To complete your certificate, press Submit.»

Enter your identifying information for the certificate request.

(Optional) Click More Options to specify the cryptographic service provider (CSP) and choose if you want to enable strong private key protection. (You receive a prompt every time you use the private key that is associated with the certificate.)

Click Submit.

Do one of the following:

If you see the Certificate Pending page, the CA administrator will have to approve the request before you can retrieve and install the certificate.

If you see the Certificate Issued page, click Install this certificate.

Request a certificate with advanced options

To use Internet Explorer to create an advanced certificate request

In Internet Explorer, connect to https:// /certsrv, where is the host name of the computer running the CA Web Enrollment role service.

Click Request a certificate.

Click Advanced certificate request.

Click Create and submit a certificate request to this CA.

Fill in the requested identifying information and other options that you require.

Click Submit.

Do one of the following:

If you see the Certificate Pending page, the CA administrator will have to approve the request before you can retrieve and install the certificate.

If you see the Certificate Issued page, click Install this certificate.

Check a pending certificate request

To check a pending certificate request using Internet Explorer

In Internet Explorer, open https:// /certsrv, where is the hostname of the computer running the CA Web Enrollment role service.

Click View the status of a pending certificate request.

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

Check the following pending certificate requests:

Still pending. You must wait for the administrator of the certification authority 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 certification authority for further information.

Retrieve the CA certificate

To retrieve a CA certificate by using Internet Explorer

In Internet Explorer, connect to https:// /certsrv, where is the name of the computer running the CA Web Enrollment role service.

Click Download a CA certificate, certificate chain, or CRL.

Do one of the following:

If you want to trust all the certificates that are issued by this CA, click Install this CA certificate chain.

If the CA has been renewed, you have the choice of which version of the CA certificate you want to download.

Select the encoding method that you want to use for the CRL: DER or Base 64.

Under CA Certificate, click the CA certificate that you want to download, and then click Download CA certificate or click Download CA certificate chain.

In File Download, click Open this file from its current location, and then click OK.

When the Certificate dialog box appears, click Install this certificate.

In the Certificate Import Wizard, click Automatically select the certificate store based on the type of certificate.

Retrieve the current base and delta CRLs

To retrieve a certificate revocation list by using Internet Explorer

In Internet Explorer, connect to https:// /certsrv, where is the name of the computer running the CA Web Enrollment role service.

Click Download a CA certificate, certificate chain, or CRL.

Click the encoding method that you want to use for the CRL, DER or Base 64.

Do one of the following:

Click Download CA certificate.

Click Download CA certificate chain.

Click Download latest base CRL.

Click Download latest delta CRL.

The latest base CRL must already be installed for the delta CRL to function.

When the File Download dialog box appears, click Save. Select a folder on your computer to store the .crl file, and then click Save.

Open Windows Explorer and locate the .crl file you just saved.

Right-click the .cer or .crl file and click Install Certificate or Install CRL, and then click Next.

When the Certificate Import Wizard opens, click Automatically select the certificate store based on the type of certificate.

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

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

In Internet Explorer, connect to https:// /certsrv, where is the name of the computer running the CA Web Enrollment role service.

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

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.

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 the Saved request scroll box. Click Edit, and then click Paste to paste the contents of certificate request into the scroll box.

If you are connected to an enterprise CA, choose the certificate template that you want to use. By default, the appropriate template is named Subordinate Certification Authority.

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

Click Submit.

Do one of the following:

If you see the Certificate Pending web page, see Check a pending certificate request earlier in this document.

If you see the Certificate Issued web page, click Download certificate chain. Choose to save the file to your hard disk drive, and then import the certificate into your certificate store.

Certification Authority Guidance

Applies To: Windows Server 2012 R2, Windows Server 2012

A certification authority (CA) is responsible for attesting to the identity of users, computers, and organizations. The CA authenticates an entity and vouches for that identity by issuing a digitally signed certificate. The CA can also manage, revoke, and renew certificates.

A certification authority can refer to following:

An organization that vouches for the identity of an end user

A server that is used by the organization to issue and manage certificates

By installing the Certification Authority role service of Active Directory Certificate Services (AD CS), you can configure your Windows server to act as a CA.

Before you install the CA role service, you should:

Plan a public key infrastructure (PKI) that is appropriate for your organization.

Install and configure a Hardware Security Module (HSM) according to the HSM vendor instructions, if you are planning to use one.

Create an appropriate CAPolicy.inf, if you want to modify the default installation settings.

Plan for PKI

To ensure that your organization can take full advantage of your Active Directory Certificate Services (AD CS) installation, you must plan the PKI deployment appropriately. You should determine how many CAs you will install and in what configuration before you install any CA. Creating an appropriate PKI design can be time consuming, but it is important for the success of your PKI.

For more information and resources, see PKI Design Guidance in Microsoft TechNet.

Use an HSM

Using a hardware security module (HSM) can enhance the security of the CA and the PKI.

An HSM is a dedicated hardware device that is managed separately from the operating system. These modules provide a secure hardware store for CA keys, in addition to a dedicated cryptographic processor to accelerate signing and encrypting operations. The operating system utilizes the HSM through the CryptoAPI interfaces, and the HSM functions as a cryptographic service provider (CSP) device.

HSMs typically are PCI adapters, but they are also available as network-based appliances, serial devices, and USB devices. If an organization plans to implement two or more CAs, you can install a single network-based HSM and share it among multiple CAs.

To set up a CA by using an HSM, the HSM must be installed and configured before you set up any CAs with keys that will be stored on the HSM.

Consider a CAPolicy.inf file

The CAPolicy.inf file is not required to install AD CS, but it can be used to customize the settings of the CA. The CAPolicy.inf file contains various settings that are used when installing a CA or when renewing the CA certificate. The CAPolicy.inf file must be created and stored in the %systemroot% directory (typically C:\Windows) for it to be used.

The settings that you include in the CAPolicy.inf file depend largely on the deployment type that you want to create. For example, a root CA might have a CAPolicy.inf file that looks like this:

Whereas a CAPolicy.inf file for an enterprise that is issuing a CA might look like this:

Select CA configuration settings

The following sections describe the configuration options that you will select after installing the CA binary installation files.

Select setup type

Enterprise CAs are integrated with Active Directory Domain Services (AD DS). They publish certificates and certificate revocation lists (CRLs) to AD DS. Enterprise CAs use information that is stored in AD DS, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the Enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type.

If you want to enable automated certificate approval and automatic user certificate enrollment, use Enterprise CAs to issue certificates. These features are available only when the CA infrastructure is integrated with Active Directory. Additionally, only Enterprise CAs can issue certificates that enable smart card sign-in, because this process requires that smart card certificates are mapped automatically to the user accounts in Active Directory.

By default, you must be a member of the Enterprise Admins group to install and configure an Enterprise CA. If you want a low-privileged domain administrator to install and configure an Enterprise CA, see Delegated Installation for an Enterprise Certification Authority.

Stand-alone CAs do not require AD DS, and they do not use certificate templates. If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests that are submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but this is less secure, and it is usually not recommended because the requests are not authenticated.

From a performance perspective, using stand-alone CAs with automatic issuance enables you to issue certificates at a faster rate than you can by using enterprise CAs. However, unless you are using automatic issuance, using stand-alone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request. For this reason, stand-alone CAs are best used with public key security applications on extranets and on the Internet, when users do not have user accounts and when the volume of certificates to be issued and managed is relatively low

You must use stand-alone CAs to issue certificates when you are using a non-Microsoft directory service or when AD DS is not available. You can use both enterprise and stand-alone certification authorities in your organization, as explained in the following table.

Option	Enterprise CA	Standalone CA
Publish certificates in Active Directory and use Active Directory to validate certificate requests.	Yes	No
Take the CA offline.	Not recommended	Yes
Configure the CA to issue certificates automatically.	Yes	Not recommended
Allow administrators to approve certificate requests manually.	Yes	Yes
Allow for the use of certificate templates.	Yes	No
Authenticate requests to Active Directory.	Yes	No

Choose CA type

Enterprise and stand-alone CAs can be configured as root CAs or as subordinate CAs. Subordinate CAs can further be configured as intermediate CAs (also referred to as a policy CA) or issuing CAs

Designate a root CA

A root CA is the CA that is at the top of a certification hierarchy. It must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.

Since the root CA is the top CA in the certification hierarchy, the Subject field of the certificate that is issued by a root CA has the same value as the Issuer field of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at the enterprise level or locally by the individual IT administrator.

A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject’s public key corresponds to the identity information shown in the subject field of the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore, it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys.

The root CA is the most important CA in your hierarchy. If your root CA is compromised, all CAs in the hierarchy and all certificates issued from it are considered compromised. You can maximize the security of the root CA by keeping it disconnected from the network and by using subordinate CAs to issue certificates to other subordinate CAs or to end users.

Subordinate CAs

CAs that are not root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but it serves as a higher certifying authority to one or more subordinate CAs.

An intermediate CA is often referred to as a policy CA because it is typically used to separate classes of certificates that can be distinguished by policies. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline.

It is not possible to convert a root CA to a subordinate CA, or vice versa.

Store a private key

The private key is part of the CA identity, and it must be protected from compromise. Many organizations protect CA private keys by using a hardware security module (HSM). If an HSM is not used, the private key is stored on the CA computer. For more information, see Hardware Security Module (HSM) in Microsoft TechNet.

Offline CAs should be stored in secure locations and not connected to the network. Issuing CAs use their private keys when issuing certificates, so the private key must be accessible (online) while the CA is in operation. In all cases, the CA and its private key on the CA should be physically protected.

Locate an existing key

If you already have an existing private key that you want to use during installation, you can use the Existing Key screen to locate that key. You can use the Change button to modify the cryptographic provider, and optionally, the CA that you want to search for an existing key.

Locate an existing certificate

If you already have a certificate that contains the private key for the CA, you can use the Existing Certificate screen to locate it. You can use the Import button to open the Import Existing Certificate dialog box, and then locate your existing PKCS #12 file.

Select cryptographic options

Selecting cryptographic options for a certification authority (CA) can have significant security, performance, and compatibility implications for that CA. Although the default cryptographic options may be suitable for most CAs, the ability to implement custom options can be useful to administrators and application developers with a more advanced understanding of cryptography and a need for this flexibility. Cryptographic options can be implemented by using cryptographic service providers (CSPs) or key storage providers (KSPs).

When using an RSA certificate for a CA, ensure that the key length is at least 2048 bits. You must not attempt to use an RSA certificate below 1024 bits for the CA. The CA service (certsvc) will not start if an RSA key of less than 1024 bits is installed.

CSPs are hardware and software components in Windows operating systems that provide generic cryptographic functions. CSPs can be written to provide a variety of encryption and signature algorithms.

KSPs can provide strong key protection for computers running a minimum server version Windows Server 2008 R2 and a minimum client version of Windows Vista.

When you select the provider, hash algorithm, and key length, carefully consider what cryptographic options the applications and devices that you intend to use can support. Although it’s a best practice to select the strongest security options, not all applications and devices can support these. If your support requirements change and you are then able to use the stronger security options, such as migrating to a KSP and a stronger hash algorithm, see Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP).

Allow administrator interaction when the private key is accessed by the CA is an option that is typically used with hardware security modules (HSMs). This allows the cryptographic provider to prompt the user for additional authentication when the private key of the CA is accessed. This option can be used to help prevent unapproved use of the CA and its private key by requiring the administrator to enter a password before every cryptographic operation.

The built-in cryptographic providers support specific key lengths and hash algorithms as described in the following table.

Cryptographic provider	Key lengths	Hash algorithm
Microsoft Base Cryptographic Provider v1.0	— 512 — 1024 — 2048 — 4096	— SHA1 — MD2 — MD4 — MD5
Microsoft Base DSS Cryptographic Provider	— 512 — 1024	SHA1
Microsoft Base Smart Card Crypto Provider	— 1024 — 2048 — 4096	— SHA1 — MD2 — MD4 — MD5
Microsoft Enhanced Cryptographic Provider v1.0	— 512 — 1024 — 2048 — 4096	— SHA1 — MD2 — MD4 — MD5
Microsoft Strong Cryptographic Provider	— 512 — 1024 — 2048 — 4096	— SHA1 — MD2 — MD4 — MD5
RSA#Microsoft Software Key Storage Provider	— 512 — 1024 — 2048 — 4096	— SHA1 — SHA256 — SHA384 — SHA512 — MD2 — MD4 — MD5
DSA#Microsoft Software Key Storage Provider	— 512 — 1024 — 2048	SHA1
ECDSA_P256#Microsoft Software Key Storage Provider	256	— SHA1 — SHA256 — SHA384 — SHA512
ECDSA_P384#Microsoft Software Key Storage Provider	384	— SHA1 — SHA256 — SHA384 — SHA512
ECDSA_P521#Microsoft Software Key Storage Provider	521	— SHA1 — SHA256 — SHA384 — SHA512
RSA#Microsoft Smart Card Key Storage Provider	— 1024 — 2048 — 4096	— SHA1 — SHA256 — SHA384 — SHA512 — MD2 — MD4 — MD5
ECDSA_P256#Microsoft Smart Card Key Storage Provider	256	— SHA1 — SHA256 — SHA384 — SHA512
ECDSA_P384#Microsoft Smart Card Key Storage Provider	384	— SHA1 — SHA256 — SHA384 — SHA512
ECDSA_P521#Microsoft Smart Card Key Storage Provider	521	— SHA1 — SHA256 — SHA384 — SHA512

Establish a CA name

Before you configure certification authorities (CAs) in your organization, you should establish a CA naming convention.

You can create a name by using any Unicode character, but you might want to use the ANSI character set if interoperability is a concern. For example, certain types of routers will not be able to use the Network Device Enrollment Service to enroll for certificates if the CA name contains special characters such as an underscore.

If you use non-Latin characters (such as Cyrillic, Arabic, or Chinese characters), your CA name must contain fewer than 64 characters. If you use only non-Latin characters, your CA name can be no more than 37 characters in length.

In Active Directory Domain Services (AD DS), the name that you specify when you configure a server as a CA becomes the common name of the CA, and this name is reflected in every certificate that the CA issues. For this reason, it is important that you do not use the fully qualified domain name for the common name of the CA. This way, malicious users who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a potential security vulnerability.

The CA name should not be identical to the name of the computer (NetBIOS or DNS name). Also, you cannot change the name of a server after Active Directory Certificate Services (AD CS) is installed without invalidating all the certificates that are issued by the CA. For additional considerations regarding CA names, see TechNet Wiki article: Considerations for Certification Authority (CA) Names.

To change the server name after AD CS is installed, you must uninstall the CA, change the name of the server, reinstall the CA using the same keys and modify the registry to use the existing CA keys and database. You do not have to reinstall a CA if you rename a domain; however, you will have to reconfigure the CA to support the name change.

Obtain a certificate request

After a root certification authority (CA) has been installed, many organizations will install one or more subordinate CAs to implement policy restrictions on the public key infrastructure (PKI) and to issue certificates to end clients. Using at least one subordinate CA can help protect the root CA from unnecessary exposure. When you install a subordinate CA, you must obtain a certificate from the parent CA.

If the parent CA is online, you can use the Send a certificate request to a parent CA option, and select the parent CA by CA name or computer name.

If the parent CA is offline, you should use the Save a certificate request to file on the target machine option. The procedure for this will be unique to the parent CA. At a minimum, the parent CA should provide a file that contains the subordinate CA’s newly issued certificate, preferably its full certification path.

If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA that you install must be able to build a valid CA chain when it starts. Do the following to create a valid certification path:

Install the parent CA’s certificate in the Intermediate Certification Authorities certificate store of the computer if the parent CA is not a root CA.

Install the certificates of any other intermediate CA in the chain.

Install the certificate of the root CA into the Trusted Root Certification Authorities store.

These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

Verify the validity period

Certificate-based cryptography uses public-key cryptography to protect and sign data. Over time, attackers could obtain data that was protected with the public key and attempt to derive the private key from it. Given enough time and resources, this private key could be compromised, effectively rendering all protected data unprotected. Also the names that are guaranteed by a certificate may need to be changed over time. Because a certificate is a binding between a name and a public key, when either of these change, the certificate should be renewed.

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

CAs cannot issue certificates that are valid beyond their own validity period. A best practice is to renew the CA certificate when half of its validity period is expired. When installing a CA, you should plan this date and ensure that it is recorded as a future task.

Choose a CA database

As in many databases, the certification authority’s database is a file on the hard drive. In addition to this file, other files serve as the transaction logs, and they receive all modifications to the database before the changes are made. Because these files may be accessed frequently and simultaneously, it is best to keep the database and transaction logs on separate hard drives or high-performance disk configurations, such as striped volumes.

The location of the certificate database and log files are kept in the following registry location:

The registry contains following values:

You can move the certificate database and log files after installation. For information, see article 283193in the Microsoft Knowledge Base.

Configure the CA

After a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) and CRL distribution point (CDP) extensions before the CA issues any certificates. The AIA extension specifies where to find up-to-date certificates for the CA. The CDP extension specifies where to find up-to-date CRLs that are signed by the CA. These extensions apply to all certificates that are issued by that CA.

Configuring these extensions ensures that this information is included in each certificate that the CA issues so that it is available to all clients. This ensures that PKI clients experience the least possible number of failures due to unverified certificate chains or certificate revocations, which can result in unsuccessful VPN connections, failed smart card sign-ins, or unverified email signatures.

As a CA administrator, you can add, remove, or modify CRL distribution points and the locations for CDP and AIA certificate issuance. Modifying the URL for a CRL distribution point only affects newly issued certificates. Previously issued certificates will continue to reference the original location, which is why you should establish these locations before your CA distributes any certificates.

Consider these guidelines when you configure CDP extension URLs:

Avoid publishing delta CRLs on offline root CAs. Because you do not revoke many certificates on an offline root CA, a delta CRL is probably not needed.

Adjust the default LDAP:/// and HTTP:// URL locations on the Extensions tab of the certification authority’s Properties Extension tab according to your needs.

Publish a CRL on an HTTP Internet or extranet location so that users and applications outside the organization can perform certificate validation. You can publish the LDAP and HTTP URLs for CDP locations to enable clients to retrieve CRL data with HTTP and LDAP.

Remember that Windows clients always retrieve the list of URLs in sequential order until a valid CRL is retrieved.

Use HTTP CDP locations to provide accessible CRL locations for clients running non-Windows operating systems.

For more information about CRLs and delta CRLs, see Configuring Certificate Revocation.

Windows PowerShell and certutil support variable numbers (preceded by a percent (%) sign) to help in publishing CDP and AIA locations. The CA’s Properties Extension tab supports bracketed variables. The following table equates the variables between the interfaces and describes their meanings.

Variable	Extensions tab name	Description
%1	The DNS name for the CA computer. If connected to a DNS domain, it is the fully qualified domain name; otherwise, it is the hostname of the computer.
%2	The NetBIOS name of the CA server
%3	The name of the CA
%4	This allows each additional revision of the certificate to have a unique suffix.
%4	None	Not used
%6	The location of the configuration container in Active Directory Domain Services (AD DS)
%7	The name of the CA truncated to 32 characters with a hash at the end
%8	This inserts a suffix on the file name when publishing a CRL to a file or URL location.
%9	When a delta CRL is published, this replaces the CRLNameSuffix variable with a separate suffix to distinguish the delta CRL from the CRL.
%10	The object class identifier for CRL distribution points, which is used when publishing to an LDAP URL.
%11	The object class identifier for a CA, which is used when publishing to an LDAP URL.

Publish the AIA extension

The AIA extension tells the client computers where they can find the certificate to be verified. This allows the client to confirm whether the certificate can be trusted.

You can configure the AIA extension by using the Certification Authority interface, Windows PowerShell, or the certutil command. The following table describes the options that you can use with the AIA extension by using these methods.

Interface check box name	Windows PowerShell parameter	Certutil value
Include in the AIA extension of issued certificate	-AddToCertificateAia	2
Include in the online certificate status protocol (OCSP) extension	-AddToCertificateOcsp	32

The examples in this section for publishing the AIA extension represent the following scenario:

The domain name is corp.contoso.com.

There is a web server named App1 in the domain.

App1 has a shared folder named PKI that allows the CA Read and Write permissions.

App1 has a DNS CNAME of www and a shared virtual directory named PKI.

The first protocol that client computers should use for the AIA information is HTTP.

The second protocol that client computers should use for the AIA information is LDAP.

The CA that is being configured is an online issuing CA.

OCSP is not in use.

Use the interface to publish the AIA extension

The interface uses the variables and check box names that are described in the previous tables. You can access the interface through the Certification Authority interface. From the contents pane, right-click the CA, click Properties, and then click Extensions. In Select extension, click Authority Information Access (AIA).

Figure 1 AIA extension menu

The locations and settings configured in the user interface are as follows:

C:\Windows\system32\CertSrv\CertEnroll\ _ .crt

• Include in the AIA extension of issued certificates

file://\\App1.corp.contoso.com\pki\ _ .crt

ldap:///CN= ,CN=AIA,CN=Public Key Services,CN=Services,

• Include in the AIA extension of issued certificates

Use Windows PowerShell to publish the AIA extension

The following Windows PowerShell commands can be used to configure the AIA extension for the given scenario:

Use certutil to publish the AIA extension

The following certutil command can be used to configure the AIA extension for the given scenario:

Publish the CDP extension

The CDP extension tells client computers where they can find the most recent CRL, so the client can confirm that a particular certificate has not been revoked.

You can configure the CDP extension by using the Certification Authority interface, Windows PowerShell, or the certutil command. The following table describes the options that you can use with the CDP extension by using these methods.

Interface check box name	Windows PowerShell parameter	Certutil value
Publish CRLs to this location	-PublishToServer	1
Include in all CRLs. (Specifies where to publish in Active Directory when publishing manually.)	-AddToCrlCdp	8
Include in CRLs. (Clients use this to find the delta CRL locations.)	-AddToFreshestCrl	4
Include in the CDP extension of issued certificates.	-AddToCertificateCdp	2
Publish Delta CRLs to this location.	-PublishDeltaToServer	64
Include in the IDP extension of issued CRLs.	-AddToCrlIdp	128

The Issuing Distribution Point (IDP) extension is used by non-Windows clients to verify certificate revocation. The IDP extension allows partitioned CRLs to be deployed when using third-party CAs. Partitioned CRLs allow a third-party CA to publish CRLs with only specific certificate types within each CRL. For example, you can have separate CRLs for end certificates versus CA certificates. Specifically, the following options can be set in the IDP:

If you are allowing delta CRL publishing to an Internet Information Services (IIS) web server, you must modify the default IIS configuration by setting allowDoubleEscaping=true of the requestFiltering element in the system.web section of the IIS configuration. For example, if you want to allow double escaping for the PKI virtual directory of the default Web site on IIS, run the following command on the IIS web server: appcmd set config «Default Web Site/pki» -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true . For more information, see AD CS: Web server should allow URI containing the “+” character to enable publishing of delta CRLs.

The examples in this section for publishing the CDP extension represent the following scenario:

The domain name is corp.contoso.com.

There is a web server named App1 in the domain.

App1 has a shared folder named PKI that allows the CA Read and Write permissions.

App1 has a DNS CNAME of www and a shared virtual directory named PKI.

The first protocol that client computers should use for the CDP information is HTTP.

The second protocol that client computers should use for the CDP information is LDAP.

The CA that is being configured is an online issuing CA.

IDP is not in use.

Use the interface to publish the CDP extension

The interface uses the variables and check box names that are described in the previous tables. You can access the interface through the Certification Authority interface. From the contents pane, right-click the CA, click Properties, and then click Extensions. In Select extension, click CRL Distribution Point (CDP).

Figure 2 CDP extension menu

The locations and settings configured in the interface are as follows:

Publish CRLs to this location

Publish delta CRLs to this location

Include in CRLs. Clients use this to find delta CRL locations.

Include in the CDP extension of issued certificates

Publish CRLs to this location

Publish Delta CRLs to this location

ldap:///CN= ,CN= ,CN=CDP,CN=Public Key Services,CN=Services,

Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually.

Include in the CDP extension of certificates

Use Windows PowerShell to publish the CDP extension

The following Windows PowerShell commands are used to configure the CDP extension for the given scenario:

If you use Windows PowerShell to add CDP paths, existing paths remain in place. The first Windows PowerShell command in the example removes all the existing paths. For more information about using Windows PowerShell to remove CDP paths, see Remove-CACrlDistributionPoint.

Use certutil to publish the CDP extension

The following certutil command configures the CDP extension for the given scenario:

To publish the CRL, you can run the command certutil -crl on the CA from Windows PowerShell or a command prompt run as administrator. For more information about CRL configuration and publishing, see Configuring Certificate Revocation.

Verify the configuration

To verify the CA configuration, you can run the following commands from Windows PowerShell or a from a Command Prompt window:

Command	Description
Certutil -CAInfo	Shows the status of the names, locale, object identifiers (OIDs), and CRLs for the CA.
Certutil -getreg	Displays the CA registry configuration.
Certutil -ADCA	Confirms the configuration of enterprise CAs.

You can use the Enterprise PKI View (PKIView.msc) tool to check your AIA and CDP publication configurations. For more information, see the Enterprise PKI.

You can also use the Online Responder role service to check certificate revocation. For more information about Online Responder, see Online Responder Installation, Configuration, and Troubleshooting Guide.