Revoke certificates when you need to -- the right way

A secure Internet runs off the assurance of digital certificates. Revoking those certificates is often necessary, but problematic. Here's your best shot at doing it effectively

1 2 Page 2
Page 2 of 2

A checkered past

Unfortunately, for a long time, revocation checking did not work reliably or wasn't enforced for many certificate-consuming applications. Either the certificate creators did not have the necessary, accurate revocation information, or the applications themselves failed to check or enforce (often because of the former problem).

Many times an application would check for revocation information, then fail "open" if it could not find valid data. I remember writing at least a half decade ago that most revocation information was invalid on the majority of certificates. It's still a challenge the PKI world fights every day -- which is why some third parties are trying to invent their own, newer methods for checking certificate validity.

However, today, most certificate issuers are getting it right, and more and more consuming applications care about whether revocation checking is done right. Some applications will still fail open or warn you when you can't access revocation information, but they number fewer and fewer every year. More often than not, if the revocation information can't be checked, the application will fail or send an interrupting warning.

All of this background brings me to my ultimate objective for this blog: Many readers ask if they should revoke user (or computer) digital certificates when the user (or computer) certificate is no longer needed. More specifically, I hear the question: Should a user certificate be revoked if the user is fired?

Clamping down

Here's my answer: Revoking an unused certificate is always the safest course of action from a security perspective. If you want the best security, revoke the certificate when it is no longer needed.

That said, it's important to note a few issues. First, revocation often doesn't work because consuming applications might not check it or might fail open. Second, when users get separated from employment, their related directory user account is usually disabled or deleted. This tends to have far more impact on the ability to access the network or device than revoking a certificate. In most scenarios, disabling or deleting users' accounts will prevent them from accessing most company resources. Only within consuming applications in which the user's certificate alone is considered for authentication would the user still have full access. This is usually not the case.

Most of the time it takes a valid, unrevoked certificate and a valid user account for users to reach their normal resources. Only through testing can you can tell for sure which method your application is using, but most of the time, if you leave the users' certificates unrevoked and delete their user accounts, the best they could do is access layers 1 to 3 of the network. Most access control is enforced at the application (layer 7).

I suppose if a user still had their unrevoked cert, but no valid user account, the best they could do is cause network problems, including broadcast storms, denial-of-service events, eavesdropping, and so on. These aren't to be taken lightly. But in today's digital world of VPNs and switched networks, those tasks become harder to accomplish, especially if the employee doesn't have physical access to the network (wireless networks are an obvious exception). Network layer attacks are exceedingly rare within a corporate network. Can you even remember the last time you had an attack at layers 1 to 3 of your network from a previous employee?

Best revocation practices

If you want the best security, revoke the certificate. However, even if you don't, I'm not sure how much risk you're really running. Most companies today never revoke any certificates for their employees, mostly because they neglected the decision and didn't think about it. But failing to revoke seldom causes problems. Your mileage may vary -- discuss and decide, so everyone understands the risks and benefits in your environment.

The problem I worry about even more is how your company's environment will react to very large CRLs, which will surely materialize if you revoke certificates all the time. I've had a handful of clients with hundreds of thousands to millions of revoked certificates. In a few instances, the CRLs grew so large that it caused network issues. In one case, it completely shut down a directory service.

Instead, if you revoke certificates on a regular basis, opt for OCSP. For years, OCSP has been recommended in place of CRLs, which should have disappeared over a decade ago. Yet they appear to be holding on for dear life.

Revoke unneeded certificates and use OCSP. That's my digital prescription.

This story, "Revoke certificates when you need to -- the right way," was originally published at Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at For the latest business technology news, follow on Twitter.

Copyright © 2014 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Microsoft's very bad year for security: A timeline