A critical component of EAP-TLS certificate-based authentication is properly managing certificates, which includes confirming that they have been properly revoked AND placed on the list of revoked certificates so the RADIUS server is aware of the new status of the certificate.
One of the quirks of authenticating X.509 certificates is that they are trusted and valid until proven otherwise, unlike credentials which are always “wrong” until proven correct. That’s why managing revoked certificates is just as important as managing active ones.
Why are Certificates Revoked?
Certificates are revoked when they need to be decommissioned before the end of their “natural” life cycle at their expiration date. Typical reasons to revoke an 802.1x digital certificate include:
- The client device is being retired
- The client user’s permissions are changing (promotion, leaving the company, lateral transfer)
- Access to certificate is lost (usually losing a device)
- Certificate is compromised (issuing certificate authority compromised, client user turns coat)
It’s important to know that expired certificates are not considered revoked and do not get treated like revoked certificates (placed on a CRL or similar). Authentication mechanisms, a RADIUS server in 99% cases, will immediately reject any certificate past its expiration date whether or not it is revoked.
Certificate Revocation List (CRL)
The standard solution for notifying the RADIUS server of revoked certificates is a certificate revocation list, which is precisely what it sounds like – a list of revoked certificates.
CRLs work just fine for the majority of organizations, but they have one major drawback: file size. Orgs that find themselves revoking certificates frequently, either because of the need to reissue certs or simply having a lot of network user turnover, will eventually build a CRL measured in megabytes instead of kilobytes.
Since the CRL needs to be referenced for every authentication request, a large CRL size can noticeably slow authentication speeds.
Base CRL and Delta CRL
The fastest and most secure way to keep track of revoked certificates is to use a set of base and delta CRLs. They neatly resolve the issue of large file sizes by storing a cached version of the CRL (base CRL) locally on the RADIUS server and only requesting any updates to that list (the delta CRL). Far fewer bytes are sent with each authentication request and it mitigates the need for a frequent update interval.
Online Certificate Status Protocol (OCSP)
Online Certificate Status Protocol was developed in response to slow CRLs, but it has a couple of significant issues that prevent widespread adoption.
The first issue is that it doesn’t usually succeed in being faster than a CRL. The protocol shifts the burden of checking revocation status from your PKI to an online public CA’s server and uses a simplified data structure, but the net result isn’t faster and it is less information-rich.
Worse, OCSP is notoriously vulnerable to man-in-the-middle attacks, specifically a “replay” attack. The authentication requests an OCSP receives don’t have encryption requirements and it conserves bandwidth by giving valid certificates a “validity period”, instead of requiring authentication each time. The result is an easily exploited authentication service, a nightmare scenario for cybersecurity experts.
How to Confirm Certificate Revocation Status
The particulars of checking a certificate’s validity status differs based on the certificate management solution (CMS) you are using. A good CMS will allow you to search for specific certificates via attribute values, or have sorting and filtering features.
For this guide, we are using SecureW2’s Management Portal to find an example certificate that has been revoked.
This screenshot shows the certificates issued to a particular device, in this case a smartphone. Note that the certificate status is already marked “Revoked”.
However, the typical RADIUS authentication request does not contain certificate status. Instead, the RADIUS checks if the certificate is present on the CRL and denies the request if it is.
Here we can see that the same certificate is on the certificate revocation list.
Attempting to authenticate with that certificate should cause the RADIUS to reject it and deny network access. We can confirm that by navigating to AAA Management > Events.
The most recent event was indeed an ACCESS_REJECT, so the RADIUS did successfully catch the revoked certificate in time to deny access.
Automatic Certificate Revocation Checks and More
Managing revoked certificates is one of the hassles of a certificate-based network, but it can be simpler than any of the CRL solutions discussed above. SecureW2’s Dynamic Policy Engine allows the RADIUS to directly reference any cloud directory (such as Google, Okta, and Azure) to confirm permissions in addition to, or in lieu of, normal CRL checks.
Our robust CMS automates much of the certificate lifecycle, including revocation, but still gives admins granular control over the process and the ability to examine any part of their 802.1x network.
We have affordable options for organizations of every size. Click here to see our pricing.
