Here is my dilemma, I am trying to perform Application Whitelisting based off of publisher which in turn is based on whether or not the application has been signed. The issue is, unsigned software does not have a publisher listed. My idea was to then vet unsigned software and if approved for use we could sign it with our internal code signing certificate. I tested this process out using Microsoft`s signtool and it seemed to work but here is the issue. When I tested it out I did it on an installer.exe, after that I installed the application in which it then created a file in Program files with the other installed .exes that came with it. When I check on the signature of the .exes that were installed in the Program Files it says that they are unsigned! I know i could go and run the same command on those to sign them but that is not feasible if we were to deploy this to numerous end systems. My question is: Is there a way to sign the installer to which when installing it, the .exes that are installed will also be signed by our internal certificate? Or is there a way to install the application and sign the necessary files and then repackage it for deployment? Sorry for the long question but I cant think of a way to get this done and I figure since Application Whitelisting is hot right now someone must have had a similar issue. Also, I know that we can use Path or Hash but that is not what I am trying to do here.
Thanks
First of all, I don't recommend signing vendor code with your corporate signature. I'm not sure if you are doing that or not but if you are, I'd suggest being careful. Unless you know exactly what's in the code, signing someone else's code is just not a good idea.
You are correct that the exes from the installer are unsigned; that's how the process works. When you sign an executable, you are only signing that exe and not the content of the cab file it extracts and lays down.
I use McAfee Application Control with signed installers, and that works out well. I trust my company's signature as an updater (allows it to change files), and it installs the software as desired without signing each executable.
So, let's go through the questions (sorry if this is long).
Is there a way to sign the installer and sign its subordinate exes? Not that I know of. Files are signed individually. You could probably automate that somehow; that's for a different thread. I'm no expert on signatures but in my experience when I've signed an installer that hasn't recursed into the installed content.
is there a way to install the application and sign the necessary files and then repackage it for deployment? Technically possible. Keep in mind that if you repackage a vendor install, you lose support on the install. There are several snapshotting tools out there that would do a delta on what was installed and would let you gather that info and then sign the files. That's an application packaging question on how to create the install from a snapshot.
Related
I have made free software and converted it into an NSIS installer. But the issue is that when users download the setup.exe first they get chrome warning not commonly downloaded and it is dangerous file with a keep button hidden under an arrow button.
Even if they choose to keep the file, when opening the installer, the windows SmartScreen shows up warning the users again.
Is there a way can I get past these two for free? I mean I don't charge my users anything.
I only know a way to bypass the download warning. However it is not the prettiest solution, but I am currently using this while researching other possibilities.
My way to bypass the SmartScreen download filter is to bundle your setup.exe into a .zip for instance and then download the zip file instead and then the users can run the setup.exe from within. After some testing and feedback, most of our users don't notice this small extra step.
When they run the setup, you need to have signed the installer using a valid certificate for the Windows warning to go away. Here I have not found any clever ways to avoid this. So you need to pay some certificate authority to create a valid certificate for your software.
Hope this answers your question.
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 made an application for Windows & everytime I run the application by opening the executable file I get the "Publisher Unverified" warning in Windows. It is fine if I was the only audience for this app but thats not the case. Is there any way to program my app such that this message does not show up for the users.
The only way to do this is to obtain and use a code signing certificate from a trusted source. Microsoft calls this Authenticode.
Unfortunately for the little guy, these cost. Verisign sells theirs for about four hundie a year.
Here are some starting points you should read about Authenticode:
http://msdn.microsoft.com/en-us/library/ms537359(VS.85).aspx
http://technet.microsoft.com/en-us/library/cc750035.aspx
http://msdn.microsoft.com/en-us/library/aa379872(VS.85).aspx
Some certificate dealers:
http://www.verisign.com
http://www.thawte.com
http://www.globalsign.net
http://www.geotrust.com
For a cheaper code signing certificate, you can use Comodo. There is a reseller called KSoftware which sells their certificates for $99/yr:
http://www.ksoftware.net/code_signing.html
I used them a few years ago and had no problems.
You can then use SignTool from the .net SDK to sign your EXE files. There is a tutorial here:
http://www.tech-pro.net/code-signing-for-developers.html
I think there is a way to resolve this. We need to add digital signature to the executables. The way to add digital signatures is very nicely outlined at,
http://blog.didierstevens.com/2008/12/30/howto-make-your-own-cert-with-openssl/
http://blog.didierstevens.com/2008/12/31/howto-add-a-digital-signature-to-executables/
Basically we will use OpenSSL to create our own digital signatures and then use the SignTool application by Microsoft to add it to our executable.
I've got a brand new code-signing certificate and have been wondering which files I should sign.
Clearly, the setup .msi package and all .exe which run elevated should be signed to avoid "unknown publisher" warnings, but should I sign other executables, e.g. .exe which don't need elevation, .dll or .oxc?
Microsoft themselves seem to handle this inconsistently:
In Office 2007, all executable files are asigned
In Visual Studio 2008, all .exe and many .dll are signed, however, there are also lots of unsigned DLLs (apparently strong-named assemblies, maybe they consider strong-naming sufficient)
In Windows (7), neither executables nor dlls are signed (not even executables that need UAC, like mmc.exe!)
I think you answered your own question, sign only where needed to avoid prompting.
There are only a few reasons where I would consider signing everything.
It might have some kind of advantage
with Anti-Virus vendors treating
your files as more trustworthy,
therefore less support / install
hassle.
It marks the file as more trustworthy to a general user, for example, when I clean up a virus infected system using autoruns from MS I tend to look for shoddy stuff that has no signature, it sticks out a mile.
You want to look more professional.
I don't know what overhead there is in checking the signature though, so older systems may be slower. Also, if your cert is from a cheapo cert supplier then the root CA might not be included in older platforms (XP pre SP2 etc).
Oh yes, I'd only do it as part of the build as well (integrate into MSBuild or a build server) as it could get tedious.
Remember to not let anyone else get access to your key otherwise you'll have it revoked and all of a sudden, installs might stop working. So use a self signed cert for devs and keep the real key locked down on a build server.
Bit rambling, but there is no right answer I think.