SHA-1 is a legacy cryptographic hash that many in the security community believe is no longer secure. Using the SHA-1 hashing algorithm in digital certificates could allow an attacker to spoof content, perform phishing attacks, or perform man-in-the-middle
attacks. Microsoft, in collaboration with other members of the industry, is working to phase out the SHA-1 protocol and to warn consumers of the possible risk when they encounter websites using the SHA-1 protocol.
In 2015, we announced plans to change the way that Windows applications and devices handled SHA-1 certificates. After extensive consultations with members of the industry, we’re adjusting our plan to better align the risk with the experience we want our
customers to have.
These changes will take place in multiple phases and are targeted to certificates that chain to and are trusted as part of the Microsoft Trusted Root Program.
The Plan has three phases. Phases one and two are centered around a browser scenario. Phase one is what we are doing today in Microsoft Edge and Internet Explorer 11. Phase two is what we will do in those browsers beginning in February 2017. Phase three
is our plan beyond February 2017.
February 14, 2017
TLS Server-Authentication Certificates
No lock icon Microsoft Edge and Internet Explorer 11
Code Signing Certificates
OCSP and CRL Signing Certificates
Code Signature File Hashes
Timestamp Signature Hashes
The first phase of our plan is to indicate to users that browse to TLS-secured websites that SHA-1 is less secure than SHA-2. Today, when customers use Microsoft Edge or Internet Explorer 11 to browse to a TLS site that uses a SHA-1 end-entity certificate
or issuing intermediate, customers will notice that the browser no longer displays a lock icon.
On February 14, 2017, Microsoft will release an update to Microsoft Edge and Internet Explorer 11 that will display an Invalid Certificate warning page alerting users that their connection is not secure. Though we do not recommend it, customers have the
option to continue to the website.
February 2017 user experience navigating to a site protected with a SHA-1 certificate
After February 2017, we intend to do more to warn consumers about the risk of downloading software that is signed using a SHA-1 certificate. Our goal is to develop a common, OS-level experience that all applications can use to warn users about weak cryptography
like SHA-1. Long-term, Microsoft intends to distrust SHA-1 throughout Windows in all contexts. Microsoft is closely monitoring the latest research on the feasibility of SHA-1 attacks and will use this to determine complete deprecation timelines.
In February 2017, there will be no impact for roots that are not included in Microsoft Trusted Root Program, such as enterprise or self-signed roots that you’ve chosen to trust.
A cross-certificate signed with for a Microsoft Trusted Root that chains to your own root would not be impacted in February 2017.
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 do this by running the following commands from an Administrator
First Create a logging directory and grant universal access:
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
Enable certificate logging
Certutil -setreg chain\WeakSignatureLogDir %LogDir%
Certutil -setreg chain\WeakSha1ThirdPartyFlags 0x80900008
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.
The February 2017 update will not prevent a client using a SHA-1 signed certificate from being used in client authentication.
Please see Microsoft's whitepaper on SHA1/SHA 2, which is located at