Use your various desktop and mobile web browsers to visit this special site: https://revoked.grc.com Since that site's security certificate has been revoked, your web browser should refuse to display a page. If you CAN see the resulting page, PLEASE read it carefully! You may be surprised and disturbed.

Our additional Certificate Revocation Pages:

2 Browsers & OSes   3 Chrome's CRLSets   4 OCSP Must-Staple

This Security Certificate Revocation Awareness Test was born from the revelation of the worrisome “Heartbleed” vulnerability that had existed in plain sight for two years without public awareness in the industry standard open source OpenSSL security suite. However, these pages are about more than that:

The security of connections between devices through the Internet depends upon “authentication” (being certain to whom we are connecting in an environment where we have no direct means of verifying) and “privacy” (being certain that our communications cannot be eavesdropped upon despite the fact that our data traffic may be travelling great distances outside our direct control). Those two security properties are assured only through the integrity of the Internet's security certificate infrastructure.

“Certificates” provide a means for web servers at
the far end of remote connections to verifiably
assert their identity across the Internet.

The security certificates that routinely assure the security of our Internet connections are among the most closely guarded and protected secrets any organization maintains. Because secrets are notoriously difficult to keep, and “certificates” are just a small file of binary data, the certificates used to assert a web server's identity routinely expire every two or three years. So even if a certificate were to somehow escape, it would “die” of its own age before long. The problem is that “long” is a relative term. In a world increasingly connected by beams of light, malicious forces can wreak tremendous havoc in seconds, let alone years.

The so-called “Heartbleed” vulnerability shocked the
Internet with the specter of mass certificate theft.

The normal life cycle for a security certificate is one where it successfully remains secret throughout the span of its two or three year life. Then, as its pending self-expiration approaches, it is replaced by a freshly minted certificate with another two or three year life span. The replaced certificate is digitally shredded so that even during its last days it cannot be maliciously abused. And so the cycle repeats.

But we all know that humans, and human computer programmers, are fallible. Mistakes will happen. What if an organization came to believe, or even suspect, that their prized secret certificate might have escaped from their control? With so much riding on a simple collection of bits, the Internet's designers recognized that there were many situations, perhaps most situations, where waiting several years for a possibly lost or stolen rogue certificate to expire was not an option. The danger and risk was just too great. We needed a means for killing off (invalidating, revoking, etc.) any certificate whose owner believed, for whatever reason, that they and those relying upon that certificate's assurances might be damaged through its abuse. So, mechanisms for certificate “revocation” were created.

Due to “Heartbleed”, the Internet industry was suddenly faced with the critical need to revoke vast numbers of possible-stolen security credentials.

What we found was . . .

Much of the certificate revocation system is
badly broken and doesn't actually work!!

Disturbing as that might be, that statement is not hyperbole, exaggeration, or even news to the people engineering today's Internet. They know that today's certificate revocation is an empty phrase. They've been writing and working on and talking about various solutions to it. But no one had been in any big rush to do anything about it.

Good and complete solutions DO exist. The problems have been solved. All we need is for the people in charge to give it more of their time and some priority.

Express your unhappiness over the fact that
certificate revocation isn't working and
perhaps we can get that changed!

• To learn about the behavior of any specific web browser or operating system, see: Browsers & OSes.
• For a detailed and in depth treatment of the history and evolution of web certificate revocation, please see our companion OCSP Must-Staple page.

Certificate Revocation Pages:

1 Introduction   3 Chrome's CRLSets   2 Browsers & OSes   4 OCSP Must-Staple

A special note of thanks to the great people at Digicert, GRC's carefully chosen and, we believe, the best certificate authority, who were gracious enough to work with us to create a special pre-revoked security certificate. Perhaps the first time this has ever been done!