Archive for February 18th, 2022

Apple’s computers are too good – they keep working and working. Case in point: we still use a Mid 2007 iMac at home. And: I also still use a Macbook Pro from Mid 2012. Certainly we’re not the only people in the world that do not throw out our computer every three or four years.

Hence it would be… nice if Apple kept the software on those older machines up to date. I understand that Apple cannot implement every last novelty on those oldies. That’s not what I’m asking for. But security patches and certificate updates can’t be that hard to integrate in some sort of update package for earlier versions of Mac OS X. After all, email is still email, and web browsers from 10 years ago are still capable of displaying most current sites. Just covering those two functional domains might allow many Mac users to use their older machines. How about it, Apple?

One of the issues posed by these older Mac OS X versions is the browser message “This Connection Is Not Private” when trying to access a site over the secure https: protocol. This message means that there is a problem with one or more certificates in the certificate chain for that particular site. Usually it’s a matter of expiration: certificates are only valid for a specific period of time. That is also the case for the certificates that were used by the Certification Authorities that sign the TLS certificates for the website. As time goes by, some of those “root certificates” expire, making browsers like Safari pop up warning messages to tell you of the problem. The correction for this problem is easy: the root certificate has to be updated, and things will work again. As long as Apple updates Mac OS X on your Mac, they will do that for you, and you don’t have to worry about this problem (at least for websites that play by the book!). However, if you’re not familiar with the underlying mechanisms in the browser, the error message is actually blocking you from accessing the site – even when in fact there is nothing wrong with it (the problem is on your Mac!).

Can this problem be fixed on older MAC OS X versions, for which Apple no longer provides updates? Luckily, the answer is yes. But it is not a “click here and you’re done” kind of fix; you need to have some experience with the Terminal application and the bash command line on your Mac, and you also need access to a Mac with a recent (preferably the latest) version of the certificates.

Here’s the procedure, paraphrased from StackExchange. To simplify things, I’ll describe how to update all system root certificates in one swoop.

  • On the ‘newest’ Mac, launch the “Keychain Access” application.
  • In the “Keychain Access” application, click on “System Roots” in the left column, and select all certifcates in the list that appears (a single click in the that list, followed by Cmd-A).
  • In the File menu, select the option “Export Items…” and save the file as “rootcerts.pem“.

All the certificates will be stored in that single file. The first thing to do now is to transfer that “rootcerts.pem” file to your ‘old’ Mac. You can do so with a memory stick or card, by email, or by using some kind of cloud storage (Google Drive, Dropbox, etc.).

To do so you should log on to the ‘old’ Mac, using a user account that has administrator rights.

  • Put the “rootcerts.pem” file in a folder, e.g. “Downloads”.
  • Open the Terminal application, and go to the folder with “rootcerts.pem” file.
  • In that folder, create a new script file called ‘trustroot.sh‘ (yes, I prefer to add a .sh extension to that file in order to recognize it as such later on), and add the following content (using pico or the text editor of your preference):
mkdir -p ${DIR}
trap "rm -rf ${DIR}" EXIT
cat "$1" | (cd $DIR && split -p '-----BEGIN CERTIFICATE-----' - cert- )
for c in ${DIR}/cert-* ; do
   security -v add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "$c"
rm -rf ${DIR}
  • Save the file and make it executable, using the command ‘chmod 755 trustroot.sh‘.
  • Everything is now in place; all that remains to be done is the execution of the script with the following command line (plus your sudo password, of course):
sudo ./trustroot.sh rootcerts.pem

You should see a list of certificate descriptors pass by in the Terminal window.

The certificates exported from your ‘new’ Mac will now be included in the list of ‘System’ certificates (as explained on StackExchange, only Apple can update the ‘System Roots’ keychain), but they will be taken into account just as well.

You can close your Terminal session now. It’s up to you to decide whether or not to keep the ‘trustroot.sh‘ script for future use; you will have to replace the rootcerts.pem file later anyway, with a more recent version of the certificates.

If everything went well, your browser should no longer show the dreaded message – except for sites that really have an expired certificate.

PS. I have changed the location of the temporary directory in the ‘trustroot.sh‘ script to the current directory, compared to what you see on StackExchange. I did that because I got an error message when running the ‘trustroot.sh‘ script that complained about “/” being a read-only file system. Somehow the settings of my Terminal shell had chosen “/” as the TMPDIR, and you can’t just create new folders there. Since the script deletes the temporary directory anyway, it’s location doesn’t matter; it will exist for a just a few seconds anyway…


Read Full Post »