Retiring SHA1 - What is Your Next Step?
All You Need To Know About the Move to SHA-2 Encryption
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 partners and customers on how to make the transition away from SHA-1.
Why?
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.
Further Reading
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: https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1
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.
1 The majority of this section comes from Google's official announcement: http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
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.
2 Symantec's full statement: "Google has announced that it plans to phase out SHA-1 support via degraded visual indicators. The plan is for that to happen in the upcoming Chrome 39 release on September 26, 2014. Google's plan is still subject to change. To help partners respond to this change, Symantec has accelerated its plan to offer SHA-2 end-entity certs chaining to SHA-2 intermediates. We expect these to be available for testing (by API-integrated partners) in our pre-production environment on September 12, 2014, and generally available on September 15, 2014."
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.
