I recently faced a very strange problem. Compilation of our products includes signing the kernel-mode drivers and adding a countersignature. This is done using a call to signtool, included in the DDK (now WDK):
"%DDKBASE%\6001.18000\bin\SelfSign\signtool.exe"
sign /T
http://timestamp.globalsign.com/scripts/timstamp.dll
/ac
"path-to-countercert\MSCV-GlobalSign.cer"
/s SPC /n "EldoS Corporation" %1
Everything worked fine until recently when we discovered that the countercertificate is just not added to the signed driver. signtool doesn't report any errors and silently omits the certificate. The signature itself and main certificate chain are applied properly, and it's only countercertificate that's missing.
SignTool from the later WDK (version 7600.16385.0) works fine using the same command line.
I tried to re-register capicom.dll, coming with signtool in question (it resides in the same folder) but this didn't help.
I am not sure if we can use signtool from 7600.16385.0 because I have a feeling that it might break compatibility with say Windows 2000.
So the question is whether anybody has an idea of what might have gone wrong?
Upd: Well, it looks like 7600 signtool works fine (i.e. drivers signed with that version work fine on XP and Windows 7), so we'll go that route for now and will replace signtool with our own homemade tools in future to avoid such surprises.
It is OK to use the 7600.16385.0 version of signtool. It will still work on Windows 2000.
As for the issues with the 6001.18000 version, check to see if you have multiple certificates for your company in your certificate store. The wrong one may be selected.
Related
I want to sign a static .exe build of one of my Open Source programs so that it will be executable in a "normal" manner to a "normal" Windows user.
I bought an Open Source Code Signing Certificate from certum.eu to be able to do this.
After some searching on the internet, I tried to sign the exe file using osslsigncode 1.7.1 on my Linux maching using
osslsigncode sign -pkcs12 cert.p12 -pass "..." -h sha2 -t http://timestamp.verisign.com/scripts/timstamp.dll -in some.exe -out some-signed.exe
Having somebody testing it on Windows 10, a rough warning pops up: "Windows protected your PC. Windows SmartScreen prevented an unrecognized app
from starting. Running this app might put your PC at risk."
So I tried to use the native Windows tool signtool.exe to sign it. I installed it in my old virtual Windows XP (where I also compiled the program; I don't have access to any other Windows machine) and signed the exe file with
"C:\Programme\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f C:\cert.p12 /p "..." /t http://timestamp.verisign.com/scripts/timstamp.dll C:\some.exe
This tool also said everything was okay, but still, the very same warning pops up.
This way, the certificate is simply useless, as the "signed" exe file does produce the very same warning as the unsigned one. I would greatly appreciate help about this.
Short answer: Wait a couple of days and the problem will disappear.
I had the same issue with my Certum certificate earlier this year. And a few years ago, I had a commercial certificate I got from Comodo and it initially had the same issue as well.
The bottom line is that your new certificate and signed binaries needs some time to gain trust and auto-verified by Microsoft's code-signing reputation service.
Start distributing your signed exe to as many PC as you can and do the "advanced" option to force the exe to run anyway. That might help bump the reputation up faster.
Being on the "Fast Ring" of Windows 10, I got a strange behaviour on my own setup executables:
I'm SHA-1 signing them with Authenticode since years the same way and never had any problems.
Recently Windows 10 does not recognize my (valid) signatures.
When downloading a setup.exe from my website and executing it, the Windows SmartScreen message box appears and tells me:
...
Publisher: unknown
...
When viewing the properties of the just downloaded setup executable, it shows the signature, and tells me that the signature is valid.
In addition, the whole certificate chain is valid.
I'm signing it with something like this:
SignTool.exe sign /v /t http://timestamp.verisign.com/scripts/timstamp.dll
/f "my-authenticode.pfx" /p "my-password" "my-setup.exe"
(Line-breaks added for readability)
My question:
Is anyone aware of a possible reason (and fix) for this?
More Information:
I can think of possible reasons:
Signing with Windows 10 Fast Ring is buggy. (I've signed on Windows Server 2008 R2 with the same behaviour).
Running the downloaded setup executable within Windows 10 Fast Ring is buggy.
Update 1:
I've found a MSDN blog article back from 2013 that seems to talk about something similar as I discover, but I still cannot see whether this really applies.
More strange: Older downloads from our website, signed with the same Authenticode certificate do not trigger the warning.
Maybe SmartScreen compares the timestamp and behaves differently for newer signatures/setup executables?
Maybe I would need to add additional/different parameters when calling SignTool.exe?
Update 2:
On a non-Fast Ring Windows 10, the SmartScreen warning is not displayed.
In addition, there is also a similar SO posting which didn't help me further.
Plus, there is a Symantec posting, that claims:
For Windows Vista 64-bit and Windows 7 the signing process has changed. The code cannot simply be signed, it also needs to be "cross-signed" with a certificate provided by Microsoft.
This is strange to me since my signing procedure worked successfully until recently.
They further link to their own instructions which talk about kernel mode software only.
Update 3:
User GSerg pointed me to "Windows Enforcement of Authenticode Code Signing and Timestamping" on Microsoft TechNet.
This seems to go into the right direction.
I've seen that my current certificate is SHA-1. I've just updated it to SHA-2/SHA-256 by re-issuing it from Thawte.
Now, I still get a SmartScreen warning on my local Windows 10 Fast Ring PC but at least it now prints the publisher.
I'll no purchase a code signing cert from DigiCert since I believe that the certificate chain also has influence on how the SmartScreen filter sees my application. I do hope it is an improvement compared to the Thawte certificate I'm currently using.
If you plan to sign for Windows Vista, please note that there was a problem with SHA-256 signed files. The linked TechNet article talks about dual signing to overcome this.
Update 4:
See also this SO answer that deals about passing the SmartScreen warning with signed applications.
If this DigiCert certificate plus waiting to get enough reputation still does not help, I'll probably have to swallow the bitter pill and buy an extended validation (EV) code signing certificate (which requires a hardware token and is more expensive).
Update 5:
After approx. one day, SmartScreen seems to not show any warnings anymore.
Seems that my now dual-signed setup executables (SHA-1 plus SHA-256) already got enough reputation to successfully pass the SmartScreen tests.
My certification path/chain now looks like this:
What looks a bit strange to me is that the root certificate "thawte" still uses SHA-1.
I would have expected that this still causes SmartScreen worries, but it seems it doesn't.
Update 6:
The article "Do You Need SHA-2 Signed Root Certificates?" explains why you do not need a SHA-256 root certificate.
In the meantime I've also received my Authenticode certificate from DigiCert. I'm using it in some setups already.
It only took about one single day until the SmartScreen filter did pick it up and not warn about it anymore.
So I'm now having a Thawte Authenticode code signing certificate and a DigiCert Authenticode code signing certificate.
If I understood the SHA-256 implications earlier, I could have saved the money for the DigiCert certificate.
As user GSerg pointed out, the reason for the error in my initial question was that I'm using SHA-1 only which is "deprecated" by Microsoft since 2016.
After dual-signing my setup executable both with SHA-1 and SHA-256 (and waiting some days), the SmartScreen filter does not complain anymore.
I always use Inno Setup for packaging and publishing. Users download the application using a link for example: https://oursite.com/codesigned/mysetup.exe
Till now, it always worked. But recently I have to renew my code signing certificate because its expired. After renew I have SmartScreen problem, every users download the application and gets this Smartscreen which was not before.
I have used signtool.exe verify /pa innosetup-made-myexe.exe and it shows successful, also I have done the verification with Windows Application Certification Kit, that shows it is PASSED, but with WARNNINGS, all those WARNNINGS mostly generated by Inno Setup.
Here you can find the output, where its showing WARNINGS on Inno Setup exes:
https://docs.google.com/document/d/11frW_GxI0xSVcrAXh4_rqcKBQSaermAlpYKj4xzQi4o/pub
How can I fix this problem?
(still not sure if its Standard Code Signing vs EV code signing issue? I already used Standard Code Signing for few years, it always worked. I can upgrade to EV Code signing, but how can I make sure its not Inno Setup compiler problem? As you can see already the WARNNINGS are shown in the URL above to Inno Setup)
To verify if it's Inno Setup or code signing issue (see https://stackoverflow.com/a/29067585/285594), I have done following:
From Microsoft, I have downloaded the file call winqual.exe, which does not need Inno Setup.
I code signed the winqual.exe and uploaded to my same server
I downloaded the same file with Internet Explorer and it works without showing me the SmartScreen.
Does it make any sense now if Inno Setup is the main cause of this problem?
Nowadays, you have to use EV code signing certificates.
See Transferring Microsoft SmartScreen reputation to renewed certificate.
Below is the original answer, which addresses some specifics of the question.
If you believe the problem is due to an unsigned uninstaller, make sure you set the SignTool directive of your Inno Setup project accordingly. And make sure SignedUninstaller directive has its default value yes.
Quoting SignTool directive documentation:
Specifies the name and parameters of the Sign Tool to be used to digitally sign Setup (and Uninstall if SignedUninstaller is set to yes). When Setup has a valid digital signature, users will not see an "unidentified program" warning when launching it.
If you want to set NXCOMPAT and DYNAMICBASE flags to the uninstaller, you can create a sign.bat batch file that both calls signtool.exe and editbin.exe:
#echo off
editbin.exe /NXCOMPAT /DYNAMICBASE %1
signtool.exe sign ... %1
The calls need to be in this order, otherwise the editbin.exe breaks the signature.
Then use the sign.bat instead of signtool.exe in the SignTool directive.
Though I do not really think this is necessary, nor helps anything.
I think this is normal behavior.
When your software collect enough "likes" = downloads or installs the SmrtScreen will automatically turn off this message.
It is really annoying feature because with every software release you need to wait appropriate time while the software become "popular" and it is recognized as safe (no certificates or antivirus methods can solve it).
You do NOT need this "Windows Application Certification Kit".
What #slappy says is correct:
After renewal of your certificate, you need enough downloads and "good reviews" before this message goes away.
What you need to do is to download your application using Microsoft Edge (not Chrome or Firefox!!!).
It will most likely say "This download may be dangerous and has been blocked".
Then you can choose "Keep anyways". And then you can choose "Report as Secure".
And THEN even Smart Screen says that it doesn't trust your app (even though it's digitally signed, LOL!!!!), then you have to choose "More..." and "Install anyways".
Install it on your computer! I think that is important.
I have used 5 different computers and reported my apps as secure multiple times and installed it.
I have also asked 2 friends (because of their different IP address) to do the same.
I hate this so much!!!!!!!!!!
After 1 day, the error message was gone.
I'm unclear how a driver should be signed in my specific circumstances.
OpenVPN has a tap driver that consists of tap0901.sys, tap0901.cat and OemWin2k.inf files.
When I install it using "devcon install OemWin2k.inf tap0901" on my win7 64-bit, it installs silently, without scary warnings.
I renamed the driver to have a different name ogtap100 (by renaming files to ogtap100.sys, ogtap100.cat and replacing "tap0901" strings in OemWin2k.inf to "ogtap100", as per http://community.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers and comments in OemWin2k.inf).
However, when I run "devcon install OemWin2k.info ogtap100" on the renamed driver, I get big scary warning from Windows that the driver comes from unknown source. It'll install but I plan to ship it as part of my app, so big scary warning is not good.
When I run "signtool verify /v ogtap100.cat", I get: "SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." even though it also says that root certificate is "Issued to: DigiCert High Assurance EV Root CA".
I've tried re-signing (signtool sign /f cert.pfx ogtap100.cat) with my own certificate (which works when signing regular .exe files) but I get the same scary warning.
What am I missing?
Can it be sth. to do with catalog (.cat) file?
I've read http://msdn.microsoft.com/en-us/windows/hardware/gg463050 but it assumes that I'll generate .cat file myself. I already have .cat file from OpenVPN. Do I have to re-generate it after renaming files and OewmWin2k.inf? If yes, how?
1) Did you ensure that you got the high assurance digicert certificate? The standard one they issue isn't meant for drivers. It is simple to change...
https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm
2) If you download the Windows 7 DDK and do a little 'reading the intent and the code' as opposed to just following the instructions, you can succeed at building your own driver (cat and sys files), properly renamed and signed.
https://community.openvpn.net/openvpn/wiki/BuildingTapWindows
Look at the OemWin2k.inf generated for some strong hints for renaming. Note: The Time stamp needs to be correct, and it is in (the ridiculous) mm/dd/yyyy format.
3) As for the warning message, at least you can get it to properly display your company name, and Windows will accept (and not disable) the properly signed driver.
For details about driver signing, check out
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/0b00c9d4-dff9-4fbe-b741-768c9b39349c/practical-windows-code-and-driver-signing-discussion?forum=wdk
This is a summery that points to some reference docs. Generating the .cat file from the inf is simple.
Check out the syntax and order of operation. I'm also using a Digicert certificate. make sure you have one issued for driver signing and pay attention to the make sure the cross certificate is correct.
The build script uses the inf2cat method, so if you are following the WHOLE instructions (and searching for the stuff in the settings that the inf didn't tell you about ... look for constants) then you are generating the .cat file.
For my install, I figured that the .sys file should be signed before generating the .cat and signing it.
Also, make sure your pc has all the windows updates. This actually did work to 'fix' a pc that had the same error signature. (It didn't have the required certificate to validate the cross certificate, which it automatically downloaded.)
(I purchased a code signing cert from Thawte and have been going out of my mind with frustration at the whole process.
What I have from them are:
.spc / .p7b file
.pvk file
(NOTE I do not have a pfx file from them. God knows why, but I have been fighting with their tech support for a week)
In any case I find "help" links on their site and at MS for signcode.exe which is useless for me because I can't find that exe on my machine, however I do have signtool.exe.
Unfortunately i am mystified at the command line parameters listed on this MS help site.
Specifically, what parameters do I use and what values? I tried what I thought was obvious but it does not work at all.
I can get the signing wizard to work, however I need this to work non-interactively in a hudson CI batch file.
It really doesn't seem like it should be this difficult, but so far it is all black magic.
thanks for any help
First, you can generate your own pfx file using the pvk2pfx tool described at http://msdn.microsoft.com/en-us/library/ff549703(VS.85).aspx
Something like
pvk2pfx -pvk cert.pvk -spc cert.spc -pfx cert.pfx -pi password
ought to do the trick.
Secondly, signtool is the tool you're after. http://msdn.microsoft.com/en-us/library/aa387764(VS.85).aspx
signtool sign /?
Gets you the help, but the basic command you're probably after is
signtool sign /f cert.pfx /p password target.exe
Which will sign target.exe. It gets more complex if you want to put the certificate into the certificate store on the machine (this is the CSP bit). This is really useful though for doing signing on a lot of dev machines, or on build lab machines where you want to avoid putting the certificate in source control.