Update 06.04.2020: clarified the last section by mentioning that everything expressed in this blog post is primary opinion-based.

Information in this article should be used only when you plan ADCS installation.

Hello Internet!

Today I’m going to describe one of the ugliest and, on the other hand, one of the most important topic in PKI — chain building and revocation checking and how to design/plan them by conforming best practices.

Motivation

Certificate chaining engine and revocation checking are PKI fundamentals and your PKI success depends on how well you understand this subject and how well it is implemented in your environment. When it is implemented incorrectly, then you are a candidate for another topic starter on TechNet forums, because certain applications stop working as expected: you cannot log on to domain by using smart card, you cannot connect to remote site over VPN, OpsMgr/SCCM cannot contact managed clients and so on. In worst cases you cannot start your CA server. Actually, revocation checking topic is the hottest topic on TechNet Security forum and, apparently, it is hotter than Tera Patrick herself.

Before you start

A time ago I posted an article on TechNet Wiki that describes certificate chaining engine fundamentals: Certificate Chaining Engine (CCE). I strongly recommend to read it to get a better understanding about how it works. The rest post will be based on this article.

Getting started

If you are familiar with how CCE works, we can identify tasks we need to solve:

1. Determine the URL type (http or LDAP) and scope (internal or internal + external);
2. Provide a target URL;
3. Configure CA server.

URL type and scope

At first we need to determine what kind of URL and how many URLs we need? By default, Windows CA use two URLs that use different access protocols (both for CDP and AIA extensions): LDAP and HTTP. For example, default URLs for default CA installations are:

• CRL Distribution Points (CDP):

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=ldap:///CN=Contoso%20CA,CN=DC1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,
                     DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
               URL=http://dc1.contoso.com/CertEnroll/Contoso%20CA.crl

• Authority Information Access (AIA):

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=ldap:///CN=Contoso%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,
                DC=contoso,DC=com?cACertificate?base?objectClass=certificationAuthority
[2]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://dc1.contoso.com/CertEnroll/DC1.contoso.com_Contoso%20CA.crt

URL order is important. CryptoAPI client always attempts the first URL in the list to retrieve the file. Second URL will be checked only when first URL times-out (15 seconds time-out). Therefore, to avoid possible revocation checking delays the most accessible URL must be placed first!

While 10 years ago it was enough for most installations, it is not very practical nowadays. LDAP protocol mainly can be accessed only by Active Directory forest members. If you have clients outside of your domain or when users cannot reach domain controller (when employee attempts to establish a VPN to corporate network from internet), then LDAP URL is not their best option and you should use HTTP protocol as it is supported by any kind of clients (even non-Windows).

Another benefit when using HTTP transport is a support for E-tag and Max-Age HTTP headers, which are not available for LDAP. E-tag header greatly improves revocation checking experience, especially for long-living CRLs (several months). Offline root CAs usually issue CRLs which are valid for 6-12 months and these CRLs are usually cached on clients until CRL expires. If subordinate CA is revoked, client's won't be notified about revocation for a long time, because they use cached CRL which is still valid. With E-tag clients can periodically query CRL distribution point for CRL update (by passing E-tag value in the request). If HTTP server responds with the same E-tag value, then CRL is unchanged and client still can use cached CRL. If E-tag in the response doesn't match the one in the request, then CRL was updated on a server and client initiates CRL download and local cache update even though cached CRL is still valid. E-tag check period is determined by Max-Age header. Default value for IIS web server is 1 week. When using LDAP, these features are not available and clients will still sit uninformed about revocation until cached CRL expires. More details on CryptoAPI support for HTTP headers: Using ETags and Max-age in a Request.

In the URL samples I displayed that two URLs are used for each extension (CDP and AIA) for redundancy. Say, if client is inside the domain network, it uses first URL. When it is outside of the domain network, the first URL obviously fails and CryptoAPI checks second URL. In this case clients outside of your domain network will experience long delays during revocation checking (15-20 seconds) for each URL. Entire chain building and revocation checking may take about 1 minute or so.

As a general practice, it is recommended to not use LDAP URLs at all and use only HTTP URLs, even if your clients are exclusively internal domain members).

file:// protocol is no longer supported for file retrieval (when published in the extension).

This design simplifies URL management and guarantees that all clients will be able to download the file. It is ok to have a single URL in the CDP and AIA extensions. Of course, you should (at least, it is recommended) to provide sort of high availability by using external means. For example, publish CRL/CRT files on NLB cluster. Also, CA server SHOULD NOT act as a web server to serve CRL/CRT files. There should be a separate web server.

