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:

Default CDP

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:

Default AIA

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):

image

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:

image

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 best practices and fully conforms all Microsoft recommendations. If you want to dig deeper, then you should check the following whitepapers:


Share this article:

Comments:

Jason Jones
Jason Jones 16.08.2013 21:29 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Hey Vadims, Great article and exactly how I design these ADCS elements for a modern PKI deployment! It encapsulates the key design features really well - thanks! Cheers JJ

Vadims Podans
Vadims Podans 16.08.2013 22:57 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Thanks! It is one of the less described topic about PKI fundamentals in the internet. Hope to see less questions about "Revocation server offline" issues :)

Taavi
Taavi 27.09.2013 18:51 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Best article I have found. Just the topic I was looking for! Thank you and keep on going! :)

Marcel
Marcel 24.10.2014 18:32 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Read many blogs and articles about this stuff, but this one is by far the best. All those silly URL's with spaces, which are used by other people, it in't necessary at all! Still doubting if I shouldn't add the LDAP path anyway. Most of our clients are member of the AD.

Vadims Podans
Vadims Podans 24.10.2014 22:10 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

> Most of our clients are member of the AD. Eventually we decided to completely move from LDAP regardless of whether certificate clients are domain members or not.

Xeiran
Xeiran 18.11.2016 03:42 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

The more I read, the more it appears that end clients are even more sensitive to CRL distribution point failure than they are to CA failure.  Yet no-one seems to have published a best practices regarding highly available CRL / AIA distribution points (or HA OCSP, or HA SCEP, or HA web enrollment).  If you place the CRL distro point on a web farm using NLB (that is separate from the CA servers), do you create and set up scheduled scripts to regularly copy the CRL and CRT files to each node's storage, since storage is not typically shared in an NLB situation?  If I have a separate PKI infrastructure for ECDSA vs RSA, can I share the same website URL for both CRL distro points, or is it better to have separate ones?  Going beyond just CRL point (and beyond the original scope of this article), what about Web Enrollment services, can those be put on an NLB webfarm?  Can that one webfarm do web enrollment for both RSA and ECDSA?

Xeiran
Xeiran 18.11.2016 04:59 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Answered the web enrollment part of my own question:  https://blogs.technet.microsoft.com/askds/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy/

Julien
Julien 22.11.2017 16:01 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Great article !

phatmandrake
phatmandrake 26.02.2018 18:26 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

I wish I found this a while ago. It answers several "But why..." questions that I wanted confirmation of.

Kudos.

Ben
Ben 18.04.2018 12:43 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Hello,

Thanks, great article :)

I don't understand why ldap url is removed from AIA and CDP's locations. If a client is outside the organisation (as you say in a vpn access case) or non-domain joined, i understand why HTTP location is necessary. But for domain-joined client / internal client, is LDAP URL not better ?
 

Vadims Podāns
Vadims Podāns 21.04.2018 21:23 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

> But for domain-joined client / internal client, is LDAP URL not better ?

not better. At first, you will have to use separate CAs for internal and external clients. It can cost. Another point is that LDAP doesn't support improved revocation experience via caching control and E-tag HTTP headers. Really, there is no real need to bother with LDAP at all.

Dustin
Dustin 02.06.2018 19:04 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Very confused on this-

"Also, you will need to change CRL file name."

1. Why?  Can't this be created correctly in initial configuration?

2. Where do you change this?

I'm assuming the C:\Windows\System32\CertSrv\CertEnroll

If you change it elswhere and it's a different name then what's stored on the server, isn't that a security issue?

 

Vadims Podāns
Vadims Podāns 02.06.2018 20:39 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

> 1. Why?  Can't this be created correctly in initial configuration?

no, you cannot configure CDP/AIA during installation, you have to change it after CA installation.

> If you change it elswhere and it's a different name then what's stored on the server, isn't that a security issue?

no, it is not a security issue. Because if you get access to this file on the server, it doesn't reveal anything useful to attackers.

