Windows app code signing in 2016

Some more info from KSoftware here:

I just tried my cert out I got from Ksoft in June 2013 (5-yr cert) and it does both SHA1 & SHA256 (you need to timestamp it for SHA256) so don’t panic until you’re totally sure.

I used this to sign the SHA256 (the /debug flag gives you a verbose output. See

"C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe" sign /debug /fd sha256 /f "C:\....certificat.pfx" /p password /tr /v file.dll

+1 for Ksoft, I remember them being good to deal with.

With some help from Mitchell Vincent of I written up what I think you need to know about SHA1/SHA2 and code signing:

Anyone else been having problems since signing with their new SHA-256 certs?

Both IE (SmartScreen) and Chrome (whatever it uses) now warn me the software isn’t downloaded often and may be malware yadda yadda.

I never got this with my previous SHA1 certs, including when I originally started signing a couple of years ago.

I’m wondering if I’m not signing the software correctly, but the details appear under Windows “Digital Signatures” ok, the only difference being a missing support email address in the new version (I can’t remember how I provided that in the first place).

I’ve spoken to the ever-helpful Mitchell at K Software who said it probably needs downloading a few times and then it will be trusted… it’s just that as this didn’t happen when first signing under SHA1 I’m a bit nervous something is not quite right…

The software itself works fine once all the “Run anyway” hoops are jumped through.

Do you put version name in downloaded file? I do, and that proved useful over the years when I want to point customer to specific version for whatever reason. However I made that decision almost a decade ago when there were no drawbacks for that. Now I wonder if it’s a problem whenever there’s a new download with different version number.

I don’t. Not anywhere in the signature-related bits anyway. I’m assuming the content of the actual app is ignored anyway, otherwise this “reputation” would be getting trashed on every release (I aim for fortnightly/monthly releases).

Sounds like it could be a possible problem though, given what MS say about comparing the text portions of the signature.

I didn’t wrote it clearly. I’m putting version number as part of file name. Therefore each new release appears as a new file name. I have no idea how MS determines what’s new file, whether they disregard numbers from file name or not.

Yep, there must be a URL out there that describes all the inputs to the similarity score.

In my case, all files are named the same: setup.exe.

I expect they use a hash of the file contents to determine what is a unique file. I would be very surprised if they pay attention to the file name.

A few other people have mentioned smartscreen suddenly popping up when you change your cert, but that it then usually goes away in a few hours or days (depending on how many people download your stuff perhaps).

1 Like

Maybe we should share our downloads to help each other get our reputation up…

1 Like

AFAIK the reputation is collected per-certificate, not for individual files. Each new version of my programs is published under a new file name (e.g. SoftwareName_setup_a.b.c.d.exe). The “not commonly downloaded” warning lasted only for a short period of time, when a certificate was just issued. Nothing changed when I added sha-256 signature in addition to sha-1. Tested on Windows XP, 7, 8, 10 with all latest updates.

1 Like

I have a Comodo certificate issued in mid-2015. It supports both algorithms. The only real extra step I needed to take was to create a PFX file for the newer versions of SignTool to work with. Comodo automagically installed my certificate when I purchased it and I’d never needed the PFX file before. There’s a short write up of the process I followed to get dual signing working here.

For those who use InnoSetup they introduced Dual Signing of installers / uninstallers in version 5.5.8 which was released about 4 weeks ago.