Little did I realise when, just over ten days ago, I passed on a warning that older Macs could have a problem looming with connecting to some websites. One comment there even suggested that it would prove just a storm in a teacup, and that the enthusiasts who would keep such old systems in use would take it in their stride. Since the first of those security certificates expired on 29 September, there’s been a steady stream of comments from ordinary users, those operating small websites, developers, and system administrators, documenting far more extensive consequences than any of us had anticipated.

For me, the realisation that this was no teacup came when I checked a local website providing real-time wind and weather reports. My iMac Pro running Big Sur, and my iPhone on iOS 15, both blocked the site as I have shown here. When I tried to connect to it on my M1 Mac mini, running the current beta of Monterey, that had no trouble. There are all sorts of issues which might explain that, but what I saw next I still find unbelievable: side by side, the iMac showed me the broken chain of trust going back through an intermediate certificate which had expired that day, to a root which was due to pass away the very next day. Yet on the mini, the same leaf certificate showed an entirely different certificate chain, including the new intermediate and root.

There’s something badly wrong when two systems on the same network report completely different chains of trust for the same leaf certificate. Yet it seems to happen elsewhere: when I check the certificates for any Wikipedia site, I see intermediate and root certificates from DigiCert which are totally different from those provided by Let’s Encrypt which expired at the end of September, yet several comments here assert that Wikipedia’s certificate traces back through the same expired intermediate and root used by Let’s Encrypt.

As many of you have remarked here, it’s not just a problem with browsers like Safari, but with a wide range of apps, plug-ins, and more. Some third-party browsers such as Firefox (but not Google Chrome yet) manage their own security certificates, which makes working around such problems both easier and more dangerous.

Why more dangerous?

Security certificates are intended to protect you from the hostile Internet. Every time that you allow a broken certificate to be ignored, you’re opening up another vulnerability on your Mac. It’s like the soldier who wears body armour deciding to leave out its protective plates because they’re too heavy and tire them out. The ultimate result is the desire, now being expressed by some in their comments, to be able to disable all security protection. Said soldier now wants to discard their body armour completely.

You don’t have to look too hard or far on the Internet to discover what’s lying in wait for you when you start disabling these protections. In another comment, someone had a close call when the URL they thought was that of their local library turned out to be an imposter, presumably sat waiting to catch the unwary, and those who’ve got so fed up with their browser’s security antics that they override everything they can.

It’s a sad fact of life on the Internet that there’s always someone waiting for you to make a mistake, and to exploit it before you even know what has happened. Safari and other reputable browsers incorporate layers of security to try to help you help yourself. Before you even consider turning any of them off, you need to be absolutely certain that the site you’re trying to open is what you think it is.

When your browser blocks or warns you about a site you want to visit, don’t just blunder on assuming that you’re right. You might be, but you have at least to wonder what’s wrong, and whether that’s a warning in itself. Check the site’s certificates and think through the implications of any error messages. If the identity on the leaf certificate doesn’t match the site you’re trying to connect to, be extremely wary, as that’s a common ploy of impersonators.

There’s one command tool which can prove useful, as it’s designed to test the App Transport Security (ATS) built into macOS. Substituting the name of the website you’re interested in, at Terminal’s command prompt type
/usr/bin/nscurl --ats-diagnostics --verbose https://www.website.com
to see a full diagnostic assessment of ATS.

You can also use OpenSSL in versions of macOS up to and including Big Sur to check security certificates in more detail than you’re likely to get in Safari. Again, with the website substitution
openssl s_client -showcerts -connect www.website.com:443
can prove useful. Apple documents this for developers here, and provides more information about TLS and ATS in its Platform Security Guide.

I think we’ve all been reminded in the last few days just what a mess Web security is, and how the routine updating of security certificates can break all hell loose. Please take care not to let your personal security go the same way.