pd
pd 19.07.2018 23:56 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Just a quick question. I am new to this and have been following articles to have this set up.we have CBA configured for o365 access control and there is a requirement to have the CRL and AIA accessible over the internet... We have the CRl and AIA published over the internet. Although the CRl does not contain any private information, the AIA contains the certs from the CAs, is this a security risk of any sort?

 

Vadims Podāns
Vadims Podāns 20.07.2018 09:05 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

> Although the CRl does not contain any private information, the AIA contains the certs from the CAs, is this a security risk of any sort?

No, there are no risks. Public certificates are meant to be public.

Hisham
Hisham 15.08.2018 09:40 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Hi,

Thank you for the article. I have a quick question that is really bothering me. If I want to configure a highly available HTTP CRL DP, I configured two Web (IIS) servers as required and then I can use DNS Round Robin or NLB between them. The thing that I cannot get my head around is:

On Server1, the HTTP CDP could look something like: http://www.contoso.com/pki/contoso-RCA1.crl

On Server2, the HTTP CDP could look something like: http://www.contoso.com/pki/contoso-RCA2.crl

If I add the two HTTP URLs to the CDPs of Server1 and Server2, would that work? Because I understand that clients only check the first entry of each type i.e. the first LDAP and then the first HTTP. Hence, it will ignore the second one, isn't that right?

If I use DNS RoundRobin, for example, having two "www" A records, one pointing at Server1 and one at Server2. In that case, which URL will I add to the CDP list? The first one or the second one? If I add the first one but the CRL file name on the second one, contoso-RCA2.crl, is different then that would give an error if a user hits the second server.

I am missing something quite trivial probably, right?

Would really appreciate the help.

Best regards!

Vadims Podāns
Vadims Podāns 15.08.2018 11:59 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

> On Server1, the HTTP CDP could look something like: http://www.contoso.com/pki/contoso-RCA1.crl
> On Server2, the HTTP CDP could look something like: http://www.contoso.com/pki/contoso-RCA2.crl>

It is not quite correct. When we talk about HA, the URL to a resource is unified. Client has only single URL and depending on DNS/Load balancer it is pointed to the right server. That is, in a given case you put only one CDP URL: http://www.contoso.com/pki/contoso-RCA1.crl and this exact file (contoso-rca1.crl) file must be available on each web server. It is out-of-band process how you deliver the file there, make a copy on each server, or have DFS share (and both servers point to that share), or another solution.

Hisham
Hisham 15.08.2018 17:24 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Thank you for that. Probably, I should have mentioned that we have 2 subordinate CAs so that's why each one of them generates a different CRL. How do manage that? If CA1 issues a certificate with CRL1 as the CDP, hence the HTTP CDP looking like this: htttp://www.contoso.com/pki/contoso-CA1.crl

But then if we have DNS Round Robin, 2 x www records, each pointing at one of the CDP and if DNS redirects the user checking for revocation to the second path which doesn't have the contoso-CA1.crl published, that woudl cause an issue, wouldn't it?

In other words, should we add the two different HTTP CDPs to each Sub CA?

Would really appreciate your help.

Vadims Podāns
Vadims Podāns 15.08.2018 18:17 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

> In other words, should we add the two different HTTP CDPs to each Sub CA?

nope, again. If you have two CAs, then, first CA (say, SubCA1) includes the following URL in CDP: http://www.contoso.com/pki/contoso-subca1.crl

You configure both web servers to serve "contoso-subca1.crl" file. Second CA (say, SubCA2) includes the following URL in CDP: http://www.contoso.com/pki/contoso-subca2.crl and configure web servers to serve that file too. Eventually, physical folder (mounted as pki virtual directory in IIS) will serve two CRL files from both CAs and both web servers will have identical configuration in respect to PKI web site. It really doesn't matter how many CAs you have as long as they share the same web site configuration to serve clients.

Hisham
Hisham 15.08.2018 19:49 (GMT+2) Designing CRL Distribution Points and Authority Information Access locations

Great, thank you so much. Much appreciated!


Post your comment:

Please, solve this little equation and enter result below. Captcha