I’ve often noticed that it can be difficult to find information in one place around PKI solutions and what makes them secure.
That’s why I’ve decided to create a PKI resource myself! This ongoing series outlines the elements that make up a secure PKI solution – and I’m ending with CRLs!
CRLs and OCSP for Active Directory Certificate Services
The Certificate Revocation List (CRL) is a list of Certificates that have not expired, but have been revoked, where clients and services can verify presented or held certificates. This exists within the Certificate Distribution Point (CDP) and provides the ability for the organisation to revoke previously issued certificates for resources that no longer exist, or no longer have authority within the business to function, since they were issued. This could be websites, users and computers and ideally, these should both reside internally for internal network services and clients and externally where required, for example for AOVPN clients that are outside the internal network before initiating the VPN tunnel.
As with most technologies there are a number of different methods in terms of protocols to provision this element of PKI with advantages and disadvantages to each method.
LDAP is configured by default and is the least secure, as unencrypted LDAP traffic is communicated in plain text, so is a vulnerability by design. Easy to configure, yes, but has other limitations as a domain account is required to authenticate to it, so you are not able to configure anonymous access to accommodate your non-domain servers and third-party services that require access to its services. One advantage though, is that LDAP gives the ability to failover as based within Active Directory but configuring the CRLs in a load-balanced fashion can achieve the same redundancy.
A much better option is to use HTTP which allows anonymous access by simple creation of a shared location on the web server, which is defined within the CA configuration as a CRL endpoint. This method can be used for both internal and external CRLs, though getting CRL information to external HTTP CRLs will involve transportation over FTP or copies over the CRL from internal CRL points. Another way to achieve this external CRL without exposing services directly to the internet is to employ a reverse proxy – the Azure Application Proxy is a robust, cost effective and easy-to-deploy solution to facilitate this.
Additionally, if the same structure for internal and external CAs is used, LDAP can disclose AD Forest information from its name to external whilst an HTTP CRL does not.
Online Certificate Online Responder (OCSP) is a robust efficient solution for the Internal CRLs because instead of the client having to download the entire CRL list, it sends a single request to the OCSP Responder point which verifies the certificates validity. This means a lot less processing time for the client, especially in scenarios such as Smart Cards used by many NHS and other bodies. Another tick in the box for OCSP is that CRLs tend to get cached by network devices and so don’t refresh as quickly as expected sometimes, but OCSP answers the revocation requests immediately.
While it is possible to host these components on the CA server itself, it should (as per best practice) be hosted on separate and ideally dedicated servers for role separation, security and maintenance.
Having a CRL or OCSP revocation list available is actually a requirement set out by NCSC regulations, so if you need to comply or simply wish to configure your PKI to a recognised level of security, especially if you employ VPN services, then this configuration is imperative.
If you want to find out more about CRLs and OCSPs, there is an excellent article from Microsoft here.
Rest of the Series
If you have any questions on what I’ve discussed here or security in general, feel free to email in on firstname.lastname@example.org and I’ll be happy to answer any queries you have.