Home » Blog
date 20.Dec.2015

■ It's all change for installer code signing (authenticode) from 2016


Are you a software vendor enjoying Christmas? I was immersed in christmas cheer until I read a strange article that claimed that SHA1 code signing certificates would be worthless in less than 2 weeks. Surely this cannot be? Throughout this last year I've heard about microsoft and google teaming up to eradicate SHA-1 "vulnerable" hash algorithm, but it was always connected to https:// websites, so it wouldn't affect me as a software vendor. So what was this guy all about? And why nobody warned us mISVs all this time?

After some googling around my original worry turned into panic when I found word from microsoft themselves pronouncing the death penalty to SHA1 signatures. Where do I stand? I purchased a 5-year cert recently, should I buy a new one immediately? Examining the Digital signature properties of my installer it was clear that the Digest algorithm is sha1, and that is not good. If windows considers sha1 untrustworthy, then my installer would be as bad as left unsigned. This means that users that tried to install xplorer² would get a security warning about "unknown publisher" or something scary like that. Not good for business, surely.

With increasing sense of frustration I looked high and low for an installer that was signed with SHA2 (or SHA-256), the SHA1 secure replacement, but to no avail. Every installer I downloaded, every big name in the business, was SHA1 signed. Even the latest windows 10 PSDK (sorry, windows kit :) was signed with a soon to be doomed old certificate. Obviously there are very few people aware of the impending doom. And there's only 10 days to go!

SHA1 to SHA2 authenticode planned changes explained


According to the official word, from 1st January 2016 here's what's going to happen:

The last point ensures that hell won't break loose first thing in the new year, but for anybody planning to release new or updated software versions in 2016, they need a SHA-2 digital certificate. If you bought your code signing certificate in the last year or so, chances are that you already have a SHA-2 certificate. How can you tell? Through the digital signature properties, click View certificate button and check the Details tab. Old SHA1 certs will show sha1RSA as the Signature algorithm. I was happy to see that mine said sha256RSA, which means I don't need to buy a new certificate!

My joy was aburptly tapered when I realized that the SHA-2 infrastructure does not exist for older windows versions. It really works only for windows 7 and later, it half-works for vista and XP, and older windows than that need not apply. xplorer² runs all the way back to windows 98, so that was a big spanner in the works. I was surprised to discover that my existing installer appeared unsigned for anybody running windows XP SP2 and older. For these old systems, the SHA1 signature generated by the new SHA2 certificate I possess does not validate! The properties declare that "The integrity of this certificate cannot be guaranteed. The certificate may be corrupted or may have been altered". The real cause is that old windows don't have the capability to validate the SHA2 certificate, but to the end user and blissful layman it appears as a dodgy signature. For older windows what you need is an old SHA1 certificate, only you cannot buy them any more, so you (and me) are basically stuffed. On the positive side, end users won't be alerted to such problems unless they try to install on windows XP SP2.

I read that this problem is of particular importance to device driver signing, but this is not a concern of mine, thank the Maker :)

Windows Vista and XP SP3 need special attention. There, the SHA2 certificate is recognised but only if it is used with the default signtool settings that generate a SHA1 digest. If you do a secure SHA256 signature, then again it appears as unsigned! On the other hand you must do the SHA256 digest to target windows 7 and above. This total mess is resolved by double signing your installer with both SHA1 and SHA256 digests. Details will follow.

Software vendor (mISV) SHA2 survival checklist


Here's the distillation of what you need to do to protect your installer's reputation. If you don't plan to release any new software updates in 2016 and ever after, then you've nothing to worry about, resume with xmas festivities. Otherwise here's what to do:

I conclude this guide with summary information on double signing executables. It is possible to attach two signatures to an EXE as sha1 and sha256 generate different digests. But you need to obtain a recent version of SIGNTOOL.EXE that supports the /as switch. The minimum version I found capable was 6.3 that comes with windows 8.1 SDK (if you don't want to download the full package here's just the signtool download). You can use either the PFX file or if it is installed on your computer simply use the certificate's Subject name. First do the SHA1 then add the SHA2. The latter will most probably require a RFC 3161 time stamp server. The example below deals with my comodo digital certificate and its timestamp servers.

After all that you will see a double signature as in the pic to the side. Windows Vista and earlier will not show the sha256 part but at least the signature will appear valid.
double sha1/sha256 signed installer

signtool sign /n "subject name" /t http://timestamp.comodoca.com/authenticode myInstaller.exe
signtool sign /n "subject name" /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 /as myInstaller.exe

Is this all just a storm in a teacup? Am I exaggerating the risk? I am not 100% but with all the above preparations you are safe come what may. Then you won't have any nasty surprises spoiling your New year celebrations. Merry Christmas everyone :)

Post a comment on this topic »

Share |

©2002-2015 ZABKAT, all rights reserved | Privacy policy | Sitemap