Field Report – Stop REACTING to Expired CRLs

In this article, I continue to dig into how we are changing the world of PKI administration with PKI Spotlight. One of the most common issues organizations face around the world is due to expired Certificate Revocation Lists (CRLs). If you’re not already familiar, Certificate Authorities (CA) are not involved in the moment-to-moment verification of the certificates they issue. That is the beauty of PKI, the CA can issue certificates to identify systems, and any two systems that need to authenticate can do so without requiring access to, or bandwidth of, the CA that issued the certificates. However, they are constrained by RFC 5280 to check if any certificate they are verifying has been revoked and placed in a CRL. Thus access to a time-valid CRL is critical to any certificate-based authentication or encryption system.

Expired CRLs happen due to technical issues, network communication problems, firewall issues, HSM failures, and human behavior.

Almost every single customer I have ever worked with over the last 2 decades has had several CRL issues a year and is the biggest pain they have – period. Yet every available tool they have can at best tell them AFTER a CRL has expired. So they are already in a business-impacting situation once they find out and are in a rush to correct the issue before the impact is felt throughout the organization. By then, it’s too late to completely avoid all impacts. Additionally, an expired CRL can potentially introduce a large security issue as each individual system and product may behave very differently than the RFC when faced with an expired CRL. Some fail in an “open” state and allow authentication to complete even though this critical check can’t be performed. Guess what adversarial attackers would like to occur in your environment?

So, imagine a scenario where you could be alerted to an issue BEFORE your CRL ever expires. What if that was hours or even *Days* before the potential impact on your business? What kind of black magic could do that? PKI Spotlight of course!

So how are we doing this? Well, there are a number of things we are providing in PKI Spotlight to pre-detect failures that will cause a CRL to expire:

#1 Is-Alive for CA Health

Our Certificate Is-Alive feature performs regularly scheduled checks of all components of the CA to ensure it is functioning and is able to access its cryptographic keys and that its core functionality is healthy. These are all required to be able to create and sign a CRL when it is next due. If a failure is detected, we alert PKI Admins the moment an issue is detected – even if it’s related to an HSM or cloud-based HSM.

#2 CRL Publishing Monitoring

Our Best Practices engine is constantly looking for issues relating to the publishing of CRLs. If you dig behind the scenes, you’ll see that the CRL is created and published PRIOR to the actual expiration of the CRL itself. In Figure A below, you can see an example of this. This CRL was published on October 7, 2022 (Event A). It is valid for 7 days and will expire on October 14, 2022 (Event C). In addition, there is an expected date when the CA will create, sign and publish the CRL on October 13, 2022 (Event B). If the CA is operating properly and there are no issues, the CRL will be replaced on October 13th. If there are issues, the CRL will continue to be valid until its expiration date on October 14th. The period between event B and event C is called the CRL Overlap.

Figure A – CRL Timeline

Almost all monitoring systems, including Certificate Lifecycle Management tools, generic network monitors, and in-house custom scripts are all waiting to detect if a CRL expires. In essence, they alert if a CRL is found past event C. By then, it’s too late – the organization is already impacted. If there was a CA corruption or hardware failure, it could take considerable time to recover. At best, you are in a race against the clock to prevent massive outages in the organization.

PKI Spotlight does this completely differently. Not only are we continually performing Is-Alive checks against the CA during the entire CRL cycle, but we are also watching to ensure the CA actually publishes and replaces the CRL at the intended time (Event B). If either Is-Alive or a Publish failure is detected, PKI Spotlight alerts PKI Admins hours or days before an impact. This provides the ability to identify and remediate issues before it ever results in a revenue-impacting outage.

PKI Spotlight enables you to pre-detect CRL failures and stop REACTING to expired CRLs. A total game changer.

About ThePKIGuy

President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.