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.
Today
February 14, 2017
TLS Server-Authentication Certificates
No lock icon Microsoft Edge and Internet Explorer 11
Invalid Certificate
Code Signing Certificates
Unaffected
Timestamping Certificates
S/MIME Certificates
OCSP and CRL Signing Certificates
OCSP Signatures
OCSP Responses
CRL Signatures
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:
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
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 http://aka.ms/sha2
May be being dumb but certutil -setreg chain\Default\WeakSha1ThirdPartyFlags 0x80800000 on Win 7 (32-bit, no SP. Running in CMD with Run As Administrator ) comes up with the errors :
CertUtil: -setreg command FAILED: 0x80070002 (WIN32: 2)
CertUtil: The system cannot find the file specified.
This text is pretty confusing: “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.”
The Authenticode file hash isn’t generated by a CA, and the signature is not a “certificate”.
What about catalog files for drivers? win7 does not accept SHA-2 Authenticode certificates, Win8+ does. This is the reason why we use our certificate from early 2015 issed with SHA-1.
Can catalog files be signed with two certificates?
The increase in priority sounds good, but as a software developer I think Microsoft needs to specifically address these two issues:
1) Exceptionally, push a Windows Update for Windows XP SP3, Windows Server 2003 SP2 and Windows Vista, to make sure that they support both SHA-2 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.
2) Make sure that your code signing tools support the dual signing (SHA-1 and SHA-2) and timestamping of not just .exe files, but also of .msi installer files. Dual signing support for several signable file types seems to still be lacking.
I've been encouraging fellow developers to dual sign for a while, but the above are showstoppers.
I think the fact that they aren't for even Vista is why they still allow SHA1 code signing certs to be issued.
I'm trying to make sense of the nouns used in the first paragraph.
When you say "timestamp certificate or the certificate's signature hash" what exactly does "certificate's signature hash" mean? And what does "signature hash" mean in the next sentence? It's confusing because there are two certificates in that picture: the one that made the main signature, and the other that made the timestamp signature. When there are two certificates, I'm not sure which one you are talking about.
When I sign a file with a timestamp, a hashing algorithm is used in several places:
1) Main digest algorithm, which is shown in the "Digital Signature Details" window in the "Digest algorithm" box.
2) Main certificate signature hash algorithm, which is shown in the "Certificate" window in the "Signature hash algorithm box".
3) The signature hash algorithm of certificates in the main certificate's chain of trust. Usually the same as #2.
4) Timestamp digest algorithm, which is shown in the "Digital Signature Details" window for the timestamp signature, in the "Digest algorithm" box.
5) Timestamp certificate signature hash algorithm.
6) The signature hash algorithm of certificates in the timestamp signature's chain of trust.
The first sentence of your first paragraph is: "Effective January 1, 2016, Windows (version 7 and higher) and Windows Server will no longer trust any code that is signed with a SHA-1 code signing certificate and that contains a timestamp value greater than January 1, 2016." So I think you are talking about #2 in that sentence, right?
Then in the second sentence you are saying the restriction will NOT apply to the "timestamp certificate" (#5) or the "certificate's signature hash" until 2017. So what does the "certificate's signature hash" actually mean in that second sentence? You already used other phrases to describe #2 and #5, so the phrase "certificate's signature hash" has got to be #1, #3, #4, or #6, right? Which one is it?
Basically, I am trying to figure out how long your advice to use a SHA-1 file hash and a SHA-2 code-signing certificate will actually work. If it's going to stop working on January 2017, I'd like to know that ASAP. Thanks!
Please give the answer to the following problem.
1.Apply the Updated Program for Win7x86 (286966/3033929).
2.In the Command Prompt on the Window7x86, input the command below:
・certutil -setreg chain\Default\WeakSha1ThirdPartyFlags 0x80800000
・certutil -setreg chain\Default\ WeakSha1ThirdPartyAfterTime @11/9/2015
3.According to the information
（social.technet.microsoft.com/.../32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx）,
I have signed exe file(FileList.exe) with a time stamp with the
11/10/2015, we run the exe file on the Win7x86.
(See attached file: FileList.exe)
As a result, the blocked dialog does not appear.
I can not confirm whether it is blocked
Please tell me how to confirm whether it was blocked?
Thankyou
If I enforce the policy and download the sha1-signed exe via IE11, I see a red warning dialog in IE right after the download that says "file may be invalid or corrupt". Apart from that I don't see any issues. I'm still able to run my exe normally. I'm not sure if this is the expected behavior or not.
I don't see this warning when downloading a sha256-signed exe.
Will this windows enforcement affect the 802.1x process, when we use workstation certificates based on the SHA-1 algorithm?
How does this policy affect files that have been signed by Microsoft?