Designing CRL Distribution Points and Authority Information Access locations

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

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.

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:

Comments:

Jason Jones
Jason Jones 16.08.2013 21:29 (GMT+2)

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)

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)

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)

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)

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

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)

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)

Great article !

Captcha