A few days ago I warned that those still using older versions of Mac OS X are likely to have problems making secure HTTPS connections with many websites, because of a security certificate due to expire on 30 September. Unfortunately, it has turned out that this isn’t confined to older Mac OS X, and can even affect Monterey betas. And there’s more than one certificate which has now expired.

The signs of trouble are obvious. You try to connect to an affected website using Safari, only to be informed that This Connection Is Not Private. That Safarian error message means that it tried to connect using HTTPS, and has detected a certificate problem. This can affect any (reasonably recent) version of Safari, running on macOS, iOS or iPadOS, and on pretty well any version of those operating systems. It may appear sporadic, although once it has affected a site, Safari is unlikely to be able to make that connection properly again.

The solution depends on your confidence that the error is spurious, which depends on how much trust you can put into that address and site. You might wish to use another browser like Firefox to check the website out before making any decision, then clicking on Show Details to proceed further in Safari.

Further information provided by Safari is helpful, explaining the certificate expiry, giving that date and inviting you to check your Mac’s clock. If you’re happy that doesn’t explain the problem, click to view the certificate.

In this case, the site’s certificate remains valid until the end of this year, but the intermediate certificate R3 has expired.

Although this is a Let’s Encrypt certificate chain, the first of the certificates to expire wasn’t its DST Root CA X3 which we were warned about, which remained valid at the time that this happened to me. The first certificate to expire was the intermediate R3, which expired on 29 September, a day earlier.

Step back to the Root Certificate, and you’ll see that’s due to expire on 30 September, the very next day.

The immediate solution is to manually approve that site’s certificate, which bypasses the expiry of its other certificates. Safari will then add a special certificate to your keychain for that particular site.

Once that has been added, you can continue to access that specific site, but others which rely on the same chain of trust will need to be added individually.

However, according to my previous article, this shouldn’t affect macOS 10.12 or later. So why did I have this problem in 11.6?

To answer this, I tried making the same connection on my iPhone (iOS 15), which failed similarly, and on my M1 Mac mini (macOS 12 beta 8), which had no problems at all with that site. Indeed, it showed a different chain of trust altogether.

The site’s certificate appears identical, although the Root Certificate is different, ISRG Root X1, which is the replacement for the DST Root CA X3 expiring on 30 September.

The intermediate certificate R3 here has an expiry date in 2025.

And the Root doesn’t expire until 2035.

So how come two different Macs connecting to the same site get such different chains of trust?

The answer I suspect lies in the caching of certificate checks. Both my iMac and iPhone have connected to this site previously, and rather than performing a full certificate check every time, macOS is just using old results, which still refer to the old intermediate and Root certificates. My M1 Mac mini had never connected to that site, so had to perform a fresh check on the chain of trust, which then traced back to the current chain with its replaced intermediate and Root certificates.

What can you do about this more generally, to save you from having to make each broken site an exception? As far as I know, nothing that you’d want to. Emptying Safari’s caches doesn’t help, as I think the old certificate information is held in a separate security database to which the user has no access. Unless you know better.

No thanks to Let’s Encrypt, which seems unaware that any of this might cause such problems.

Note

Whether you’re running a server which relies on Let’s Encrypt certificates, or trying to connect your browser to one, the most helpful and information page on the subject is this one from Certify The Web.

Thanks to Peter for that link.