Deprecation of SHA1 code signing certificates on Windows

Question

EDIT (7/7/2016) - see addition at the end of post

I have been keenly following the issues with regards to Microsoft deprecating the use of SHA1 code-signing certificates for Windows executables (http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx).

We are now into 2016, and as we will need to sign and release code shortly, I am trying to verify that, indeed, without upgrading our code signing certificate to a SHA256 one, we will have problems. However, I seem unable to demonstrate any expected problems.

I have signed some executables (today, in 2016) using the SHA1 certificate and configured AppLocker to run only signed executables (I have verified this - I cannot run unsigned executables). However, I am still freely able to run my newly SHA1-signed executables, and additionally, downloading these files from a web server in IE does not present me with any 'warnings' (as I had expected) - the security scan returns that all is good with the files!

I am running the tests on Windows 7.

What actual problems should I expect to experience?

(in case you are wondering why we don't simply just upgrade to SHA256 anyway - there are multiple reasons: one is bureaucratic, but the other is the fact that we also sign VBS scripts which currently do not support dual signing).

EDIT (7/7/2016) Well, it seems that Microsoft has finally put out an update to IE and Edge that warns you if you download an executable which is signed only with a SHA-1 certificate! Basically, with IE 11.0.30 or later, if you download an executable which was signed with a SHA-1 (but not SHA-256) cert AFTER 1/1/2016, then you will see one of the following warnings:

I guess Microsoft is finally getting in with the warnings in preparation for the 1/1/2017 cut-off. It's important to note that for the moment, apart from these warnings, there are no other changes - the files still execute without problems, and of course, downloading them in other browsers do not cause problems.

Answer 1

I've now found an example of an actual download that was signed using an SHA-1 certificate after 1/1/2016. I downloaded KeePass 2.31 using Edge on Windows 10.

Edge tells me that "The signature of this file is corrupt or invalid."

If I right-click and select "run anyway", or double-click the file in Windows Explorer, SmartScreen blocks the file:

Ticking the checkbox and clicking Run Anyway allows the file to run normally. The UAC warning then shows the name of the publisher like it does with a properly signed executable.

Clicking "Run Anyway" when SmartScreen blocks the file removes the "Mark of the web" from the file. Double-clicking the file a second time in Windows Explorer no longer blocks the file.

The Digital Signature Details dialog in Windows Explorer also says the signature is OK. It does this even when the file still has the "mark of the web" (i.e. before using the Run Anyway button in the SmartScreen filter):

The file actually has dual signatures. The first uses SHA-1 for the signature and the second uses SHA-256 for the signature. But critically, both were made using an SHA-1 certificate. That is what Windows 7 and later find fault with for downloaded files. Also, both signatures are timestamped with SHA-1. Windows 10 will have a problem with that for downloaded files starting 1/1/2017.

It seems that the Digital Signatures Details dialog does not take into account whether a file has the "mark of the web". It says "this digital signature is OK" for both the signatures on this file. So to really test whether your files are properly signed, you need to download them from your website like your customers would.

Testing the same download in a virtual machine snapshot of the original Windows 10 that hasn't been updated since August and another snapshot of the 1511 release that hasn't been updated since November produces no warnings. If I then have the 1511 VM check for and install updates until it says it's up to date, then I do get the warnings shown above. I did note in my previous answer that the SHA-1 deprecation is pushed out through Windows Update. So it looks like this is a very recent update, perhaps a post-1/1/16 update. Make sure your PC has all the latest security updates before testing your download.

Answer 2

This is more of an extended comment/fact-finding entry. Not a fully fledged answer in itself.

I don't get it either. It is pretty confusing. But I don't feel so bad not understanding that, because Eric Lawrence is confused by that, too. He used to be an Internet Explorer developer but now works on Google Chrome. And he knows his way around certificates. (So if he ain't getting it, then I'm inclined to say that it really IS confusing.) (And he also is on StackExchange.)

1. See his comments here:

   https://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/ (Archived here.)

   Also noteworthy: This gem here:

   Eric Lawrence
   The KB you link says there’s no plans to deprecate MD5-based Authenticode signatures (the hash on the code, not the certificate). That seems… irresponsible.

   Scary. Unfortunately there is no Microsoft reply to that comment.

2. And he has left another comment on the the TechNet Wiki site: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx (Archived here.)

   EricLaw [ex-MSFT] 4 Nov 2015 9:23 AM
   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”.

And again: No answer from Microsoft to that. And his is not the only comment voicing confusion.

3. Play with the system clock? If you want to reproduce failure, you might try the steps "Graham Bloice" lists on the TechNet Post:

   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.

Again: No answer from Microsoft to that.

Further reading

• In depth blog post about AuthentiCode: 2014-09-04, Eric Lawrence, MSDN Blogs, Caveats for Authenticode Code Signing

• 2015-12-28, @EricLaw, https://twitter.com/ericlaw/status/68148757822312448189

• Related question: 2012-09-20, Code signing with MD5 on Windows 8

• Didier Stevens, 2015-12-29, SHA256 Code Signing and Microsoft (Archived here.)
  This clears it up significantly:

  First of all, the loss of trust will not happen for all executables with a sha-1 signature. It will only happen with executables with a “Mark of the Web” attribute and without a timestamp or a timestamp after 1/1/2016.

Answer 3

There are 3 digests in a timestamped Authenticode signature that you have control over.

1. The digest of your certificate. A recently purchased certificate will use SHA-256. Most CAs switched to issuing SHA-256 certificates during 2014. They only provide SHA-1 certificates on special request. A quick way to check your certificate is to right-click on an .exe you've signed with it in Explorer and then go into Digital Signatures tab, Details button, View Certificate button, Details tab. The signature has algorithm should be "sha256". Windows XP SP3 is the oldest Windows version that supports SHA-256 certificates. The policy as stated on the document you linked is "Windows [7 and later] trusts SHA1 (if timestamped prior to 1/1/2016) and SHA-2 (any timestamp) for Mark of the Web files."

2. The digest of the signature itself. You can check existing signatures on the Digital Signatures tab. Windows 7 and later show the digest algorithm directly. On any version of Windows you can click the Details button, Advanced tab to check the digest algorithm. When using signtool.exe, this can be set to SHA-256 with the /fd sha256 argument. Windows 7 is the oldest version of Windows that supports SHA-256 signatures. For this the stated policy is "No changes until SHA-1 preimage is possible." Even MD5 signatures are still accepted.

3. The digest of the timestamp. When using signtool.exe you need to use the /tr argument with the URL of an RFC 3161 timestamping service and /td sha256 to request SHA-256. Windows 7 is the oldest version of Windows that supports SHA-256 timestamps. For this the stated policy is "On Win 10 and above, blocked on 1/1/2017 for Mark of the Web files."

The summary is that if you obtain an SHA-256 certificate then a single SHA-1 signature using that certificate with an SHA-1 timestamp is presently accepted by Windows XP SP3 through Windows 10. On 1/1/2017 you will need dual signatures if you want to support Windows 10 as well as Vista or XP SP3.

The depreciation policy is applied to Windows 7 and later through Windows update. If updates are disabled, the depreciation will not happen. What you should experience is that Windows 7 treat a signature with an SHA-1 certificate as invalid which should result in more severe warnings when running a file downloaded from the internet.

Answer 4

Just some additional information from me as well, as I ran into an issue with all of this today, that cost me half a day.

I got the "The signature of this file is corrupt or invalid." from Edge as well. Windows told me that my file (which was already signed with SHA256), is not secure and also failed to show me the correct cert information (Only "Unknown Publisher").

We are using StartSSL Code Signing certificates and switched to a new SHA256 certificate in december. What we failed to notice was, that signtool includes all intermediate (!) certificates during the signing process as well. Turns out: It uses the locally cached version of the intermediate certificates, which were outdated (still using SHA1), despite newer ones being available. After removing & updating this certificate, everything worked as expected.

So, make sure to check if every certificate in the chain is also SHA256, or everything will break - as the intermediates are included during the sign process!

Answer 5

I just went through the same issue with our Windows apps. So here's some info for you:

A) As you pointed out SHA-1 hash is being phased out due to it's inadequate collision resistance. Or, in other words, it doesn't produce code signatures that are strong enough by today's crypto-standards.

