Code Signing on Windows now requires some attention

If you are code signing your applications for distribution on Windows I recommend reading up on the requirement to use SHA256 certs if your app is code signed after January 1, 2016. Windows 7 no longer accepts SHA1 signatures generated after Jan 1, 2016 BUT requires a KB hotfix to accept SHA256 certs. See https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=INFO3205 for all details.

The solution seems to be dual-signing using a SHA1 and a SHA256 and it works for our apps.

Cheers,
/Mattias

Thank you for the heads-up, sir.

Sorry for sounding thick:
what does

entail?
Do we need to buy two certifcates now: I dont know how I could incorporate dual signing into my process which is currently to incorporate KSign into the Inno setup build…

I use a Comodo Code Signing Certificate with KSign tool but cannot select which SHA.
Am I missing something?

And how can I check which SHA certificate I have?

[quote=239325:@Jeff Tullin]Sorry for sounding thick:
what does
dual-signing
entail?
[/quote]

The dual signing allows Vista users to run the EXE without any warnings. Vista only supports SHA-1. Signing the EXE with BOTH certificates allows all versions from Vista/2008 up to Windows 10 to properly verify the signing.

This may depend on your Certificate provider. We are using thawte and I just used the Re-issue (not revoke!) and generated another SHA-256 certificate and saved that to a pfx-file. I am using Microsoft’s SDK tool signtool.exe to sign the EXE and installers. Sorry if I can’t help you with other tools.

[quote=239328:@Christoph De Vocht]I use a Comodo Code Signing Certificate with KSign tool but cannot select which SHA.
Am I missing something?

And how can I check which SHA certificate I have?[/quote]

Sign the EXE, right-click and check the security tab. You should see one signature with sha1 or sha256. When the EXE is dual-signed it should look like this:

Note that the timestamping of the SHA256 signature must be made with a SHA256-certified timestamping service as well, see https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=INFO3266&actp=search&viewlocale=en_US where the secondary (SHA-256) signature is made using geotrust.com.

Ok, my Comodo Codesigning Certificate is SHA256.
Looking into this a bit further and as far I understand, when you codesign with a SHA256 certificate, it will work on Vista (with patch/hotfix) and upwards for download and installers.

[quote=239336:@Christoph De Vocht]Ok, my Comodo Codesigning Certificate is SHA256.
Looking into this a bit further and as far I understand, when you codesign with a SHA256 certificate, it will work on Vista (with patch/hotfix) and upwards for download and installers.[/quote]
That’s my understanding as well.

I asked kSign (who I use for Windows certificates) and they sent this back this afternoon:

So, hopefully this will get cleared up for those users soon.

Anyone else purchase a Tucows branded Comodo code-signing certificate? I got one about 3 years ago which is expiring soon, and it looks like it’s SHA1 only. I can’t find any info on the Tucows site about upgrading…

@Michael D

I just renewed my Cert through Tucows late November and it is SHA256 (SHA2)

[quote=239467:@Bob Keeney]I asked kSign (who I use for Windows certificates) and they sent this back this afternoon:

kSign will work fine with a SHA256 certificate as that is really a function of the certificate and not the signing tool. What kSign does use is an SHA1 file digest algorithm, but that’s not what is being referenced with all the current talk about SHA1/256 (it is confusing for sure!). Unfortunately the library that kSign uses doesn’t seem to support SHA256 file digests so I’m in the middle of a re-write from the ground up… Hopefully I’ll get that wrapped up this week

So, hopefully this will get cleared up for those users soon.[/quote]

This is what I think so too.

When I do a view certificate details from right-click file properties, my COMODO certificate shows Signature algorithm as sha256RSA and Signature hash algorithm as sha256. This is a sha256 certificate. Scroll down and I see Thumbprint algorithm sha1 and I understand this is a property to the certificate on my computer nothing to do with the certificate actual sha256 algorithm.

