Over the past weekend in #autopkg Slack channel in the MacAdmins Slack, some fellow admins saw their recipes erroring with a non-zero exit status of 60.

At dataJAR we only run our AutoPkg recipes weekdays, but sure enough we hit the same issue come Monday.

Below is some more details, as well as a proposed fix for at least the short term.

What happened?

Well…

The AddTrust root CA expired May 30 2020 and now OpenSSL libraries used in tools like `curl` are struggling to recognise intermediate certs that are cross-signed to get around expiring root issues

From this blog post from Aaron Polley

For more details on cross-signing please see this blog post from Sectigo.

Visibility

The issue is that these cross-signed certs will not show in an internet browser, as they use a different cert store.

Below is an example.

But, if we try to curl that site:

curl https://fael-downloads-prod.focusrite.com
curl: (60) SSL certificate problem: Invalid certificate chain

As Aaron Polley mentions, curl is using a different store for certificate trust than browser.

Proposed fix?

The below is something we’re cautiously using on AutoPkg hosts as a short term fix.

This was originally found in this Stack Overflow post, & other methods are detailed there too.

I don’t recommend running scripts on endpoints to curl to bash items & therefore do not recommend this across a fleet.

But, details below:

sudo cp /etc/ssl/cert.pem /etc/ssl/cert.pem.orig
sudo nano -c /etc/ssl/cert.pem

Once in the file, look for the AddTrust AB cert & delete the entry, then save & exit.

This entry can look like the below:

Or the below, depending on the version of macOS etc:

The above is around line 2900, hence the -c flag for nano.

Both will have the cert with —–END CERTIFICATE—– & —–BEGIN CERTIFICATE—– blocks.

Once the changes have been made, you should be able to curl the failing URL’s again without issue.

I went with these changes due to differing contexts which AutoPkg is ran (launchd, user etc).

Use with caution.