OCSP

OCSP (Online Certificate Status Protocol) — is a lightweight revocation checking protocol which runs over HTTP transport. The idea is that instead of downloading whole (probably large) CRL file for single certificate checking, it is reasonable to query web service for particular certificate revocation status. While CRL download size is variable and depends on a number of revoked certificates, OCSP request/response transaction size is constant value ~2.5kb. OCSP caching mechanism is the same as with CRL. Each OCSP response is cached for a period time specified in the OCSP response.

Another good feature in OCSP is OCSP Stapling. Certificate owners (for example, IIS web server) can get signed OCSP response for its own certificate and pass this OCSP request to web clients along with TLS certificate during TLS handshake negotiation. Client is no longer required to query OCSP or download CRL to verify TLS certificate revocation status. Client safely uses stapled OCSP response sent by server. Since OCSP response is digitally signed by OCSP server, there is no way for certificate owner (web server) to tamper or otherwise manipulate the OCSP response.

There is, though, one downside with OCSP: bulk client certificate validation. For example, smart card authentication, 802.1X wireless authencation certificates. With OCSP, RADIUS servers (or domain controllers) will be forced to query the same OCSP server when validating each client certificate. As the result, OCSP traffic may exceed CRL size and it would be reasonable to get single CRL, cache it, and use for every client certificate validation. Microsoft CryptoAPI handles such cases as follows: after sending 50 OCSP requests to the same OCSP responder and same issuer, CryptoAPI client stops OCSP query and downloads CRL if possible (by using URLs specified in the CDP extension of client certificates). More on this behavior: Determining Preference between OCSP and CRLs.

Another point to consider is the use of OCSP servers for each CA type. OCSP is recommended for CAs that issue certificates to end clients (users, computers, services) and where revocation intensity is relatively high. OCSP doesn't bring any benefit to CAs that issue certificates only to other CAs. For example, root CAs usually issue certificates only to intermediate CAs only. In this case, revocation is extremely rare and CRL size will be less than OCSP request/transaction traffic. Typical CRL size with no revocation records is ~500-800 bytes only. As a general practice, consider to use OCSP only for issuing CAs only.

URL form

In the previous paragraph we identified that we will need a single URL for each, CDP and AIA extensions and URL will use HTTP scheme.

NEVER use HTTPS protocol for CRT/CRL file retrieval, because CryptoAPI will permanently fail to fetch this URL.

Now, we need to design a URL form. This means that we need to design the name for CRT/CRL file, virtual directory (if necessary), separate host (if necessary). There is no significant recommendations, except that file name should be simple and do not contains spaces and/or special characters. Here are several examples of good URLs for “Contoso CA” root CA server:

1. http://www.contoso.com/pki/contoso-RCA.crl
   http://www.contoso.com/pki/contoso-RCA.crt
2. http://www.contoso.com/crl/contoso_RCA.crl
   http://www.contoso.com/cert/contoso_RCA.crt
3. http://pki.contoso.com/contoso-RCA.crl
   http://pki.contoso.com/contoso-RCA.crt
4. http://pki.contoso.com/crl/contoso-RCA.crl
   http://pki.contoso.com/cert/contoso-RCA.crt

First example illustrates when both CRL and CRT files are stored in the same virtual directory, while the second example illustrates a separate virtual directories. You can see that files in first two examples are served by a (most likely) Contoso’s front web site.

Third example illustrates when CA files are served by a dedicated web site without any virtual directory. And the last example illustrates combination of 2nd and 3rd example. You may choose any, or your own, depending on internal practices.

Configure CA server

We are almost done. Now we need to configure CA and web servers. The following step-by-step scheme will be used:

1. CA server generates CRLs and CRT files;
2. CA server publishes these files to a remote share (share on web server or DFS share, doesn’t matter which one);
3. Web server picks these files from local or remote share;
4. Web server transfers these files when requested.

Configuring permissions

Step 2 requires additional permission configuration. If CA and remote share are located in the same domain, then you need to configure permissions on remote share as follows:

• Share permissions: grant Allow Full Control to “Cert Publishers” predefined domain-local group;
• NTFS permissions: grant Allow Full Control to “Cert Publishers” predefined domain-local group.

if remote share is located in different domain:

