Does my Windows app needs to be signed with a trusted certificate? - windows

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.

Related

Code signing applications within Windows for Application Whitelisting

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.

Microsoft SmartScreen - suspended using Inno Setup installer?

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.

Best Code Signing Practice

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.)

Undentified Publisher on a signed setup executable during install with Vista

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.

Code-Signing: which file types should I sign and why?

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.

Resources