November 18, 2016 10:00 am

SHA-1 deprecation countdown

The SHA-1 hash algorithm is no longer secure. Weaknesses in SHA-1 could allow an attacker to spoof content, execute phishing attacks, or perform man-in-the-middle attacks when browsing the web. Microsoft, in collaboration with other members of the industry, is working to phase out SHA-1. We have outlined our timeline for SHA-1 deprecation in earlier posts, most recently in April. This post is to clarify some of our most commonly asked questions, and to help you test ahead of time.

Starting on February 14th, 2017, Microsoft Edge and Internet Explorer 11 will prevent sites that are protected with a SHA-1 certificate from loading and will display an invalid certificate warning. Though we strongly discourage it, users will have the option to ignore the error and continue to the website.

This will only impact SHA-1 certificates that chain to a Microsoft Trusted Root CA. Manually-installed enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend for all customers to quickly migrate to SHA-256.

Additional information on Microsoft’s overall SHA-1 deprecation plans can be found on TechNet.

Screen capture showing Microsoft Edge when browsing to a site protected with a SHA-1 certificate

Microsoft Edge will display an invalid certificate warning when browsing to a site protected with a SHA-1 certificate

Frequently asked questions

How can I test if my site will be impacted?

By installing the latest November 2016 Windows Updates, including the November 2016 Preview of Monthly Quality Rollups for Windows 7/Windows 8.1, you can test how your site will be impacted by the February 2017 update.  Please note that the Windows 7 and Windows 8.1 updates are currently offered as Optional Updates on Windows Update, and are expected to be promoted to Recommended Updates on December 13th, 2017. You can test by running the following commands from an Administrator Command Prompt:

First, create a logging directory and grant universal access:

set LogDir=C:\Log
mkdir %LogDir%
icacls %LogDir% /grant *S-1-15-2-1:(OI)(CI)(F)
icacls %LogDir% /grant *S-1-1-0:(OI)(CI)(F)
icacls %LogDir% /grant *S-1-5-12:(OI)(CI)(F)
icacls %LogDir% /setintegritylevel L

Next, enable certificate logging and SHA-1 blocking:

Certutil -setreg chain\WeakSignatureLogDir %LogDir%
Certutil -setreg chain\WeakSha1ThirdPartyFlags 0x80040004

Important: Use the following commands to remove the settings after you have completed your testing.

Certutil -delreg chain\WeakSha1ThirdPartyFlags
Certutil -delreg chain\WeakSignatureLogDir

How will other Windows applications and older versions of Internet Explorer be impacted?

Third party Windows applications that use the Windows cryptographic API set and older versions of Internet Explorer will not be impacted by the February 2017 changes by-default.

How will SHA-1 client authentication certificates be impacted?

The February 2017 update will not prevent a client using a SHA-1 signed certificate from being used in client authentication.

What about cross-signed certificates?

Windows will only check if the thumbprint of the root certificate is in the Microsoft Trusted Root Certificate Program. A certificate cross-signed with a Microsoft Trusted Root that chains to an enterprise/self-signed root would not be impacted by the changes planned for February 2017.

― Alec Oot, Senior Program Manager
― Jody Cloutier, Senior Program Manager

Updated November 18, 2016 10:35 am

Join the conversation

  1. This is ridiculous that Microsoft Edge still does not allow to view full details of HTTPS website certificate (like IE and all other web browsers do)!

    • We hear the feedback loud and clear and this is something we’re looking at – in the meantime, the best way to share your feedback is via the Feedback Hub app in Windows.

  2. Thanks for the details on this important subject. However, I suspect some details are missing. For example, once we enable logging and SHA-1 blocking, what next? I suspect I should open the web sites with HTTPS, ensure they’re not blocked, and read the logs – right? But in so doing I don’t see any logs. And should the logging and SHA-1 blocking be done on the server side or client (remote) side?

    Also, certutil says the certsvc service should be restarted but I can’t find any such service. That might be why I’m not finding any logging.

    Thanks.

    • Hi Paul,

      The WeakSha1ThirdPartyFlags option suggested above (0x80040004) should be used to configure a client to distrust SHA-1 certificates that chain to a Microsoft Trusted Root CA. After you set this flag and restart Microsoft Edge or Explorer, you can browse the web and you should see SHA-1 certificates blocked in the way that is described above. To give additional details, this option specifically configures the following flags:

      CERT_CHAIN_DISABLE_OPT_IN_SERVER_AUTH_WEAK_FLAG (0x00040000) – This is the flag that previews the February 2017 behavior. It will instruct Windows crypto to distrust SHA-1 certificates for applications that opt-in for this behavior (including Microsoft Edge and Internet Explorer). The update that we will release in February 2017 will enable this flag by-default.
      CERT_CHAIN_ENABLE_WEAK_LOGGING_FLAG (0x00000004) – This flag will trigger Windows to log SHA-1 certificates for all applications in the directory specified on the client. This is an optional flag and intended to help you troubleshoot, and is not strictly required to preview the February 2017 behavior.

      After setting this flag, I recommend that you browse with one of many SSL/TLS testing sites that is protected by a SHA-1 site for testing purposes. If the site is not blocked, please make sure that you have installed the latest updates (including the November 2016 Preview of Monthly Quality Rollups, or later).