SHA1 deprecation: what you need to know

The news is that SHA1, a very popular hashing function, is on the way out. Strictly speaking, this development is not new. The first signs of weaknesses in SHA1 appeared (almost) ten years ago. In 2012, some calculations showed how breaking SHA1 is becoming feasible for those who can afford it. In November 2013, Microsoft announced that they wouldn't be accepting SHA1 certificates after 2016.

However, we're in a bit of a panic now because Google followed up to say that they will soon start penalising sites that use SHA1 certificates that expire during 2016 and after. This is a major policy change that requires immediate action—according to SSL Pulse, only 15% sites use SHA256 certificates in September 2014.

What you should do

Before this most recent development, the advice was very simple: don't use SHA1 certificates past 2016. Google's decision complicates things: now it's no longer safe to use SHA1 (with Google Chrome) even during 2016. For some sites there won't be a satisfactory outcome no matter what they do: if they want to maintain an error-free presence with Chrome they might need to cut off some older clients. I'll detail these problems later in this post.

Here's what I recommend:

1. Read the recent announcement from Google to understand how the changes will be introduced. Within months, certificates that expire after 2016 will be affected. Relatively soon thereafter, further changes will be introduced that will impact the certificates that expire during 2016.

2. Ensure new certificate and their chains use SHA256; this is critical—if your new certificates are not guaranteed to be SHA256 then all your other efforts will be pointless. If you get this right, all SHA1 certificates that expire by the end of 2015 will be guaranteed to be ready for 2016 without further effort.

   It's also necessary to check that the entire certificate chain is free of SHA1. It's not common, but there are cases where the leaf uses SHA256 but one of the intermediates uses SHA1. Don't worry if the root certificate uses SHA1; signatures on roots are not used (and Chrome won't warn about them).

   Companies that use centralized certificate procurement should find this step straightforward. For others, well, perhaps this is a good opportunity to centralise further certificate issuance.

3. Inventory your existing certificates; this might be tricky, depending on your environment. Automated scanning is not only easy to do once, but can also be repeated regularly to ensure new SHA1 certificates are not introduced. There are companies that offer products for this; for example one of the QualysGuard modules does this automatically after scanning the entire company network.

4. Replace SHA1 certificates that expire after 2015; start with those used on your most important sites and those that expire after 2016. Those will be the worst affected by the proposed changes and might stop working in 2017. Then work your way back to replace the remaining certificates. This step is time consuming but shouldn't involve further direct costs because most CAs will reissue certificates for free. However, there are some special cases you might wish to consider:

   • Older server platforms might not be able to support SHA256 certificates. For example, that's the case with Windows Server 2003. Thus, upgrading to a SHA256 certificate might require an upgrade or patching of the underlying platform.

   • Some older clients don't support SHA256. Most general-purpose sites can upgrade to SHA256 and expect the users to upgrade, too, but large sites with diverse user bases might want to preserve SHA1 compatibility for as long as possible. In some cases that will be possible with dual-certificate deployment, described below.

What older clients don't support SHA256

Many older clients don't support SHA256, but the real question is which of those are relevant? The answer will vary depending on the site. For detailed information on client capabilities, head to GlobalSign, which maintains a detailed summary of SHA256 support for a large number of platforms.

On the desktop, Windows XP introduced SHA256 in Service Pack 3. Users running SP2 should be able to upgrade to SP3. Depending on a site's profile, a significant chunk of the user base might be running XP. This operating system is still very popular in China and there is also strong anecdotal evidence that it remains widely used in some large organizations.

Among the mobile platforms, Android added SHA256 support in version 2.3. Earlier versions—still used in large numbers—support only SHA1.

What if you need to support older clients?

Technically, it's possible to have the best of both worlds by providing SHA256 certificates to modern clients and serve SHA1 to those that can't do better. Indeed, there's nothing to say that a site can't use more than one certificate at the same time. This approach is ideal for transitions such as this one. At this time, a site could use two certificates: ECDSA+SHA256 for modern clients and RSA+SHA1 for older clients.

Unfortunately, this feature might not be available for your favourite platform. As far as I am aware, Apache is the only major server to support multiple certificates. If you're running Apache and are willing to play with dual certificate deployment, you're in luck. As for other platforms, CloudFlare and Yahoo have stated that they will add support to Nginx and Apache Traffic server, respectively.

What will SSL Labs do?

We are making some changes to our SHA1 reporting, split into two phases. In the short term, we will:

• Treat SHA1 signatures as weak and warn about them.
• Introduce three new warnings:
  1. To ensure renewal with SHA256 when the current certificate expires, if the server is using SHA1 now and the expiration date is before the end of 2016.
  2. To renew with SHA256 as soon as possible, if the server is using SHA1 now and the certificate expires after 2016.
  3. To renew certificate or fix the chain if the leaf is SHA256 but one of the intermediates is SHA1.
• Stop awarding A+ to sites that use SHA1 certificates.
• Link to this advice for more information.

These changes have already been implemented and deployed on our staging server. They will be migrated to production in the following days. These changes were deployed to production on 16 September. Our second step, which will come some time later, will involve a change to our rating criteria to penalize sites that continue to use SHA1.

Tags