Windows app code signing in 2016

Microsoft announced that starting from January 1, 2016, software signed with certificates which use SHA-1 algorithm will no longer be treated as digitally signed. Meaning it will display various warnings when you try to install such software. Older builds, timestamped before 1st January will continue to work.

I’ll link to discussion on BOS about this subject:

However I don’t see that it’s enforced yet. Tried to install new release of CCProxy on Win 8.1 and Win 10 and it works without any warnings. I can see digital signature, that it’s SHA-1 and timestamped in 2016 and there are no problems yet. Does anyone else see this issue with new builds and SHA-1?


Ugh. How do I check if my company’s signing procedure is currently SHA-1?

I bought the certificate here in Spain in mid-2014.

To check the current digital signature of a file, in Windows Explorer, right-click the file. Click ‘Properties’, then click the ‘Digital Signatures’ tab. The ‘Digest Algorithm’ column tells you what it’s signed with.

Here’s some more information: enter link description here

I decided to sign with both SHA1 and SHA256 for the reasons outlined in the link above. After some investigation, here’s the commandline arguments I used for signtool.exe:

First sign the file with (SHA256):
sign /fd sha256 /f “PATH_TO_PFX_FILE” /p PFX_PASSWORD /tr /v “PATH_OF_FILE_TO_SIGN”

Then sign a second time with (SHA1):

1 Like

Can you sha1 sign with a sha256 certificate? Or do you need 2 certificates?

As long as you’ve got a pfx file you can sign with both (as I’ve shown above) or with either individually. The benefit of signing with both is that some older versions of Windows don’t support 256, so they can fall back to SHA1.

In your case, I think that you should be able to sign with SHA1.

I just found this out also, I mean that SHA1 is not valid anymore from the foirst of Jan. I always buy a 3-year Comodo certificate via Tucows. So I renewed last December expecting to receive a SHA2/256 cerificate. When I signed my code with the new certificate and checked, it still appeared to be SHA1.

I complained with Tucows and received within a day a new certificate, tried, but still the same, SHA1! Both Tucows and Comodo asssured me that the certificate was SHA256, so I expected the problem must be with me.

Finally I found that I had been signing with “Signtool” from the VisualStudio 2008 SDK.Switching to “Signtool” from the Windows 10 SDK solved the problem and the code ias signed now with SHA256. By the way, I both sign the exe and the msi.

I really want to express here my happiness with the fast and great support from both Tucows and Comodo in this matter.

I just found out that my existing Comodo certificate from February 2013 CAN be used for SHA-2. I just used newer signtool.

So there was no need to ask for new certificate. Unfortunately I figured out this too late, I already used their control panel to “Replace” existing certificate. Btw. this doesn’t mean I purchased new certificate, this is just replacement for existing one. However new one is in “awaiting validation” state, and old one which turned out to be perfectly ok will expire in two weeks because of this replacement. I’m mad now, mostly at myself. I hope this validation doesn’t include any phone calls and other stupid stuff we have to endure when we sign up.

My certificate was due Feb 6 2016, so I needed a new one anyway. Surprisingly the validation process was very fast this time, only a few days and no need to supply them with additional proof as in previous times. Only an automated phone call procedure by Comodo this time was required.

As both grujicd and me learned: use the latest signtool!

The two commands in Gareth’s post were very helpful. With those, I was able to dual sign the “exe” file using a sha2 certificate.

However, that approach does not work for “msi” files. It gives the error “Multiple signature support is not implemented for this filetype”. Searching for this, I reached this link.

That article does mention a way to dual sign the msi files. But, the example command there ends with “foo.exe” and not an msi file, making me not trust it fully!

Wait a second. “Digest Algorithm”? You sure about this? @Gareth

I think you have to click “view certificate” - “details” and see “Singature algorithm” and “signature hash algorithm”

PS. side note: Joel’s forum is still alive? I guess that’s even bigger news hahah :slight_smile:

1 Like

@jitbit, yes, on Windows 10. Not sure about earlier versions of Windows:

In addition to the “/fd sha256” parameter, “/td sha256” should also be added to make timestamp digest sha256 too.

I mean, you sure that MS means THIS algorithm, not the one inside the certificate?

I had a cert from Comodo via KSoftware with almost a year to run.

Comodo will re-issue them for free -

Had to contact KSoftware to get this done and Mitchell organised it with no problems.

Highly recomend KSoftware for certificates, used them for over 6 years now.


Did they revoke the old certificate afterwards? If so did that mean any old downloads needed to be re-signed to avoid a scary warning?

Good question - I assume not but have to check.

In fact how do you check that!

Has anybody found a way to sign installer “msi” files using sha2 certificate so that they are fine both on newer versions of the Windows as well as on XP & Vista?


I’m not sure how you’d check, presumably an old download would show the scary warning.

Had anyone seen those warnings? Just tried old (sha1 signed) and new downloads (both sha1 and sha256) on Windows 10 with all updates, but neither of install packages issued warning for me…

The warnings are scheduled to start in January, 2017.