1. in target (where resides remote share) domain add CA server computer accounts (all CAs) to a respective domain “Cert Publishers” predefined domain-local group.
2. Configure permissions on the share as follows:
3. Share permissions: grant Allow Full Control to “Cert Publishers” predefined domain-local group;
4. NTFS permissions: grant Allow Full Control to “Cert Publishers” predefined domain-local group.

These steps are necessary to allow CA service (which runs under Local System account) to publish files to remote share.

Configuring CRL Distribution Points extension

Now, we can configure CDP and AIA extensions on CA server. To do this, open Certification Authority MMC snap-in. In the opened snap-in, select CA node, right-click and switch to Extensions tab:

In the picture you see default CDP locations. Just remove ldap, http and file locations. We will configure CA to use the following URL in issued certificates: http://www.contoso.com/pki/contoso-RCA.crl. You will need to remove all entries, except first one. You should not remove it, because it is internally used by Certification Authority MMC snap-in. After that add the following entries:

• \\ServerName\RemoteShare\contoso-RCA<CRLNameSuffix><DeltaCRLAllowed>.crl. Enable “Publish CRLs to this location” and, optionally, “Publish Delta CRLs to this location” (if you plan to use Delta CRLs) checkboxes.
• http://www.contoso.com/pki/contoso-RCA<CRLNameSuffix><DeltaCRLAllowed>.crl. Enable “Include in CDP extension of issued certificates” and, optionally, “Include in CRLs. Clients use this to find Delta CRL locations” (if you plan to use Delta CRLs) checkboxes.

First entry specifies the location to which actual files should be published. Replace “ServerName” and “RemoteShare” with actual values. Also, you will need to change CRL file name. The only part that remains unchanged is: <CRLNameSuffix><DeltaCRLAllowed>. These special variables are necessary to support multiple CA certificates and Delta CRLs. For more details read the following article: Root CA certificate renewal.

Second URL will be published in issued certificates. CRL file name and special variables MUST match in both URLs.

Configuring Authority Information Access extension

When finished, apply changes and switch to Authority Information Access (AIA) extension. Here are default AIA URLs:

Again, we see 4 URLs. You should leave first location (which points to local file system) and remove the rest locations. We will configure CA to use the following URL in issued certificates: http://www.contoso.com/pki/contoso-RCA.crt. Unfortunately, Windows CA do not support custom CA certificate publication locations, you will have to rename and copy the file to remote share manually. Therefore you will need to add only one location:

1. http://www.contoso.com/pki/contoso-RCA<CertificateName>.crt. Enable “Include in the AIA extension of issued certificates” checkbox. You plan to use OCSP, then add another location that points to a OCSP server and enable only “Include in the online certificate status protocol (OCSP) extension” checkbox.

The purpose of the special <CertificateName> variable is described in the Root CA certificate renewal article. Apply changes and restart CA service when prompted.

Verify settings

If you feel that everything is configured properly, then you should verify new configuration To verify it, run pkiview.msc MMC snap-in. This console allows you to check CDP/AIA URL availability and whether the published files are correct. Here are 2 screenshots from my test lab (2-tier hierarchy):

This screenshot from root CA. As you see, it’s version is V1.0 which indicates that CA certificate was renewed once with the same key pair. And you see <CertificateName> variable in action: it adds a certificate index in parentheses — (1).

And here is another screenshot from subordinate CA:

Subordinate CA version is V2.2 which indicates that CA certificate was renewed twice and last time it was renewed with new key pair. In this example you see the following variables in action: <CertificateName> variable in CRT file and <CRLNameSuffix><DeltaCRLAllowed>. <CRLNameSuffix> adds key index in parentheses (2) and <DeltaCRLAllowed> adds a plus “+” sign at the end of file to indicate that the file is Delta CRL. If all locations report “Ok” status, then the configuration is ok, otherwise something went wrong and you should fix it *before* you start use CA server.

If something went wrong and you fixed it, you may need to revoke the latest certificate based on “CA Exchange” template and re-run the console. Pkiview.msc relies on CA Exchange certificate to collect configured CRL/CRT URLs.

Everything in this article is based on my own opinion, experience in PKI field, best practices (as I see them) which may or may not conform Microsoft recommendations. If you want to dig deeper, then you should check the following whitepapers:

• Certificate Status and Revocation Checking
• Certificate Revocation Checking in Windows Vista and Windows Server 2008