To Revoke or Not to Revoke

As a PKI engineer, I have consistently faced the challenges associated with certificate revocation. In several positions, I’ve been tasked with implementing automation to perform certificate revocation in bulk. Although I appreciated a task that showcased my coding skills, I often argued against such processes. I believe that many organizations misunderstand certificate revocation and how it is meant to be leveraged as a security control.

The fundamental question is: When should we revoke a certificate? Many cybersecurity generalists think, “When we separate a worker, we deactivate their login and remove all their rights to other digital resources, so why wouldn’t we also revoke their certificates?” At first glance, this seems logical. However, since you’re reading this blog post, you understand the issue is not so straightforward.

What exactly is certificate revocation, and what does it accomplish in the moment?

When a certificate is revoked, its serial number—the unique identifier of that certificate in the context of its issuing Certification Authority (CA)—is added to the Certificate Revocation List (CRL). The CRL is a digitally signed “press release” routinely issued by the CA to inform reliant parties of certificates it has issued that should no longer be trusted. Until a revoked certificate expires, its serial number must remain on the CRL. 

It’s important to bear in mind that three critical steps must be performed before a certificate is recognized as revoked by reliant parties: 

1. The certificate must be flagged as revoked in the certificate database on the CA.
2. The CA must digitally sign and issue a new CRL.
3. That CRL must overwrite older copies existing at the CRL distribution point(s).

Even if all three steps are performed, be advised that reliant parties typically maintain a local, cached copy of the CRL to reduce network traffic. These clients will continue to refer to their cached copy of the CRL until the time indicated in the “Next Publish” (when a new CRL can be expected to be available) or “Next Update” (when the current CRL expires) extension is reached. This means that even if you take swift action to revoke a certificate and then generate and publish a new CRL, you have absolutely no control over the fact that the previous CRL may still have quite a bit of validity left. If this is the case, your hastily published new CRL will go largely unnoticed, potentially for the duration of a critical security incident! And no, OCSP is not a panacea either because OCSP ultimately relies on CRLs in most cases as well. 

The takeaway here is that certificate revocation, alone, is certainly not an effective access control within the context of a fast-moving security event.

The CRL Growth Dilemma

New problems arise when certificates are revoked en masse. This is because the size of the CRL file grows with each serial number added. I’ve worked in organizations which only issued internally trusted certificates but managed to publish CRLs in the tens of megabytes. Not only does this cause a large amount of unnecessary network traffic, but in many cases (such as with load balancers and other network appliances with limited-resource embedded systems) there is a hard limit to how large a CRL it can download. After this CRL size threshold is passed, these systems either deny all certificate authentication requests (causing a DDOS) or “fail open” by not performing revocation checking at all!  

I should mention that the Online Certificate Status Protocol (OCSP) does exist which partially mitigates the problem of large CRLs, however, I have often cautioned organizations without sufficient, dedicated PKI staff to think twice before going down the OCSP route. While a CRL is a digitally signed file which can be hosted on any web server on any platform, OCSP is a fully-fledged web application. Being as such, it has a much larger attack surface. OCSP also requires deep PKI expertise to properly deploy, secure, and maintain.

Looking at Certificate Revocation Through a Security Incident Lens

Based on my experience and research, it’s best to treat certificate revocation as a significant event triggered by a security incident rather than as a routine business process related to retiring equipment and offboarding workers. 

When deciding whether certificate revocation is needed, the underlying questions you should be asking are “Have we lost control of the private key?” and if so, “What exactly is the level of risk posed, how long will that risk persist, and what is the likelihood of it being exploited if we don’t revoke?”. 

To that end, here are some recommendations for organizations that would like to rely less on certificate revocation to maintain their security posture:

1. Consider reducing certificate validity periods. Certificates from an internal PKI are, for all intents and purposes, free to issue and replace. So, does it really make sense in all cases to issue certificates that remain valid for a year or more? The validity of different certificate types should be carefully planned out, balancing the administrative and automation effort required to replace them frequently with the risk of issuing longer-lived certificates which impose a longer-lasting threat due to key compromise. 
    
   Even if shorter-lived certificates need to be revoked, they only remain on the CRL for a short time, so their impact on CRL size is greatly reduced. 
    
   For extremely short-lived certificates (a matter of hours), there is the option of volatile issuance. Volatile certificates are signed by the CA but aren’t written to the CA database and cannot be revoked, but the threat posed from compromise is so short-lived that revocation wouldn’t be an effective control anyway.
2. Avoid relying on certificates alone for authentication. I’ve encountered multiple organizations which proudly proclaimed that they had enabled 2-factor authentication for VPN access cost-free by combining internal certificates with network login credentials. However, in all such cases, no binding occurred between the identity of the account logging in, and the identity asserted on the certificate. In such cases, the two authentication factors are intended to be “something you have” and “something you know,” but if any trusted certificate can be combined with any VPN-entitled network login, does that really provide the intended level of security?
3. Protect the private key. Many organizations lose sight of the fact that the security benefit of their PKI program is only as strong as their disciplined commitment to good key management policies and procedures. 
    
   When possible, protect private keys associated with certificates used by critical infrastructure in hardware security modules (HSMs). 
    
   If you want to use certificates in lieu of a commercial MFA solution to provide VPN access, for instance, investigate taking advantage of the Trusted Platform Module (TPM) which most business laptops come equipped with. Such devices make it impossible for the wayward user or administrator to make out-of-band, uncontrolled copies of their certificate private keys.

Conclusion

Revoking certificates should not be seen as a “silver bullet” control or as a cost-free activity. Certificate revocation should be treated as a significant event, driven by the organization’s loss of control over the private key combined with the risk level and persistence imposed by that loss. Compensating controls should be considered to reduce an organization’s reliance on certificate revocation to maintain their security posture.