SHA-1 Certificate Warning

Hello all. Today I want to talk to you all about certificates and in particular, publicly signed certificates. I’m going to do the short version straight away for the sake of clarity and understanding before I do the deep-ish delve.

If you are running certificates from a public source (such as Symantec, Entrust, GoDaddy (really?) ) that use SHA-1 at any point in their chain of trust, then you should replace them with SHA-2 ones now.

Now here’s why:

That’s the pop up you get on macOS 10.12.4 or later when you are dealing with a system that is using certificates that the OS suddenly doesn’t like. Now a standard user can just click the “Continue” button and continue on but this is only a temporary fix.

Let’s wind the clock back a bit and explain the history of what’s going on. Then let’s get into the hows and whys of what is now going on. After that, my warning above will hopefully make a lot more sense.

History

SHA-1 or Secure Hash Algorithm 1 is a cryptography hash function designed back in 1995 by the US NSA. It was used successfully for many years and used to be regarded as secure. That changed in 2005 when it was found that it was possible to reduce the computational effort to crack the key down to something approaching a human lifespan. To quote big numbers, a brute force would take 2^80 operations and researchers managed to get this down to 2^35 operations.

Then in 2015 it really was broken with The SHAppening which managed to undermine SHA-1’s security claims. 2017 was a real watershed when Google announced the SHAttered attack. SHA-1 was pretty much insecure for general internet use at that point. The resources needed to break it were in reach of minor corporations, let alone governments.

With all this going on the world’s major IT players were not sitting there doing nothing. Security is a major selling point, especially for us in the Apple world. By the end of 2016 companies such as Apple, Microsoft, Mozilla, Google and others had plans to stop dealing with SHA-1 certificates, and to start warning users of the dangers. Some made their plans public.

Apple as is typical, mentioned a couple things in passing at WWDC 2016 and then said nothing. Actions spoke louder than words when iOS 10.3 and macOS 10.12.4 suddenly started asking users if they wanted to trust seemingly valid certificates. Apple also started removing root certificate authority certs from the system keychain on both OS’.

The result is the pop up window above. This isn’t a situation that will continue to exist because of Apple’s increasing security focus. (Destroying their admin access to iCloud key vaults every time they’re created? Yeah, they’re taking the whole subject seriously.)

Diagnosis

Let’s have another look at the example, so i’ll post it here again. Then we’ll do some detective work that thankfully only involves Google.

In the middle, you can see the chain of certificates. At the top is the root, the “Version Class 3 Public Primary Certification Authority – G5”. In the middle is the “Symantec Class 3 Secure Server CA – G4” intermediate signing cert and at the bottom is the blanked out cert for the service we’re trying to access. Assume that blanked out cert is secure and using SHA-256. We turn our attention first to the intermediate signing cert.

Intermediate certificates are used as a stand-in for the root certificate. They’re used as a proxy because we must keep our root certificate behind numerous layers of security, ensuring its keys are inaccessible. However, because the root certificate itself signed the intermediate certificate, the intermediate certificate can be used to sign the blanked out cert in the example and maintain the “Chain of Trust.”

Googling the name “Symantec Class 3 Secure Server CA – G4” very quickly reveals the following link: https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=crosslink&id=info2045 and I’ve screen grabbed the relevant section.

So the good news is this intermediate cert is using SHA-2. We also established that the end user cert is also using SHA-2. However did anyone spot the worrying phrase in that screen grab?

“(under SHA-1 root)”

Gulp.

More digging required. Let’s see what we get … and first thing is Verisign seems to have been purchased by Symantec, because we end up back on the same site again. This time we are confronted with this.

SHA-1 root CA … ah.

So what it appears is happening is that Apple has made a change in iOS 10.3 and macOS 10.12.4 onwards that examines the entire certificate chain of trust and if it finds any SHA-1 based certificates then the OS immediately does not trust any certificate in that chain. That even includes certificates that have been signed in a secure manner. Makes sense, if the root cert is insecure then the rest by extension are potentially compromised too. The chain of trust is working as should be expected.

Now this isn’t a specifically Apple issue. From the articles I’ve linked elsewhere, everyone else in the industry is making this change and some more publicly than others. It won’t be long before every computing platform whether it be Apple or Microsoft or the various Linux’ and especially the mobile platforms will be effected by this and not in a good way. I do need to explicitly point out that at time of writing, this is only applying to publicly available certificate authorities. Internal enterprise certificates are safe … for now 😉

The Aftermath

Lots of work basically. If you have public services (websites, vpn, wifi etc) that rely on public cert authorities then you have no choice but to upgrade the entire CA chain to use the SHA-2 standard. It’s reasonably well known that at some point soon SHA-1 will end up marked as insecure and OS’ will stop prompting to allow trust. They simply won’t trust it at all. So as I said at the beginning:

If you are running certificates from a public source (such as Symantec, Entrust, GoDaddy (really?) ) that use SHA-1 at any point in their chain of trust, then you should replace them with SHA-2 ones now.