Freigeben über

ADCS: Manually Created CDP Extensions Cause CRL Look-up Failures

  • Artikel

Summary: Gregg O’Brien , a Microsoft Premier Field Engineer from Canada, makes a case for not throwing sand in your face and correct zipper placement when dealing with a Certificate Revocation List Distribution Point (CDP) in Microsoft Active Directory Certificate Services. The moral of his story: make sure your CDPs are properly formatted or you’ll see some strange results. Enjoy!

zipperAs children, we learned a lot by doing things the wrong way.  For example, as a toddler playing in a sandbox, many of us soon learned that throwing sand up in the air and then looking skyward was the wrong way to play with sand.  Particularly if we wanted a day free of eye pain.  As we got older, many of us would have discovered that when we put pants on and found the zipper is in the back, we put the pants on the wrong way.  As obvious as these things are for us now (hopefully, at least), there are some things that may be incorrectly done, but are not at all obvious. Such can be the case with the configuration of CDP extensions in Microsoft Active Directory Certificate Services (ADCS) .

In ADCS, and Public Key Infrastructure (PKI) environments in general, a Certificate Revocation List (CRL) and the corresponding CRL Distribution Point (CDP) are key components of a functioning infrastructure. If these are configured incorrectly, certificates issued will be unusable by endpoints or exposed to security risks. If you are unfamiliar with CRLs and CDPs, you can find out more information by reviewing How Certificate Revocation Works.

The main idea is that clients need to be able to check to see if a certificate has been revoked by an Administrator or not.  If a certificate has been revoked, clients should reject it.  Clients verify the status of a certificate by looking for the certificate in the CRL.  If found, that means the certificate is no longer trustworthy. The CRL will be hosted in a location known as a CDP.  When a client connects to a server, such as a browser connecting to a secure website, it is presented with a certificate from the server.  The certificate will contain a series of parameters known as extensions.  If the extensions for the CDP are configured incorrectly or not configured at all, the client will not be able to verify the status of the certificate.

So, let’s get down to business. One of the things I recently came across and have come to learn is a common problem is with the actual process with which the CDP is configured. When we look at the properties of a certificate we can see the paths to the CRL, like this:

look at the properties of a certificate

Looks like the CRL can be found at both https://crl01.website.net/crl/caserver2.crl and at https://crl02.website.net/crl/caserver2.crl.

Now, when we look at the configuration of the associated Certificate Authority, we see something like this:
the configuration of the associated Certificate Authority

Notice the series of parameters such as <CaName> and <CRLNameSuffix> and not https://crl01.website.net/crl/caserver2.crl. This is the correct way to create the extension that points to the location of the CDP.  If we were to simply hit add and type in: https://crl02.website.net/crl/caserver2.crl for example, we would be committing the equivalent of throwing sand in the air and looking up. This. Will. Cause. Us. Pain.  Though it may not be obvious, the formatting of the CDP such as https://crl01.website.net/CRL/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl is translated by the Certificate Authority to https://crl01.website.net/crl/caserver2.crl at the time of the creation of the certificate.  Manually specifying the CDP location causes the lookups to fail.  Not all applications will complain about this.  Some will work just fine actually.  Other applications and services, such as IPsec, UAG, DirectAccess, will reject any certificates referencing the incorrectly formatted CDP location.

The takeaway here: always ensure that your CDP locations are formatted with the convention:

https://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

If the CDP is correctly formatted, you should not experience any issues with CRL lookups regardless of which application or service you are using.

That’s it for today.  Until next time, keep your zippers in the front!

 

Written by Gregg O’Brien; Posted by Frank Battiston, MSPFE Editor

Comments

  • Anonymous
    April 26, 2013
    yay Gregg you did it a fine blog