November 4, 2015 10:00 am

SHA-1 Deprecation Update

By / Program Manager, Microsoft Edge

Ed note – please see “An update to our SHA-1 deprecation roadmap” for the most recent details on this topic.

In a previous update on TechNet, we announced that Windows will block SHA-1 signed TLS certificates starting on January 1, 2017. In light of recent advances in attacks on the SHA-1 algorithm, we are now considering an accelerated timeline to deprecate SHA-1 signed TLS certificates as early as June 2016.

Mozilla recently announced a similar intent on the Mozilla Security Blog. We will continue to coordinate with other browser vendors to evaluate the impact of this timeline based on telemetry and current projections for feasibility of SHA-1 collisions.

For more details on our schedule, please see Windows Enforcement of Authenticode Code Signing and Timestamping on Technet, or reach out to us on Twitter or in the comments below.

– Kyle Pflug, Program Manager, Microsoft Edge

Updated June 9, 2016 11:30 am

Join the conversation

  1. The text in the target link is pretty confusing– the code file hash isn’t generated by a CA, and it’s not a “certificate”. “Code signature File Hashes: Microsoft does not require that CAs move to using SHA-2. Windows will also not enforce policies on these certificates. If pre-image attacks on SHA1 become feasible we will reevaluate how the system trusts these certificates.” Can you help get this cleared up? Thanks!

    When will Windows (all versions?) will stop accepting MD5 as a valid hash algorithm for Authenticode signatures?

  2. Sounds good, but as a software developer I think Microsoft needs to specifically address these two issues:

    – Exceptionally, do a Windows Update for Windows XP, Windows Server 2003 and Windows Vista, to make sure that they support both SHA-256 signatures and the related RFC timestamping mechanism (which AFAIK is required for the new signatures, but not supported by those versions of Windows). This is a major reason why certification authorities, under pressure from corporate customers, continue with their SHA-1 offerings, and why developers keep sticking to SHA-1.

    – Make sure that your code signing tools support the dual signing (SHA-1 and SHA-256) and timestamping of not just .exe files, but also of .msi installer files. This seems to currently be missing.

    I’ve been encouraging fellow developers to dual sign for a while, but the above are showstoppers.

  3. These are good news, actually! Btw, it would be great to disable SSLv3 by default in Microsoft IIS as well, or at least to warn users that they are using not really secure SSL configuration by default.
    I would also recommend everyone, before deploying an SSL/TLS website, to check the webserver configuration for possible threats and weaknesses (like POODLE, BEAST, etc.) and see if it is NIST/PCI compliant. You can use this free SSL scanner to verify security of your website.

  4. I think that pulling in this date will create chaos for some large enterprises who are already scrambling to phase out SHA-1 by the end of 2016. They had been counting on using all of 2016 to complete their migration. It wouldn’t just be an inconvenience – it would make an already-difficult situation nearly impossible.

    And I’ll point out that Mozilla is considering the same thing but with a different date – July 1, 2016. Would you at least consider collaborating with other browser vendors to agree on the same date?

  5. While it’s good to be proactive and long-sighted given how long-lived and persistent crypto algorithms can be, I can’t help but feel that some of the panic is not rational. Advance in free collision attack doesn’t necessarily lead to practical second pre-image attacks which is what matters for certificates.

  6. A liitle late to reply, but I’ve we’ve come across an issue with the SHA1 deprecation and cab files.

    In testing we’ve found that existing SHA1 signed cab files used for installing an ActiveX component via IE fail to install immediately post the deprecation date (by adjusting the date forward in the registry) even though the cab signature timestamp predates the (moved) deprecation date. Win 10 doesn’t fail, but Win 7, Win 8.1, Server 2K12 and Server 2K12 R2 all fail in our tests.

    This seems at odds with the deprecation notice that says signatures timestamped before the deprecation date will be valid until 2020.

    Has anyone else run into this issue?

  7. The notification is placed in the last place where affected developers may look into it, web browser blog.
    I wish beside issuing this silly upgrade to deprecate certificates you will also update SmartScreen UI in IE and Edge to tell what is going on with certificate to give a clue what is happening.
    Is is hard to add a message that this file is using outdated sha1 algorithm and link to this or similar article? This would be a user friendly. Current implementation is leaving developers in desperate eternity.

  8. Thanks for the update. I would like to know if IE browser will reject SHA1 Client certificates issued by private CA. These certificates are used by my customers to login to my site. A response on this would be very much appreciated.