But I’m an MCSE. This should just work right…

Yet another Configuration Manager deployment that required more time remediating the Public Key Infrastucture (PKI) then it did to deploy the entire hierarchy. Based on that, I wanted to write this article.

Nearly all the PKI issues I see are all a bi-product of a “next-next-next” deployment. It amazes me that people will spend months planning a SQL deployment but not give a critical infrastructure component like Certificate Services more than 5 minutes of their time. Anyway, I digress 🙂

Lets start right at the beginning and explain how Certificate Revocation works:-

1) Computer A needs to talk to Server B using a certificate verified or encrypted connection

2) Server B presents his public certificate to Computer A.

3) Computer A looks at the CRL Distribution Point (CDP) extension of Server B’s certificate and downloads and interogates the *.crl file specified in the CDP


4) If Server B’s certificate has not been revoked, is still valid and matches the target address used by Client A to talk to Server B (So either ServerB.domain.local or Application.domain.local) the session continues.


5) Depending on whether client certificates are required, Server B may repeat steps 2,3,4 for Client A’s certificate. Configuration Manager does this for example.

By default, all Microsoft Certificate Authorities (CAs) will deploy a host of CRL publishing and CDP locations by default. These work right out the box but only when your clients are operating in the following environment:-

default cdps

– LDAP publishing – Clients are Windows and domain members

– HTTP publishing – you have chosen to deploy the certificate web services and your clients can contact the CA based on its original hostname and, more thank likely, by querying the Active Directory DNS zone (A record registered).

Where this all falls apart is in the following situations:-

– Non-domain members who can not read LDAP such as Windows workgroup systems which require certificate validation the most!

– Non-Windows clients who will never read LDAP such as Linux, Unix, IOS, Android, the kettle, the fridge, etc.

– Internet clients who can not (and shouldn’t) query your internal AD zones and who can not query LDAP.

– CA has been migrated to another host and breaks the default HTTP CDP stamped on all existing certificates. You now need to fudge DNS 😉

This brings me to the most important part of this post:

Once you begin issuing certificates you can not alter the CDP’s without reissuing the certificates.

And so finally here here are my recommendations for all PKI planners no matter what the platform!

1) Only ever use a HTTP CDP. Forget about all the others!

2) Always use a DNS alias for your HTTP CDP. As I personally struggle to be creative when allocating names so something like pki.internaldns.local and pki.natmeoutside.com should cover all bases.

3) You are allowed to call your CRL anything you like. You are not forced to call it “ServerB_IssuingCA_v43_ServerB.internaldns.local_BLABLABLA.crl”. Something like “RootCA.crl” or “revoke.crl” is perfectly acceptable.

4) Please do not make your CDP (I will do a step by step for you below) an SSL (HTTPS) website. If the website certificate expires or is revoked nobody can access your HTTPS CDP (yes I have seen this more than once!). Stick to HTTP. Crl’s are public knowledge and that is the entire point.

If you stick to these simple rules you will have a CDP that is available to ALL clients, easy to migrate and easy to expand (say behind load balancers) later.

Here are some steps for deploying a HTTP CDP on Server 2012 R2:-

Note: I assume you have already installed a PKI which I will cover in a later post.

Note: I have assumed you have already made your DNS alias. In this example that is pki.lab.local rather than dom-1.lab.local

1) Open an elevated powershell window and install the basic IIS role

install-windowsfeature Web-Server


2) Make a directory which will host your certificate revocation list (CRL) files

Note: This will become your website root so remember the path!

MD C:\Inetpub\wwwroot\PKI

3) Open the Certificate Authority (CA) MMC and open the properties for the CA. Move to the extensions tab. Select the CDP extension. Add an entry for the CRL publishing path.

Note: The CRL publishing path is where the CRL files are created and should match the path shown above.

Note: If you plan on publishing delta CRLs do not forget to add the <DeltaCRLAllowed> variable in your name. For example: C:\PKI\revoke<DeltaCRLAllowed>.crl

Note: Do not forget to end your file name with .crl


4) Open the Certificate Authority (CA) MMC and open the properties for the CA. Move to the extensions tab. Select the CDP extension. Add an entry for the CDP Extension.

Note: The web address must start http://<Your DNS Alias such as pki.lab.local>/

Note: Your entry should end with the exact same name and format you chose for the CRL name above. http://<Your DNS Alias such as pki.lab.local>/revoke<DeltaCRLAllowed>.crl

Note: Do not forget to tick the box to include this CDP in issued certificates and if you are going to use delta CRLs as per this example then tick the box Include in CRLs. Clients use this to find delta CRLs


5) You will be asked to restart the CA. Do this now.

6) Right click the Revoked Certificates node in the CA MMC and publish a new Full and Delta CRL.

Note: Delta CRLs will be greyed out if you are not using them

Note: You should now make sure you are left with CRL files in the folder and publishing entry you setup in steps 2 and 3 above.

publish crl crls

7) Open Internet Information Services MMC on the CA and create a new website for your HTTP CDP using the DNS alias and using the folder tested above.


8) In order to handle the + character in the delta CRL files allow double escaping. To do this open the Request Filtering feature. Edit the feature settings and select the option to allow double escaping.

doubleescaping doubleescaping2

9) From here you can now test the URL which you setup in step 4. Perform two tests firstly for the full CRL which will be something like revoke.crl and then for the delta CRL which will be something like revoke+.crl.

cdp.test.1 cdp.test.2

10) Now you are safe to issue your first certificate and not have to worry about the client type or environment it will be used within.

I thank you for stopping by and I hope you have found this useful.