SHA-1 Sunset: What You Need To Know

(Most recent update: 2014-09-23)

What is SHA-1?

SHA-1 is a cryptographic hash algorithm which is currently widely used in the production of digital certificates. It's been used since around 2008, replacing the older MD5 algorithm.

Why do I care about SHA-1?

In recent years it has been suggested that the SHA-1 algorithm is less secure than it needs to be, going forward, to protect against attempts to change or duplicate valid digital certificates.

Microsoft had already announced in 2013 that they will be ceasing support for SHA-1 certificates for all Windows users as of 1st January 2017. Plans were already in place to manage reissues of certificates that would have been affected by this deadline, nearer the point where it would have become an issue.

What's changed?

Google have decided that they would prefer to cease support for SHA-1 certificates sooner than would have been indicated by the schedule driven by Microsoft's deadlines. They intend to start making provisions to cease support as of the next release of Chrome, release 39, which will be released in its preliminary version on September 26th 2014 -- although most people will not start to see changes until the stable version of Chrome 39 is released, most likely in November.

What will we be using instead?

Instead of SHA-1, certificates will be signed using the SHA-2 algorithm (also known as SHA256, because the certificates will be using a 256-bit hash). There will also be changes to the intermediate certificates which go with your issued certificates.

What will Chrome users see?

This depends on the version of Chrome and the expiry date of the certificate concerned.

As of the issue of the stable version of Chrome 39 (likely to be around mid-November), Chrome users will start to see a different indication of security for sites which are using a certificate signed with the SHA-1 algorithm, and where that certificate expires after 31st December 2016. In the following release of Chrome, release 40, those changes will extend to SHA-1 certificates which expire later than 1st June 2016 (and certificates expiring after 31st December 2016 will be shown as even less secure), and finally in release 41 the changes will extend to SHA-1 certificates which expire later than 31st December 2015. Google's explanatory page has examples of what will be seen in each version.

Versions of Chrome have a 'branch point' before the stable version is released. The branch point for Chrome 39 is on 26th September 2014; the branch point for Chrome 40 is on 7th November 2014, and the branch point for Chrome 41 is not yet fixed but will be in Q1 of 2015. In general, the release date for the stable version is 6-8 weeks after its branch point; the stable version of Chrome 39 is therefore likely to be released during November, while the stable version for Chrome 40 will not be released until "after the holiday season". So those people using unstable versions of Chrome will be likely to see changes earlier than most, but the majority of users will not see the changes until the stable version containing the changes is released.

What do I need to do?

If your certificate expires prior to 31st December 2015: you do not need to do anything at this stage. We will be happy to provide you with a reissued certificate signed with the SHA-2 algorithm if you prefer, but it is not necessary at this time and your site's display in Chrome will not change.

If your certificate is used for a server-to-server application, rather than in a situation where browsers will interact with it: you will not need to replace the certificate at this stage unless you want to. You may wish to consider whether the deadline for Windows support of SHA-1 certificates (1/1/2017) will be relevant to you.

If your certificate expires after 31st December 2015 and is used in a browser-facing situation: you will need to have your certificate reissued for continued support by Chrome.

I have already requested a SHA-2 certificate, do I need to do anything else?

If you requested a SHA-2 certificate prior to 15th September 2014, and that certificate expires after 31st December 2015, then unfortunately you will also need to have your certificate reissued. While your certificate is SHA-2, the intermediate certificates in its certificate chain will still be SHA-1 at this point and this will cause Chrome to treat it in the same manner as an SHA-1 certificate (see "What about intermediate certificates?", below)

Will this cost me anything?

No; reissues of Symantec, Thawte, Geotrust, RapidSSL and QuickSSL certificates are always free.

Will my old certificate stop working if I request a reissue?

It will not be revoked by Symantec unless you specifically request that. Some server software cannot support having more than one certificate or certificate request in place at a given time -- so, for instance, it is not possible to request a new certificate without removing the old certificate first. In such cases we suggest that you generate the new certificate request on a different server, if one is available, and import the replacement certificate onto the right server when it has been issued.

Will my server support SHA-2? Will my users' browsers support SHA-2?

See Where can I find out more? below for a full list, but most servers and browsers support SHA-2. Notable exceptions:

How do I request a reissue?

The reissue process for requesting an SHA-2 certificate is no different to the process for requesting a reissue in any other circumstances. Typically you will need to provide us with a new CSR (certificate signing request) and we will request the reissue on your behalf. For domain-validated certificates, a new authorisation email will be sent out. For organisation-validated and extended validation certificates, it's likely that the existing certificate details will be rechecked (possibly depending on how long ago the existing certificate was issued).

Our details have changed since the certificate was issued...

Please get in touch and let us know what has changed; in many circumstances you will still be entitled to a reissue, but this will need to be managed on a case-by-case basis.

What about intermediate certificates?

When you are installing an SHA-2 certificate, to have it be seen as correctly trusted by newer versions of Chrome you will need to install an SHA-2 version of the intermediate certificate which signed your new SHA-2 certificate -- the one immediately above your issued certificate in the certificate's details -- but you will not need to install an SHA-2 version of any other intermediates.

... why's that?

Google's view of SHA-1 certificates is that they will warn Chrome users if the issued (end entity) certificate is signed with the SHA-1 algorithm (and expires after the dates noted above) and if intermediate certificates within the chain of trust are signed with SHA-1.

The slightly confusing aspect here is that different browsers have differing views on what constitutes a "root certificate" and what an "intermediate certificate", depending on what certificates they have embedded within them as 'trusted' certificates.

To take Thawte certificates as an example here: older browsers will have Thawte's Premium Server CA certificate installed as a trusted root certificate. More modern browsers will have both that certificate and also Thawte's Primary Root CA certificate installed. Older browsers see the Primary Root certificate as an intermediate certificate (its name notwithstanding) whereas the modern browsers see it as a root certificate.

Server administrators will still typically want to install the Primary Root certificate on their server as well as the lower-level intermediate which signed the issued certificate (e.g. the "Thawte SSL CA"/"Thawte SSL CA - G2" certificate for a Thawte SSL Web Server certificate or the "Thawte DV SSL CA"/"Thawte DV SSL CA - G2" cert for an SSL123 certificate) so that older browsers will be able to form a complete chain of trust back to the Thawte Premium Server CA certificate. However, Chrome won't treat the Primary Root certificate as an intermediate -- as it's already installed in the browser -- so it does not matter that it is signed using the SHA-1 algorithm.

The situation is analogous for Symantec, Geotrust and RapidSSL.

If you are not sure which intermediates you need to install alongside your reissued certificate, please do ask us -- we will be happy to advise!

What about SHA-2 root certificates?

Although you will see SHA-2 root certificates available from Symantec, Thawte, Geotrust and RapidSSL, these are not ubiquitous within browsers yet and should not be installed unless you have a very specific requirement to do so and are confident that everything interacting with your server will have the correct root already installed. The SHA-2 root certificates do not chain back to an existing, more widely installed root, so they do need to exist within browsers for certificates chaining back to those roots to be trusted.

Where can I find out more?

I'm still confused...

If you purchased your certificate from us here at Herald, we'll be delighted to help -- email or call us on 020 8394 2288. (If you originally purchased your certificate from a different reseller or from Symantec, Thawte, Geotrust or RapidSSL directly, we encourage you to contact them first.)