There is no problem that cannot be turned into a much tougher problem. That’s a feature of human ingenuity.

Essential documents that used to be sent by post might now require a complex series of manoeuvres involving an account name, a secure password, an authenticator app and scanning a QR code before you can access them ‘more conveniently’ online. And if you’re unlucky, the authenticator app you use could turn out to be bogus, even if you downloaded it from an app store.

Checking security certificates used for secure internet communications using TLS is no different, as we learned last week with the compromise of eight certificates issued by eMudhra’s Certificate Authorities, a company declaring its purpose is “to create a secure, connected world built on trust”. The intent here is that they can be blocked by checking certificates against a list of those that have been revoked or compromised in a trust store, which sounds like a straightforward task until you realise there are many trust stores, as it seems every man and his dog keeps their own.

To give you an idea of just how many different trust stores need to be updated to block those eight certificates, Dennis Jackson has drawn attention to more than 80, spread across operating systems, programming languages, apps and command tools. Take into account the many internet-enabled devices like TVs and I’m sure that would grow into hundreds. Instead of using a single common trust store that would ensure everything was protected, we have divided the problem up into a multitude of individual problems, ensuring that some won’t get protected for months, if ever. No wonder the bad guys always seem to be winning.

This is difficult enough for Macs and Apple’s consumer devices such as iPhones and iPads. Apps written using standard Apple APIs, including many of mine, use the macOS trust store, which Apple updated between 19-23 October to block eMudhra’s compromised certificates. Those updates don’t appear in any common sources of information like System Settings, SilentKnight or even SystHist, though. If you want to confirm that your Mac or device has been updated, the best test is to view the checks Dennis Jackson generously provides, using Safari or another app that you know uses the macOS APIs.

As I pointed out, and Apple has explained, that trust store doesn’t cover everything supplied in macOS. In particular, some command tools use a separate trust store at /etc/ssl/cert.pem. Until Apple devises a method of updating that on all recent Macs, if you use curl, git or bundled python, you’ll need to address that yourself by blocking the affected certificates manually.

Problems get worse once you look beyond macOS itself. Among the many apps that maintain their own trust stores, rather than using either of the above, are Google Chrome, Chromium-based browsers, Mozilla and Microsoft products, and some Electron apps. For those you’ll need to update that app to a version whose trust store has been updated to block the compromised certificates. But how can you tell whether that’s required for an app other than a browser? Others could also be affected if they use a language like Python, Java, Go, or possibly Rust or Ruby. Compiling a list of all Mac apps that might need their internal trust stores updated is a daunting task, and unlikely to happen.

If you were using the internet back in 2014, you may recall the chaos that resulted from Heartbleed, a severe vulnerability in OpenSSL 1.0.1, a precursor of TLS, leading to mass compromise of certificates and over a year of global insecurity. While eMudhra’s compromised certificates aren’t on the same scale, they demonstrate how little we learned from that.

One change coming to SSL certificates is their period of validity is reducing. Currently, new certificates are valid for a maximum of 200 days, from March next year that falls to 100, and in 2029 it will become a mere 47 days, requiring sites to renew their certificate every month. But those limits don’t apply to the intermediate certificates issued by CAs like eMudhra, so would have little effect on any future recurrence. As it’s still not clear exactly how the eight certificates involved in this came to be so easily compromised when they were created over a year ago, no one knows how likely that might be.

Yes, the eight compromised certificates were generated on 30 April 2025, but weren’t detected as being broken until 17 October 2026.