none
Why does IE10 tell my users that my executable download signature is "corrupt or invalid"? RRS feed

  • Question

  • Hello.  I am developer who makes some software that is available for download as an executable file from the internet.  I recently noticed that when people download the file in Internet Explorer, it gives an error message that says "The signature of this program is corrupt or invalid."  This error message makes it hard (but not impossible) for our users to run the program.

    I have reproduced this problem on my computer which runs Internet Explorer 10.0.9200.16686 and Windows 7 64-bit SP1.  Here is a picture of the error message I am getting:

    I inspected the signature of the file in the Properties window and it looks totally fine.  Can someone please tell me why Internet Explorer is rejecting the signature and what I can do about it?

    You can inspect the file and its signature yourself if you want; it is available for download here:

    http://www.davidegrayson.com/keep/sign_exe_130918/svp2.exe

    The file was signed with a SHA1 code signing certificate from Go Daddy, using the following command:

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool" sign /v /t http://tsa.starfieldtech.com /r "Go Daddy Class 2 Certification Authority" /n "Pololu Corporation" /sha1 300cbc06f4c9be4e313ed48fdc9d2dd8a5b862be %1


    I am eager to learn what is happening here because I do not want our users to see this error message.  Also, it is valuable information that I would add to the long article I wrote, Practical Windows Code and Driver Signing.

    I clicked on the "Learn More" link but it took me to a very generic Microsoft Support page with no information about that particular error message.  I also searched with Google.


    --David Grayson



    • Edited by DavidGrayson Wednesday, September 18, 2013 6:53 PM
    Wednesday, September 18, 2013 6:45 PM

Answers

  • Thanks for the help, qwerasdfasd3.  Your answer but me on the right track to figuring this out, because it did actually work.  However, I did an experiment and determined that SHA256 isn't actually important.

    For IE10 to accept your signature, you should use the /tr option instead of /t when you invoke signtool.

    You can see my experiment here:

    http://www.davidegrayson.com/signing/svp2_signing_experiment/

    Based on this, I would recommend using /tr for all signatures.  I do not recommend using SHA256, because in my experience, support for SHA256 in older versions of Windows is generally spotty.  If you use SHA256, I would be worried about the signature failing on some version of Windows XP or Vista.


    --David Grayson



    • Marked as answer by DavidGrayson Wednesday, October 2, 2013 5:58 PM
    • Edited by DavidGrayson Wednesday, October 2, 2013 6:00 PM
    Wednesday, October 2, 2013 5:58 PM

