Here's what we know – as of August 21st, 2024:

• Firefox and Vivaldi currently lead the industry in certificate revocation checking security. By default, if a site does not provide a valid stapled OCSP status, they query for that site's OCSP status to make sure its certificate is currently valid. Unfortunately, no other web browser currently does this. (Note that under iOS, Apple forces all other browsers to use their Safari engine... so other browsers running on iOS are actually just “browser skins” over Safari.
• iOS may be somewhat better than the rest. The day after the podcast which mentioned that Safari on iOS was again displaying this page, that behavior changed. It MIGHT have been due to the server's deliberate blocking of OCSP which forced Apple to add the certificate to a certificate revocation list (CRL). So I've changed the certificate and iOS is again showing the page. This time I'm going to keep quiet about it!
• NO OTHER BROWSER in the industry – not Chrome nor any of the Chrome derivatives – show any indication that they check website revocation in any way. (If you have a browser that appears to, please let me know!)

This “revoked.grc.com” 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, this special site is 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.

And now you understand the problem . . . or YOUR problem: The fact that you are viewing THIS PAGE, which was displayed “securely” using a deliberately revoked certificate, means that this web browser is either deliberately by design, or through misconfiguration, ignoring the Internet industry's deliberately designed and otherwise functioning certificate revocation system!

This means that this web browser will not detect and warn you if you
visit a fraudulent website that is using a revoked certificate that is
known to the REST of the Internet to be bogus. YOU won't know.

At the moment, and for the next several years, this potential danger is extreme, because many experts believe that the long unseen Heartbleed vulnerability, which affected approximately 17.5% of the Internet's websites, may have been used to steal those sites' security certificates. If, upon learning of Heartbleed, those sites took the responsible action of revoking their possibly-compromised certificates and having replacements reissued, and if those stolen certificates where then used to impersonate the once-vulnerable sites, this web browser WILL NOT DETECT AND WARN YOU that you are visiting a known-fraudulent website.

By April of 2017, all of the certificates which may have been stolen via Heartbleed will have died of old age, and the threat will diminish to normal levels. But fraudulent websites are always a threat. You need to be aware, especially for the next several years, that this defective web browser is ignoring the certificate revocation mechanisms that the Internet's designers put in place specifically to protect users from the persistent threat of rogue certificates.

Good luck!

If you are interested in learning what you can do about this, and to understand more about the situation and problem of security certificate revocation, please see these pages: