On the usefulness of CRLs for client side certificates

A certificate revocation list is a collection of certificates that can’t be trusted anymore. The reasons of mistrust can be many:-

  • A suspicious activity by the certificate holder
  • A compromise of clients private key that tricks the system in believing the impostor as the real certificate holder.
  • A compromise of the CA’s private key that allows the attacker to maliciously sign client certificates to gain access to protected systems.

When we talk about client side certificates, we are not dealing with just a single certificate, but with a much larger volume of certificates that complicates their management. Automatic checks like email verification only guarantee that a certain email belongs to a certificate holder and not much else. Therefore when we talk about valid certificate what we mean is, that the certificate being presented to us is signed by a trusted CA. No more, no less. Once a connection has been established by a valid certificate we still need to authorize the actions of a certificate holder. Not all certificate holders should be able to perform all actions on our server.

A certificate itself provides very little information to us. For that purpose we need to map some attributes of a client certificate to our user table. That attribute could be a DN or a serial number. In doing that we are saying that a certificate with an attribute X belongs to a user Y. It should be the responsibility of the certificate issuer to make sure the the attribute that is being mapped is unique across the certificates.

A CRL invalidates a certificate during the establishment of a connection. But this presents some inconsistencies in our application design since even with a CRL it is important to define what actions are allowed for a user passing the CRL check. A rejection at the level of access control is much more manageable/intuitive than a rejection at CRL level.

Keep a clean nose

If a certificate holder is doing a suspicious activity with a valid certificate then revoking the certificate is an incorrect response because the certificate is genuine. Instead steps should be taken to either warn the user or ban him from performing certain actions within the application.

If the private key of the user has been stolen and the certificate issued has been compromised then the certificate serial number (or other attribute) can be unmapped from the user table and a notification can be issued to user to get a new certificate. Meanwhile all requests from the old certificate can be responded with a succinct 401.

If the CA’s private key has been compromised then rather than invalidating all the client certificates it would be best to create a new CA and issue new certificates to your clients. A CRL does not make any sense here because all the certificates have been compromised.

“What about speed?”

A CRL is certainly faster since it rejects the user when he’s about to establish the connection but if you take into account that a series of checks will have to be performed after establishment of the connection the equation changes somewhat. Add to this the inconvenience of maintaining two different levels of access control and consequently dealing with two data points when it comes to determine the validity of user, it becomes simpler and efficient to not keep a crl even at the cost of a tiny gain in performance.



  • On February 15, 2018