All replies

  • The file passes WinVerifyTrust just fine, and IE should be using this API to verify the signature. I suspect that the reason the file being rejected is because it is using SHA1. Try switch to SHA256.


    Visual C++ MVP

    Wednesday, September 18, 2013 10:03 PM
  • I'm having the very same problem and it's also with a Go Daddy certificate.

    See http://files.rootsmagic.com/RM6Setup.exe

    I know the problem isn't using SHA1 vs SHA256 since I have an older executable that was signed with a certificate from Comodo also using SHA1 and it is perfectly fine.

    See http://files.rootsmagic.com/PHistorianSetup.exe

    What is strange is that I have quite a few executable files signed with a Go Daddy certificate that, up until a few days ago, downloaded in IE without any problems.  And now they are all suddenly giving Invalid Signature errors when all other indicators say that the signatures are fine.  Downloading the files in any other browser works just fine.

    I'm wondering if Go Daddy's certificates somehow were blacklisted in some verification service that is used by IE.

    Thursday, September 19, 2013 1:18 AM
  • Thanks for the example files, Michael!  I was able to reproduce your results here.  My svp2.exe and your RM6Setup.exe and PHistorianSetup.exe all are signed with certificates whose chain of trust goes back to the Trusted Root Certification Authorities list on my computer (viewable with certmgr.msc), so I don't know why Internet Explorer raises an alert for two of the three.

    Could someone from Microsoft please tell us what is going on here or how to debug it?  Ideally you would just write documentation for Internet Explorer's download security scan feature.  If you are too busy, please just give us the source code for Internet Explorer's download security scan, and I can write the documentation.  (Hey, it doesn't hurt to ask.)

    Michael, we also have quite a few executables signed with Go Daddy and we didn't specifically test the download on Internet Explorer, but as far we know there were no issues until someone in the Netherlands reported one on 2013-09-12.


    --David Grayson




    • Edited by DavidGrayson Thursday, September 19, 2013 8:12 PM
    Thursday, September 19, 2013 5:51 PM
  • I am encountering the same problem.  I don't know why IE is being an issue but even assemblies which we created years ago with our GoDaddy cert is encountering problems.  If I can't find a resolution soon we will end up shipping unsigned.  

    Platforms:  My efforts have all used the v7.1 or v7.0 SDK.  Given this and the posts above I think it is pretty clear that this isn't related to different versions of signtool.exe.  My testing has been IE10 under windows 8 but I will examine other OS/IE behaviors and edit this post.

    Update:  No error is presented on XP/IE9 or any prior version of IE.  An error is presented on windows 7/IE10.

    • Edited by _CurtisC_ Thursday, September 19, 2013 7:59 PM More testing
    Thursday, September 19, 2013 7:40 PM
  • Having the exact same problem as well. Any help from MS would be appreciated.
    Thursday, September 19, 2013 8:21 PM
  • CurtisC and qwerasdfasd3:  Thanks for your input.  What company did you buy your signing certificate from?

    --David Grayson

    Thursday, September 19, 2013 8:30 PM
  • It's a GoDaddy Code Signing Certficiate.
    Thursday, September 19, 2013 8:31 PM
  • >What is strange is that I have quite a few executable files signed with a Go Daddy certificate that, up until a few days ago, downloaded in IE without any problems. And now they are all suddenly giving Invalid Signature errors

    Make a list of windows updates installed in the past few days. Uninstall them one by one, see if the result change. If you found an update that breaks signature validation, you can open a bug on connect.microsoft.com/IE.



    Visual C++ MVP

    Friday, September 20, 2013 12:11 AM
  • I've reproduced the problem on:

    Internet Explorer 10.0.9200.16686, Windows 7 64-bit SP1 
    Internet Explorer 10.0.9200.16688, Windows 8 64-bit 

    Friday, September 20, 2013 1:49 PM
  • Timestamping the application signature with SHA256 appears to fix the problem.

    Something like this:

    signtool sign -n "My CodeSigning Subject" /tr http://tsa.starfieldtech.com /td SHA256 "MyApp.exe"

    • Edited by jknepfle Friday, September 20, 2013 1:50 PM
    • Proposed as answer by _CurtisC_ Friday, September 20, 2013 11:55 PM
    Friday, September 20, 2013 1:50 PM
  • Another developer named IgHR has reported a similar problem with his SHA2 Go Daddy certificate; in September 2013 "signtool verify" started giving him an error message about how it doesn't trust the Go Daddy root G2 (SHA2) certificate.  You can see his post here:

    http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/0b00c9d4-dff9-4fbe-b741-768c9b39349c/practical-windows-code-and-driver-signing-discussion#ea3d1bbb-3ae9-48d5-ba16-a3ab4d82ec25


    --David Grayson

    Friday, September 20, 2013 3:45 PM
  • For the meantime I simply turn off SmartScreen Filter temporarily for the files that raise a flag. Works fine after that. Hopefully there will be a fix soon that clears this up for all IE 10 downloads that are falsely blocked.
    Saturday, September 28, 2013 3:40 PM
  • Thanks for the help, qwerasdfasd3.  Your answer but me on the right track to figuring this out, because it did actually work.  However, I did an experiment and determined that SHA256 isn't actually important.

    For IE10 to accept your signature, you should use the /tr option instead of /t when you invoke signtool.

    You can see my experiment here:

    http://www.davidegrayson.com/signing/svp2_signing_experiment/

    Based on this, I would recommend using /tr for all signatures.  I do not recommend using SHA256, because in my experience, support for SHA256 in older versions of Windows is generally spotty.  If you use SHA256, I would be worried about the signature failing on some version of Windows XP or Vista.


    --David Grayson



    • Marked as answer by DavidGrayson Wednesday, October 2, 2013 5:58 PM
    • Edited by DavidGrayson Wednesday, October 2, 2013 6:00 PM
    Wednesday, October 2, 2013 5:58 PM
  • It worked well until January 12th (or so)... now the same pain is back again and SmartScreen is raising alerts on software downloaded.

    1) I switched to use a certificate signed with SHA256 and the software is signed with SHA2.

    2) We use the /tr option as well, and the algorithm for timestamping is sha256 too.

    in sort we use

    signtool sign /a /fd sha256 /td sha256 /n VeriSign Class 3 Code Signing 2010 CA /d Reporting Estandar SL /du http://www.reportingstandard.com /tr http://timestamp.geotrust.com/tsa /v {installer file to sign}

    The point is that I've installed Skype today to tell a colleague about the issue and the Skype installer failed smartscreen test too. so my question is if this is now a general issue for everybody using smartscreen?

    Tuesday, January 19, 2016 8:02 PM
  • Bill Cumming has been tracking Microsoft's SHA-1 deprecation plans and reporting it in another thread.  In particular, he posted that:

    As of Patch Tuesday (1/12/2016) Microsoft has now turned on SHA-1 deprecation.

    I don't think it's a coincidence that IgHR started seeing IE security scan errors on January 12th.  I also got a similar report from one of my users recently.  I thought that older downloads with SHA-1 certificates that were timestamped before 2016 would be OK, but maybe not.  I might have to do more experiments.

    It looks like Skype updated their Windows installer just yesterday!  It looks like they have a SHA-1 signature with a SHA-1 certificate and also a SHA-2 signature with a SHA-2 certficiate.  I can tell they updated it yesterday because of the cryptographic timestamp.


    --David Grayson





    Tuesday, January 19, 2016 9:48 PM
  •  I thought that older downloads with SHA-1 certificates that were timestamped before 2016 would be OK, but maybe not.  I might have to do more experiments.

    I think you are right, if you need to conduct more experiments .. you can check these two files

    First one is signed with SHA-1 on 2015-12-31:

       http://www.reportingstandard.org/RS_XBRL_Setup_es-2.8.7-x64_951.msi

    The second one is signed the same way on 2016-01-07:

       http://www.reportingstandard.org/RS_XBRL_Setup_es-2.8.7-x64_953.msi

    You can see that SmartScreen behavior is completely different.

    Wednesday, January 20, 2016 11:59 AM
  • Hi,

    It looks like the problem was on the root CA signed with SHA1.

    We had a SHA256 certificate from Verisign and Verisign Class 3 CA certificate was a SHA1 certificate. When signing executables we found them rejected by SmartScreen. Now, we tested with another certificate from GoDaddy whose CA is also SHA256 and it worked fine.

    • Proposed as answer by IgHR Thursday, January 21, 2016 1:57 PM
    • Unproposed as answer by DavidGrayson Saturday, January 23, 2016 1:52 AM
    Thursday, January 21, 2016 1:57 PM
  • FYI, the "VeriSign Class 3 Code Signing 2010 CA" certificate itself is signed with SHA-1. This seems to be causing SmartScreen to report "signature is currupt or invalid" even thogh both the code and your certificate are signed using SHA-2.

    I contacted Symantec (they run VeriSign now) and they issued a replacement certificate to us (for free). It's signed by "Symantec Class 3 SHA256 Code Signing CA", which itself is SHA-2-signed. Executables signed by the new certificate are no longer blocked by SmartScreen due to corrupt or invalid signature.

    So watch out for "VeriSign Class 3 Code Signing 2010 CA" - it's signed with SHA-1 and even if your certificate issued by it is signed by SHA-2, it won't work with SmartScreen.

    Thursday, February 18, 2016 10:41 AM