SHA-1 Sunsetting, Google, and Your Next Steps.
What is happening, and what was happening?
The SSL Industry and the CA/B Forum have planned for the “sunsetting”(depreciation) of the SHA-1 signing algorithm for quite some time. However, their plan was mainly formed around Microsoft’s desires to phase it out in 2017, alongside the end-of-life for Windows XP. This was widely understood to be the approved plan for CAs to follow, and the preparation for moving from SHA-1 to its successor, SHA-2, wouldn’t be necessary for many months from now.
However, Google recently made an announcement, in stark contrast to Microsoft’s plan, that they are implementing their own SHA-1 sunsetting timeline, which will begin on September 26th 2014.
This timeline has three distinct stages, which will result in degraded visual indicators in Google Chrome (padlock, green-bar) for SHA-1 signed certificates meeting specific criteria (this is discussed in the section “What certificates are affected?” below).
This means it is now necessary to educate and assist our customers on how to make the transition away from SHA-1.
First, let’s understand what SHA-1 does. Both SHA-1 and its successor, SHA-2, are specific types of signing algorithms. Signing algorithms are used as part of the identity validation role that SSL certificates perform. They are mathematical functions (referred to as a “hash”) which, when performed, should calculate a persistent and unique value for each file. So, for instance, the Word doc this text is stored in has a unique SHA-1 hash value. If I change a single part of this file – add an extra period somewhere, change a letter, etc. – it will produce a different SHA-1 hash value.
When a certificate is downloaded from a server to the client’s browser, a hash is taken of it. The type of hash taken (SHA-1, SHA-2, MD5, etc.) depends on how the certificate is signed. The hash calculated by the browser is compared to the hash value provided by the server, which has been verified by the Certificate Authority (CA) at the time of issuance. If they match, the identity of the certificate and server are verified.
Accurate identification is very important for the CA Trust Model, and SHA-1 can no longer perform this. This is because SHA-1 is vulnerable to “collisions.” This is when two different files produce the same hash value. This would allow someone to “forge” a certificate, and have a client’s browser falsely verify a server’s identity. This compromises a user’s trust of the internet and browsers, and is precisely the reason that Google wants to get rid of SHA-1 quickly.
Google is amongst many parties who believe that “forging” a certificate signed by a SHA-1 hash is becoming easy. They also feel that in previous instances when CAs needed to transition to a new technology (in the switch from MD5 to SHA-1, and from 1024- to 2048-bit certificates) they did so slowly and poorly. For this reason, they are forcing the sunsetting of SHA-1 (and therefore, an upgrade to SHA-2) early.
Eric Mill, a software engineer, has written an excellent post describing the entire situation in very common-sense terms. His post is very approachable by those who aren’t very technical and we highly recommended it as additional reading:
When is this happening?
Google’s policy involves three distinct steps, the first beginning on September 26th. On this date, only customers with SHA-1 signed certificates expiring in 2017 are affected. However, the amount of affected certificates will expand in November, and again in Q1 2015. The full details on what certificates are affected is in the below section, “The Nitty Gritty.”
What certificates are affected?
Certificates are affected if they meet the any of the following criteria:
- All certificates from the RapidSSL or QuickSSL family issued before September 15th, 2014 and expiring after January 31st, 2016 (They are signed by a SHA-1 Intermediate).
- If they are signed with SHA-1 and expire after January 1st, 2016.
- They have an Intermediate Certificate Chain that are SHA-1 signed certificates.
To understand the exact certificates affected, please see the below section which gives explicit detail.
The Nitty Gritty1
On September 26th, 2014:
SHA-1 signed certificates expiring on or after January 1st, 2017 will be treated as “secure, but with minor errors” and will receive the yellow triangle padlock.
On November 7th, 2014:
SHA-1 signed certificates expiring on or after June 1st, 2016 to December 31st, 2016 are treated as above. Certificates expiring after January 1st, 2017 are treated as “neutral, lacking security.” These certificates will receive a blank page icon, as seen with HTTP sessions.
In Q1 2015:
SHA-1 signed certificates expiring on or after January 1st, 2016 to December 31st, 2016 will continue to be treated as “secure, but with minor errors.”
SHA-1 signed certificates that expire on or after January 1st, 2017 are treated as “affirmatively insecure.” This will be identified by the red “X”.
How is the problem solved?
Affected certificates can be fixed by reissuing (There are no situations where anything other than a reissue is needed). Our partner CAs have sped up their implementation of SHA-2 compatible infrastructure due to Google’s new policy.
Symantec has officially confirmed that their full product line will have a fully SHA-2 compatible chain “on September 15, 2014.”2 Comodo’s full product line is already ready for the SHA-2 transition and by default are now being issued as SHA-2. Certum has announced they will make SHA-2 Certificates available “this year”, specifically they are targeting October. This deployment date for Certum may be delayed, so we know they will not be ready for Phase 1 of Google’s rollout, but perhaps by Phase 2. We will certainly keep our customers and partners informed as soon as we know more.
What do I need to do?
If your certificate is SHA-1, you need to perform the following:
a) A reissue of your certificate to SHA-2
In addition to the step above, you probably also need to:
b) Install newly available SHA-2 Intermediate Certificates.
Please see below to determine what is necessary for your situation.
It will be necessary for you to perform a) if you have a SHA-1 certificate (as determined by your selection during the enrollment process). This can affect certificates from any of our providers, and is more likely to affect older certificates.
If your certificate was SHA-1, most likely it was also signed by a SHA-1 Intermediate. When you reissue the certificate it will be signed by the SHA-2 Intermediate, which must also be installed to your server. These will either be provided or linked to you when you receive your new certificate.
How can I tell if my certificates are effected?
You can use this SHA checker tool to test if your certificates are affected. You can also come to our 24/7 support to make sure, but please do use the checking tool first.
Q & A
What products have compatibility issues with this switch?
Symantec, GeoTrust, Thawte, and RapidSSL:
These CAs will make a SHA-2 Intermediate Certificates available for their products on September 15th. At this time, their full catalog will have fully compatible subscriber certificates and certificate chains. Customers using the old Intermediate certificates will need to reissue so their certificates can be signed by the new Intermediates.
These CAs will make a SHA-2 Intermediate Certificates available for their products on September 15th. At this time, their full catalog will have fully compatible subscriber certificates and certificate chains. Customers using the old Intermediate certificates will need to reissue so their certificates can be signed by the new Intermediates.3
What platforms have compatibility issues with this switch?
The biggest issue will be Windows XP and Windows Server 2003. As documented by RapidSSL4, if the user is running these platforms with the correct patches, they will have compatibility with SHA-2. For Windows XP they will need to install Service Pack 3 (this will solve most issues). For Windows Server 2003 and for edge cases in Windows XP please see RapidSSL’s documentation.3
However the SHA-2 digital signature is purely for identity validation. So, this is only for establishing the “visual trust indicators”. Note that even without properly patched Windows platforms, the HTTPS session can still be initiated so that user information is still protected.
There will also be issues with other specific hardware, such as enterprise or legacy servers/networking hardware, game consoles, older/niche mobile phones, etc.
The following matrix notes when major platforms began supporting SHA-25
|Minimum OS Version|
|Windows||XP if patched with SP3 (see above)|
|Windows Server||2003 if patched (see above)|
|Apple OS X||10.5+|
|Chrome OS||Since release|
What browsers have compatibility issues with this switch?
|Internet Explorer||Windows XP||Windows Vista||Windows 7|
|Version 7 and higher||Version 7-8||Versions 8-9||Versions 8-11|
|Version 6||Only with SP3||N/A||N/A|
What if I had a SHA-2 subscriber certificate issued before the SHA-2 roots were available (The certificate is signed with a SHA-1 Intermediate and has a “mixed-chain”?
You need to reissue your certificate and you need to update the intermediates to the new SHA-2 versions.
5. Specifically, the hash function SHA-256
What if the customer has a SHA-1 subscriber certificate?
They need to reissue their certificate and choose “SHA-2” or “SHA-256′ during enrollment. They also need to make sure they download and install the new SHA-2 intermediates. Please note that the certificate’s signing algorithm is determined solely during the generation process; it is not related to the CSR.
Does the customer need to generate a new “SHA-2” CSR?
No. The signing algorithm is decided solely by what is selected in the enrollment process. It is possible on certain platforms to create a CSR that requests a signing algorithm. However with our enrollment method this is entirely ignored. Only what the customer selects during enrollment is considered.
Obviously, if the customer does not have their old CSR, they will need to generate a new one, but they can use the same method they used previously with no need to specify anything with SHA-2
Should I use something more secure than SHA-2?
No. At this time, there is no evidence that SHA-2 faces the same issues as SHA-1. This does not mean it won’t in the future. To think about this topic more broadly, all signing algorithms are mathematical functions. They have a specific purpose and theoretical capabilities. However, in reality, they may not always function as designed. In the case of SHA-1, it’s been proven by many researchers to be flawed. SHA-2 has not yet shown the same flaws.
SHA-2 is also significantly more complex than SHA-1 so it is also much more secure from brute-force attacks. There is a SHA-3 algorithm however it is not finalized nor practical to use in a live environment.