Effective February 14, 2017, Windows (version 7 and higher) and Windows Server will no longer trust new code that is signed with a SHA-1 code signing certificate for Mark-of-the-Web related scenarios (e.g. files containing a digital signature) and that has been time-stamped with a value greater than February 14, 2017. This cut-off date applies to the code-signing certificate itself.
This restriction will not apply to the time-stamp certificate used to time-stamp the code-signing certificate or the certificate’s signature hash (thumbprint) until February 14, 2017. After this time, Windows will treat any code with a SHA-1 time-stamp or SHA-1 signature hash (thumbprint) as if the code did not have a time-stamp signature.
Drivers with signatures verified by Code Integrity are not affected by this change. For more information about how to conform to the latest requirements for driver signing, see the Windows Hardware Certification Blog.
↑ Back to top
Files downloaded through browsers that set the Mark-of-the-Web will go through SmartScreen on Windows 8 and higher systems and files not compliant with policy will run into the following experience:
There are a couple ways to figure out how a particular file is signed. Signatures embedded on a file can be viewed using the Digital Signature tab in file properties or the SDK command-line utility signtool can be used to enumerate the signatures on a file.
Use the following steps to view the signature on a file:
signtool.exe verify /pa /v <foo.exe>>
The signtool invocation will also display the thumbprint of the certificate as the SHA1 hash field. This information can be used in conjunction with certutil to determine the hash algorithm of the code signing certificate. The following command line will dump information about all the certificates used to sign and timestamp the specified file
certutil.exe –dump <foo.exe>
The signature algorithm field will mention the hash algorithm and the public key algorithm used for the certificate.
The items in red are highlighted are marked on the following screenshots. The items of interest for the policy enforced by KB 3123479 are the Signature hash algorithm and Signing time. KB 3123479 requires that any files signed after 1/1/2016 that are being distributed over the internet and maybe downloaded through a browser are signed with a SHA-2 certificate. Here is a simple cheat sheet:
Signature hash algorithm value
Signing time value
Behavior
SHA1
Earlier than 1/1/2016
No signature verification failures due to policy
After 1/1/2016
Signature verification will fail in IE and Edge download checks and SmartScreen’s prompt
SHA2
Any value
Lots of software is distributed through MSIs and we recognize that developers will want to try and maintain as simple a distribution as possible. Given the enforcement matrix in Appendix A, it is possible to ship a single MSI that is appropriately trusted on all down-level editions of Windows by signing the MSI with a SHA-2 code signing certificate while maintaining a SHA-1 file hash.
EXE files can be multiple signed and the modern AppX platform supports SHA-2 signatures. These solutions can provide alternatives for developers looking for cryptographically agile deployment mechanisms.
PE files like EXEs and DLLs can be dual signed. If a single executable needs to work on all Windows systems down to Windows Vista dual signing the file is the best option.
Signtool, a Windows SDK utility, allows developers to perform dual signatures with the aid of the /as option for the sign command. The series of signtool invocations below offer an example of how to perform dual signing for a file:
signtool.exe sign /n <Subject name of SHA-1 certificate> /t <URL to SHA-1 Authenticode timestamp server> /v foo.exe signtool.exe sign /n <Subject name of SHA-2 certificate> /fd sha256 /tr <URL to SHA-2 RFC-3161 timestamp server> /td sha256 /as /v foo.exe
signtool.exe sign /n <Subject name of SHA-1 certificate> /t <URL to SHA-1 Authenticode timestamp server> /v foo.exe
signtool.exe sign /n <Subject name of SHA-2 certificate> /fd sha256 /tr <URL to SHA-2 RFC-3161 timestamp server> /td sha256 /as /v foo.exe
Since the MSI file format does not support dual signing a different approach needs to be used for signing a single MSI to be conformant with the policy down to Windows Vista. The signtool invocation below offers an example of how to handle the SHA-1 code signing certificate requirement. Note that this approach will meet policy only for the code signing certificate requirement being enforced for SHA-1 code signing certificates starting on 1/1/2016.
signtool.exe sign /n <Subject name of SHA-2 certificate> /t <URL to SHA-1 Authenticode timestamp server> /v foo.exe
On Windows 10 and above for certificates with the Must Staple extension, SHA-1 signatures will not be accepted after 1/1/2016
On Windows 10 and above, SHA-1 signatures will not be accepted for any TLS certificate after 2/14/2017
CAs should move to using SHA-2 starting 1/1/2016 for SHA-2 TLS certificates.
CAs should prepare to move to SHA-2 for all TLS certificates by 2/14/2017
(Note: no kernel mode enforcement)
The restriction will use the framework Microsoft published earlier to enforce this restriction. The policy will be applied to Windows 7 and higher systems (and the corresponding Server releases) through a Windows Update.
The following registry settings need to be set to enable the policy. The easiest means of doing so would be to use the inbox certutil tool but it is possible to directly manipulate the registry as well.
Note: For testing performed prior to 1/1/2016 it may be convenient to assign the time to a different earlier value
No – the functionality to enforce this requirement will be added to a future build of Windows 10.
Yes - within the constraints of the enforcement being performed for SHA-1 OCSP signatures. SHA-1 OCSP responses will not be trusted by Windows 10 and higher systems for certificates using the Must Staple extension after January 1, 2016. SHA-1 OCSP responses will not be trusted by Windows 10 and higher systems for all certificates (i.e. certificates without the Must Staple extension) after January 1, 2017.
Back to top
Yes. The following Microsoft partners can provide SHA-256 time-stamping services:
No, the OCSP signature enforcement requirements only apply to TLS certificates.
The policies will be enforced for all the certificates under the root certificate (i.e. the leaf and intermediate certificates)
The deprecation policies will not be targeted at those systems. Those systems however do not have SHA-2 support and no patch is available to add that support either. Developers can use SHA-1 code signing certificates and SHA-1 file hashes to sign their code. SHA-1 timestamps should be used as well.
The policy is aimed at the signature in the response i.e. the Signature member of the OCSP_SIGNATURE_INFO struct in an OCSP_BASIC_SIGNED_RESPONSE_INFO struct. There is no enforcement on content in the OCSP_SIGNED_REQUEST_INFO.
No.
No – the OCSP signature requirements will only be enforced on Windows 10 and higher systems which have full support for handling SHA-2 OCSP responses. TLS servers can get a certificate with the Must Staple extension and will not have any problems with downlevel clients that do not enforce the requirement.
No, the policies will only apply to certificates issued by CAs in the Program.
No. Only certificates that are in the Microsoft Trusted Root Program will be affected by the policies described here.
No – policy on a client Windows machine targeting TLS certificates will not be applied until January 2017
Dual signing a single catalog file is not supported. It is possible to sign the same content with multiple catalogs. Developers with compatibility concerns can catalog sign their content with two catalog files – one with SHA-1 and the other with SHA-2 and ship both catalogs as part of their software package.
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?