When I use Ksign to sign my exe, I see Digest algorithm in file properties of my exe as sha1.

What is important is whether the actual codesign cert is sha256, not the Digest algorithm. From Bob’s post, when Ksoftware update Ksign, then Digest algorithm will show sha256.

Installer that I use can sign the setup as digest algorithm sha1 or sha256, whichever I choose.

I did a test yesterday.

Using Ksign, my exe was codesigned with Digest algorithm showing sha1 and timestamped 5 Jan 2016 (this is obviously after 1 Jan 2016). I created the installer and signed the setup as sha1 and timestamped 5 Jan 2016.

Uploaded the setup to my website.

Using a Windows 10 computer updated to latest Windows updates and never downloaded from my website before so no prior instance of my codesign cert in this computer, I login as Standard User, download the setup, run the setup. Windows 10 did not make any noise.

What should be happening? Or what should I be seeing differently?

Seems this may not be quite correct or not very clear what/which/whatever is actually required to be SHA256 for Windows 10:
https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=INFO3205

[quote]Jan. 1 - Dec. 31, 2016
User Mode: SHA256. Windows continues to verify SHA1 signed code which has been timestamped prior to Jan. 1, 2016.
[/quote]

Is there a way to use the signtool.exe instead of KSign so we can still have SHA256 with Comodo certificates?

Same here. Did a quick test (with KSign) and when downloading the setup.exe it did say it is from a valid (mine) developer and ran fine without a glitch. Does it mean SHA1 is still possible or does KSign still use SHA256 ? (my Comodo Codesigning Certificate is SHA256 for sure).

Ksoftware reply to Bob:

So I think there really is confusion what actually is required of this SHA256 thing. What Ksoftware saying is about Ksign software using SHA1 file digest algorithm, whatever this means and has nothing to do with the codesign certificate which is actually SHA256.

Whatever this confusion, the good news is:

[quote=239512:@Cho Sing Kum]Ksoftware reply to Bob:
So I think there really is confusion what actually is required of this SHA256 thing. What Ksoftware saying is about Ksign software using SHA1 file digest algorithm, whatever this means and has nothing to do with the codesign certificate which is actually SHA256.[/quote]

Indeed it is confusing. The SHA256 is required for the hash of the Certificate and starting mid-2015 (I guess) all certificates issued (Code Signing and “HTTPS” web-certifcates) are SHA256 by default. My old Code Signing certificate (issued October, 2014) is using SHA1 for the hash of the Certificate and thus I had to re-issue (free-of-charge) to get a SHA256.

For the file digest (that is signed with the Certificate), I haven’t seen any requirements whether to use SHA1 or SHA256. I use the “/fd” flag to signtool.exe to indicate sha256 file digest to use with the SHA256 Certificate and sha1 for use with my SHA1 Certificate.

[quote=239508:@Cho Sing Kum]I did a test yesterday.
What should be happening? Or what should I be seeing differently?[/quote]

If you check the Certificate you used to sign your EXE (right-click the EXE and then Properties), it will most likely show as sha256 (sorry for only having this in Swedish, I am out of office and only have my small laptop):

Since kSoftware is rewriting kSign, with some luck, we should have a valid solution in a week or so (never trust a developer’s own TTC estimate :wink:

Hi Mattias,

Yes, this is what I explained in my first post here at… <hmm don’t know what time… 1 hour ago will change… not static> … after brian franco’s post. Only thing I used words instead of screen shots.

This is what is showing on computers of mine where I have tested my program, Win7, Win8, win10, because I understand the info already embedded into the exe after I signed.

What I was wondering about is that during downloading and installing, Windows 10 was very quiet. My understanding then is that as long as the codesign certificate is SHA256, the digest algorithm does not really matter, which your initial screenshot (6th post) seem to lead to confusion because that screenshot is about digest algorithm to be SHA1 and SHA256, not Signature algorithm/Signature hash algorithm.