B) To code-sign your executable you'll need to have a code-signing certificate that supports any of SHA-2 hashing algorithms, such as SHA-256. (In my case the CA, Comodo, upgraded our existing code signing cert for free. You'll need to ask your CA though.)

C) Download and install the latest Windows SDK. Then you can access signtool.exe in either of these two locations:

For 32-bit:
%SystemDrive%\Program Files (x86)\Windows Kits\10\bin\x86

For 64-bit:
%SystemDrive%\Program Files (x86)\Windows Kits\10\bin\x64

D) The following table shows which OS's support SHA-1 and SHA-256 code signatures:

+---------------------+-------------------------------+------------------------------+
|     Windows OS      |             SHA-1             |           SHA-256            |
+---------------------+-------------------------------+------------------------------+
| XP SP3, Server 2003 | Yes                           | No (need KB968730, KB938397) |
| Vista, Server 2008  | Yes                           | No (need KB2763674)          |
| 7, Server 2008 R2   | No (if signed after 1/1/2016) | Yes (with latest updates)    |
| 8.1, Server 2012 R2 | No (if signed after 1/1/2016) | Yes                          |
| 10, Server 2016     | No (if signed after 1/1/2016) | Yes                          |
+---------------------+-------------------------------+------------------------------+

One important note for Vista users is that they need to install KB2763674 to be able to open files signed with SHA-256 signature.

E) So the solution to address discrepancies in the table above is to dual sign your executables. To the best of my knowledge the following files support dual signing:

.cpl, .com, .dll, .exe, .scr

So to code sign a file call signtool twice as such:

First SHA-1 (as a fallback for older OS):

SignTool.exe sign /f "path_to_exported_cert.pfx" /p "pfx_file_password" /d "Your file description if you need it" /t "http://timestamp.verisign.com/scripts/timstamp.dll" /v "path_to_file_to_sign.exe"

