Considering how security certificates are supposed to ‘just work’, they get a lot of news coverage when they fall short. Only this last week, when a couple of certificates used by Let’s Encrypt expired, many users have been experiencing problems connecting to websites as a result. Yet every security certificate has an expiry date, so why should this always seem to cause problems?

Security certificates generally have two main purposes: identification, and provision of keys used for encryption and decryption. When used for some specific purposes, as in code signing certificates in macOS, the process of signing may support other purposes; in that case it’s accompanied by the calculation of cdhashes, which are used to verify the integrity of executable code by the macOS security system, and that’s why signing is required for all ARM native code running on Apple Silicon Macs.

In the rest of this article, I’ll focus on the use of security certificates for one of their most common purposes, in establishing a secure connection to a remote server using the HTTPS protocol, using Transport Layer Security (TLS), which long ago was known as the Secure Sockets Layer (SSL) and is still occasionally referred to incorrectly as being SSL.

A security certificate consists of a public key and the information required to identify its owner. The public key is part of a specially generated key pair, of which the owner keeps the private key a secret. When a certificate is used as part of an encryption protocol, the public key is used to encrypt data that need to be sent securely from client to server, and only the private key will enable its decryption.

Identification of ownership relies on establishing a chain of trust going back to a Certificate Authority (CA), normally accomplished using three separate certificates. The trusted CA has a Root certificate which it signs; it then issues intermediate certificates that can be traced back to that Root certificate. At the end of the chain, a ‘leaf’, your security certificate, can be traced back to an intermediate, thus to the Root. If at any stage in that chain a certificate has expired or is not valid, then it invalidates all the security certificates from there out to the leaf.

Security certificates have a validity period determined by their not valid before and not valid after datestamps. That period is determined by the issuing Certificate Authority, and is normally long for Root and intermediate certificates, anything from 10-25 years, and shorter for individual leaf certificates, which are usually only valid for a year or two.

Like most operating systems, macOS comes with a set of standard trusted Root certificates stored in /System/Library/Keychains/SystemRootCertificates.keychain, locked down on the System volume, which are also documented for various versions of macOS in this article. Individual browsers may store their own; for example Mozilla’s Firefox are given here. You can also inspect security certificates stored in keychains using the Keychain Access app in the Utilities folder, and by clicking on the padlock at the left of the web address in the top of your browser.

When your browser tries to establish a secure HTTPS connection to a web server, it first has to ask the server for the privilege. Following that, it asks the server to identify itself using its security certificate, through a complex series of exchanges. The server sends the site’s certificate, and your browser should then check its validity. If that succeeds, your browser informs the server that it is happy to continue, completing the ‘handshake’ required to switch over to TLS. Sensitive information is then encrypted and transferred using HTTPS to the server.

Checking the validity of security certificates normally imposes a delay in the process of establishing the connection, thus the loading of the web page. To reduce the chances of that happening, browsers and operating systems try to store certificate information locally, in a database or cache. As with all such local stores, they run into trouble when the information they contain becomes out of date, and that’s likely to occur around the time that a certificate in the chain of trust expires by date. When that happens to a browser using its own cache for checking certificate validity, it can offer to work around the problem quite easily. In macOS, Safari and the WebKit underpinnings which are used by many third-party apps may not be so forgiving.

For Mac users, the biggest problems with expiring certificates haven’t occurred with websites, but when Apple’s certificates have gone out of date. As Apple is its own CA, this most commonly occurs with its intermediate certificates, and caused minor crises in February 2015, and again almost two years ago, when one of Apple’s intermediate and at least one user certificate expired on 24 October 2019. If you still have old Apple installers from before that date, they no longer work as their chain of trust is broken.

The good news is that, as far as the certificates Apple issues to third-party developers are concerned, it should be a while before we next run into problems with expiry. The rule applied to signatures on apps is that the signing certificate must have been valid at the time of signing, rather than the time of checking. So you’ll be able to carry on installing and using apps well after their signing certificate has expired.

Of more concern is Apple’s intermediate certificate against which code signing certificates are verified. For third-party apps, that doesn’t expire until 2027. That will be something to look forward to.