SHA1 Deprecation: What You Need to Know

Ivan Ristic

Last updated on: December 22, 2022

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 we 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.

Show Comments (25)


Your email address will not be published. Required fields are marked *

  1. "At this time, a site could use two certificates: ECDSA+SHA256 for modern clients and RSA+SHA1 for older clients."

    What about Chrome on XP?  It doesn’t support ECDSA+SHA256 certificates, and it will soon complain about RSA+SHA1 certificates.

    Ideally you need to serve an ECDSA+SHA256 cert to modern clients, an RSA+SHA256 cert to Chrome on XP/SP3, and an RSA+SHA1 cert to older clients.

    I think it should be possible to write server-side code to do this once this bug is fixed…

    Issue 409901 – chromium – TLS signature_algorithms lists non-functional algorithms – An open-source project to help m…

  2. Ivan – do we know how IE will be handling sites which still use SHA1 after 2016? This post says that "Microsoft won’t be accepting" – does that mean https request to sites with SHA1 will be refused or will the user be presented with the SSL warning similar to that of a self signed certificate?

    1. @user5309 we don’t know exactly, that’s for Microsoft to decide as the deadline approaches. But I don’t suppose that SHA1 certificates will be treated more harshly than other invalid (e.g., self-signed) certificates.

  3. Dear Ivan,

    A big question is in my mind :-?…. when Microsoft announced that they wouldn’t be accepting SHA1 certificates after 2016, what exactly this mean? You know, we have a lot of trusted certificates in our windows 7 & 8 certificate store! what happens to these certificates? to our OS? should we use patches from Microsoft in 2016 via windows update to replace these certificates? Is this way secure?

    1. Emad, I suspect that such certificates will start to show as untrusted, in the same way self-signed certificates are currently not trusted. I expect that the trusted SHA1 certificates currently in Microsoft’s root store will be upgraded automatically by Microsoft before the deadline.

  4. 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.

    Is there any resources on how to do this?

      1. Ok, I have done exactly like what is shown at the said link:-

        I have two certificates, one is RSA SHA256, another one is EC 384 SHA256.

        The site.

        Everytime I load the said site with Firefox, Opera and Chrome (latest versions for them all), they will default to loading the secure site using the RSA certificate. Only Internet Explorer 11 will load the site using the ECC certificate. Is this expected? How to make those browsers I mentioned to load the site with ECC certificate?

          1. Thanks, it now works. Have to modify Mozilla’s intermediate compatibility list though to look like below:-


  5. "Companies that use centralized certificate procurement should find this step straightforward". I think this very complicated, because you need to re sign the root chain (or generate a new one ?) and then beginning to sign new certificates with SHA256, AND maintain the old hierarchy for some time, if not, you will have to revoke a lot of certificates. How to do that ?

    Just re sign the SubCA and SubSubCA with SHA256 or generate a new hierarchy along with the "old" one ?

  6. Is there a QID that we can use to scan all assets for SHA-1 presence. I am in the process of scoping the change and need to understand the size of the problem.

    1. We have two IGs which provide all of the SSL information, both with supported ciphers and certificates installed. The results of these QIDs can be parsed to gather whatever information supports your specific policy. QID 38116 lists all Cipher information and QID 86002 shows the certificate information.

  7. Sites that hit this issue are still scoring “A” with the SSL checker, despite the fact these sites will show a fairly ugly error (in the URL bar) in many browsers now. Surely any sites hitting this issue should be capped to something far lower than “A”?

    Especially for sites where the cert expires sometime in 2017, so they will being failing in many browsers very shortly.

  8. I am surprised that the “change to our rating criteria to penalize sites that continue to use SHA1.” indicated in your last sentence is still not happening, 2.5 years later, when at the same time my Firefox complains, and even for (intermediate) cert valid until 2019.

  9. Seems like the SHA1 is not an issue at all — nearly 3 years later. My host is not even aware of this but said that they are SHA256 compliant.. but I was recently issued an SHA1 cert and have had zero issues so far.