then SHA-256 on the same file to add it (/as parameter):

SignTool.exe sign /f "path_to_exported_cert.pfx" /fd sha256 /p "pfx_file_password" /d "Your file description if you need it" /tr "http://timestamp.geotrust.com/tsa" /td sha256 /as /v "path_to_file_to_sign.exe"

Note that parameters to sign with SHA-256 are different, especially for the timestamp server! Using the timestamp server for SHA-1 produces weird results in Windows 10.

F) For any other files, including: .msi, .msp, .js, .vbs, .jse, .vbe, .ps1, .ps1xm, .psm1, .ps1xml, .wsf you will need to chose one or the other, as they do not support dual-signing. So unfortunately we'll have to sign them specifically for the OS that they are intended to be deployed on.

Answer 6

I have used osslsigncode (a linux tool) to dual sign the exe installer with SHA1 and SHA256. For Windows users I have read about a Windows fork of osslsigncode. My current comodo signing certificate 2016 comes with dual digest SHA1 and SHA256 so I only need a single certificate for both signatures.

First must go the XP compatible signature:

osslsigncode sign -pkcs12 comodo-signing-2016.p12 -askpass \
-n "My-program installer" \
-i http://www.my-site.com/my-program \
-t http://timestamp.comodoca.com \
-h sha1 \
my-installer.exe my-installer-signed.exe

Then the Win7/8/10 compatible one:

osslsigncode sign -pkcs12 comodo-signing-2016.p12 -askpass \
-n "My-program installer" \
-i http://www.my-site.com/my-program \
-ts http://timestamp.comodoca.com \
-nest -h sha256 \
my-installer-signed.exe my-installer-dual-signed.exe

Note that I use the Authenticode timestamp (-t) for the first signature and the RFC 3161 timestamp (-ts) for the second one. Not sure about how useful is this but Authenticode is older and probably more backwards compatible. The authenticode timestamp digest is sha1 by default and the RFC 3161 is automatically set to sha256 as mentioned here.

Also note that the second command includes the -nest flag in order to add the new signature instead of replacing the first one.

Answer 7

It appears that Microsoft have significantly changed their policy on deprecating SHA-1 for code signing, as of 19 October 2016, 11:15 am. Before that time, they said SHA-1 was going to be deprecated for code signing (11:14); after that time, they say SHA-1 code signing is unaffected for now, with no shut-off date specified for the future (11:16).

Here are the details as of today, 25 Feb 2017 (link to current version):

TLS Server-Authentication Certificates
   Today:      No lock icon Microsoft Edge and Internet Explorer 11
   Mid-2017:   Invalid Certificate
Code Signing Certificates
   Today:      Unaffected
   Mid-2017:   Unaffected
Timestamping Certificates
   Today:      Unaffected
   Mid-2017:   Unaffected

In the long term, of course, SHA-1 is a risk; this question is however about the deprecation of code signing certificates on Windows, and there Microsoft's change in October 2016 is significant compared to previously released plans. They currently say "Long-term, Microsoft intends to distrust SHA-1 throughout Windows in all contexts," and the plan for that is in "Phase 3", "after 2017".

Answer 8

While your certificate will not return warning signs on older platforms and browsers you will see warning signs on any upgraded systems. The best example to give you is Windows 10. Windows 10 will show warning for ANY code signing certificate that IS NOT an EV - SHA-256 certificate.

If the platform has been updated to the new recommendations of the CA/B forum guidelines then your certificate will not eliminate warning signs.

If you want to talk to someone in more detail let me know and I will get you in touch with someone at GlobalSign who can issue you a new certificate or just talk to you in more detail about compatibility. Otherwise this article may indeed help: https://support.globalsign.com/customer/en/portal/articles/1499561-sha-256-compatibility

Answer 9

Not as a full answer, but for some additional overview information, including signtool example lines for dual signing (XP/Vista compatibility)

I managed to switch nicely to dual-signing in my build chain according to this very good blog post from ksoftware.net, our certificate supplier.

I wrote a small batch file to dual-sign a file with the two certificates and call this from my deployment script:

set SIGNTOOL_CMD=F:\FuH\dev\Docklight1\Installer\signtool\signtool.exe
set DL_WWW=http://docklight.de
set DL_PROJ_NAME=Docklight
set TIMESERVER_SHA1=http://timestamp.comodoca.com
set TIMESERVER_SHA256=http://timestamp.comodoca.com/?td=sha256

"%SIGNTOOL_CMD%" sign /v /sha1 D35C... /t %TIMESERVER_SHA1% /du %DL_WWW% /d "%DL_PROJ_NAME%" "%1"
"%SIGNTOOL_CMD%" sign /v /sha1 7FD7... /as /fd sha256 /tr %TIMESERVER_SHA256% /td sha256 /du %DL_WWW% /d "%DL_PROJ_NAME%" "%1"

Instead of downloading the full Windows SDK for an updated signtool, I just grabbed the signtool download link from the KSoftware blog

I tested this on Windows 10 x64 / Edge and it looks all good.