I have a setup executable which I have signed with a Verisign cert. The executable displays the correct publisher information during installation with XP and Win7, but on Vista it displays it as "Unidentified Publisher". I've checked each and every individual file that gets put into the msi and the executable manually using the Properties menu to verify that those files are signed, and they are indeed signed with a signer and timestamp BUT not an email. (Is there a tool that does this?).
If I run the msi contained inside the executable, and cancel the installation before it is complete. Then when I run the SAME setup executable that was complaining about Unidentified Publisher again, it displays the correct publisher information.
Does anyone have a suggestion on how I may solve this problem? I am aware of the bug with windows installer on Vista for uninstalls, but this is an install.
What tool are you using to sign the package, is is SignTool.exe? If so, are you getting the certificate from a path specified on your machine or you've specified for SingTool.exe to get it from the store.
The recommended method is to import the certificate in the store and then ask for SignTool to use it from there.
This problem appeared for me only if the SignTool.exe used was from Windows SDK v.7.0 or later.
Related
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 developed a Windows app using C++ and QT library. The app doesn't require elevated privileges to run.
I'm going to distribute my app as an MSI installer downloaded from a website. The installer will be signed using my signed certificate.
However, I haven't signed the EXE file and I don't see any issues with that. There's no security warning shown when I start the app after the installation.
So the question is, should I sign the EXE file as well? If I don't sign it, will there be any issues?
For example, after I downloaded the Dependency Walker tool, it shows me a security warning about an unverified publisher every time I run it. My EXE file isn't signed as well, but I don't see any warnings.
I'm wondering if I can encounter any issues if I release the unsigned EXE file within my signed MSI installer.
It would certainly be preferable for the EXE file to be signed, but it is not ordinarily mandatory. Windows will not warn users when running an unsigned executable file unless the file has a zone identifier or is being elevated ("run as administrator").
However, unsigned files are more likely to experience false positives from security software, may cause users or administrators to be concerned about the trustworthiness of the file and/or process, and are more difficult for administrators to whitelist in high-security environments.
Generally speaking, if the container (the MSI file) is signed and therefore has not been tampered with between its creation and use by the customer then you can trust the content when it gets extracted. Signing is something used mostly at deployment, whether via MSI install or installing a driver, or when you transfer the file to someone else. If there were a scenario where you'd ask some other person or company to use that executable outside of installing it from the MSI file they would probably prefer that it be signed to verify that it's from you and your company.
I have acquired and deployed a digital code signing certificate. I have added it to the installation program for a Windows application, signing the InstallShield setup.exe file and the msi file. Everything works perfectly in the installation program.
My application is installed as a single exe file along with a complied html help file.
Is the best practice to digitally sign the exe file in addition to the Windows installation program?
Yes. You should sign the executable as well.
You should also ensure you use a time-stamp server if possible when signing too. Thus users of your application know the code came from a valid source, and the certificate was valid when it was signed. (The time-stamping means users can check the signing is valid after the expiry date of your certificate - i.e. the signature will be valid for all time.)
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.)
On my machine, I’m using a signed application with an installed certificate to get a trusted publisher dialog from Windows. I’ve created a certificate with makecert.exe and installed it to the certification store in windows. From there, I’ve exported the PFX and signed with signtool.exe my application. In order to get the same trusted publisher dialog on another machine, a certificate is necessary. Instead of installing the certificate by hand, an installer should accomplish the importation of the certificate. Unfortunately, the windows installer doesn’t support this feature. Because of that, I’m looking for a solution like a classical API command in windows. Is there something built-in in windows to make it easier or something comparable?
To install certificate with respect of MSI setup you have to use custom actions. If you not familiar with custom actions I recommend you to use the simplest custom action which allows you to start an exe. It can be an existing utility like CertUtil.exe (see here some examples and try certutil -importPFX -? to see help about the import of PFX files).