macOS fix for expired certificateAnswered

Hello,

Can you give some details about the Terminal command you used to do so ? I search but didn't find one.
On OSX 10.11, the following command fixes everything : 
sudo security -v add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain isrg-root-x1-cross-signed.pem

In last couple of days, I explored a lot of solutions. The best one I found is to use offline activation/deactivation. 
In brief, I wrapped TA_Activate() so if it returns TA_E_INET_TLS, it falls back to offline activation (I automated everything with a PHP script and TurboActivate's web API). I tested this solution a lot, and it's fine.

My emergency solution was to use TA 4.0.9.6 that doesn't have the certificate issue, but it's risky. At least, it bought some time to find a better solution.

Best. Philippe

Hi Philippe,

Here's a summary from what I shared with my customers and it reportedly works well for macOS 10.13, 10.14 and 10.15.0-5:

(0) In a Terminal window enter: /usr/bin/curl -I https://letsencrypt.org (or https://wyday.com, of course) to prove the issue. 

Expect to see a message like this

curl: (60) SSL certificate problem: certificate has expired

(1) In a Terminal window enter open /etc/ssl and create a backup copy of /etc/ssl/cert.pem and keep it in a safe place 

(2) create a a local copy of /etc/ssl/cert.pem and open it with, say, TextEdit

(3) find "DST Root CA X3" and delete the related certificate block starting after the preceding "-----END CERTIFICATE-----" line thru (including) the next "-----END CERTIFICATE-----".

(4) save the changes

(5) copy the local cert.pem back to /etc/ssl/cert.pem (requires macOS admin password)

(6) check and fix the owner of the file. Must be 'root' (System).  (requires macOS admin password)

(7) repeat step (0) to prove it's working now.

Best, Ferdinand

Thank you so much for this. I am an end-user of a licensed software product, and have come here because the software provider wasn't able to provide a fix for end-users like me using 10.14.6 because, believe it or not, a large portion of the film/sound industry is still on Mojave because we still need 32 bit architecture for certain software (something that WyDay's arrogant assertions to “update to 10.15” completely miss, nevermind that some people are unable to because the hardware is too old). However there is one step missing from the above, namely ROOT permissions to ensure root:wheel permissions for cert.pem (as no user should be logged in as ROOT). So:

(6) check and fix the owner of the file. Must be 'root' (System).  (requires macOS admin password)

TO DO THIS in Terminal (as no user should be logged in as ROOT):

a) open SSL directory in Terminal where cert.pem is stored (the new version should already be copied back into the folder as per above):

cd /etc/ssl

b) change permissions of cert.pem to root:

sudo chown root:wheel cert.pem

There you go.
 

Huge thanks to Ferdinand Schwoerer — you've saved an entire film from missing a festival submission deadline. I owe you beer sir.

 

Glad I could helped, Tobias.

Many of our customers are on tight deadlines working on older equipment or ‘outdated’ software with no opportunity to update their macOS. 

I couldn't just sit and wait for some magic to eventually happen.

And, thanks for pointing out the details/cmds for (6)! Much appreciated.  

This would be a simple one liner your customers might be able to use:

sudo echo "" && curl -s https://gist.githubusercontent.com/cbenhagen/fe8ed84911b32103e1de80a489c803ea/raw/91be436650e0198dab18a590d1cb9dc132a69e79/cert.pem.diff | sudo patch -Nb /etc/ssl/cert.pem

The diff was created on an updated macOS 10.14. It might work on other versions.

Also, here's a good base-level, updated CACert package to overwrite the out-of-date one they have on unsupported-by-Apple versions of macOS.

More info here: https://curl.se/docs/caextract.html

Also, we'll have TA 4.4.4.1 for macOS by Friday this week to work around this Apple bug so these trick won't be necessary once that is out.

Glad I checked here, we were also experimenting this issue and was wondering what was going on… Said before, not an option to ask clients to upgrade OS for us (they have multiple reasons not to upgrade), and perhaps next time: 1) warn limelm users ahead of any such changes and 2) perhaps provide a simple app for user to run to fix them…

Pierre

1) warn limelm users ahead of any such changes

This was not a change. It is a bug in macOS 10.14 and older. When we release 4.4.4.1 it will be a workaround for the Apple bug.

Regarding updating:

macOS 10.13 and older no longer receive any updates and are vulnerable to security bugs (i.e. ransomware, crypto-mining, botnets, etc.).

macOS 10.14 will no longer receive updates in 25 days and will be vulnerable to security bugs (i.e. ransomware, crypto-mining, botnets, etc.).

If the end-user cares about their data they should update to macOS 10.15 and newer regardless of this specific Apple bug. Particularly in the film industry: remember the Sony hack? It was caused by not updating (the hackers didn't use 0-days, they used known and fixed vulnerabilities).

Will that fix work for macOS 10.11 - 10.15.5?

Yes.

Will removing DST Root CA X3, or even overwriting it, cause a security risk?

It might break other software. Just update TA and/or update macOS.

This is a solved problem.

Hi,

I still got TA_E_INET_TLS with TA 4.4.4.1 on macOS 10.9.5

in order to use TA on this computer I 

lipo libTurboActivate.dylib -remove arm64 -output libTurboActivate.dylib

but before it was working.

++

wow, thanks!!

for the solution (that worked on my antique macOS 10.9) and for the fast reply

++