cancel
Showing results for 
Search instead for 
Did you mean: 
Flexera MichaelU
Flexera

Re: Codesigning using SHA-2, SHA256

The supported way of changing the timestamp server in InstallShield is to edit settings.xml. (Take care editing that file, and keep a backup of the last known good version.)
0 Kudos
Stefan_M
Pilgrim

Re: Codesigning using SHA-2, SHA256

I changed the line

to

but this didn't work.

Commandline with RFC3161 timeserver
SignTool.exe sign /f cert256.pfx /p password /fd SHA256 /tr http://timestamp.geotrust.com/tsa filename.exe

Commandline with old timeserver
SignTool.exe sign /f cert256.pfx /p password /fd SHA256 /t http://timestamp.verisign.com/scripts/timstamp.dll filename.exe

The difference is the /t <> /tr parameter.
0 Kudos
Flexera MichaelU
Flexera

Re: Codesigning using SHA-2, SHA256

Ah, thanks, I missed that difference in your post. However I'm now unclear whether you're talking about InstallShield 2014 or 2015, as we no longer call signtool in InstallShield 2015. In 2014 you're welcome to keep intercepting the command lines and processing them yourself.

Regarding doing this in InstallShield 2015, it looks like the APIs only support generating RFC3161 timestamps on Windows 7 or later - that's not a problem for you is it? Assuming it's not, I can file a request to add support for these. I expect we would also put this in settings.xml, at least if we can add it before our next major release.
0 Kudos
Stefan_M
Pilgrim

Re: Codesigning using SHA-2, SHA256

Would be nice to have this in IS 2015.

Additionaly it is necessary to sign files with SHA1 and SHA256 because some programs are used with Vista and Windows7/8.

Actual I run signttool twice:
SignTool.exe sign /f Cert_SHA256.pfx /p password /t http://timestamp.verisign.com/scripts/timstamp.dll filename.exe
SignTool.exe sign /as /f Cert_SHA256.pfx /p password /fd SHA256 /tr http://timestamp.geotrust.com/tsa filename.exe

the first signing uses SHA1 for Vista
the second uses SHA256 for Windows7/8

Additional Parameter:
/as Appends this signature. If no primary signature is present, this signature is made the primary signature instead.
0 Kudos
Flexera MichaelU
Flexera

Re: Codesigning using SHA-2, SHA256

I will have to double-check with the engineer that implemented this, but my recollection is that we tested the ability to verify SHA-256 signatures and (according to my fuzzy memory) it worked down through Windows XP, er Windows Vista. Since the API required to place additional signatures requires Windows 7 er Windows 8 (we only require Vista for the IDE), and everything seemed to work without it, we chose to use a single signature whose digest's hash algorithm matches the certificate's hash algorithm. Have you encountered a scenario where this fails?
0 Kudos
joshstechnij
Pilgrim

Re: Codesigning using SHA-2, SHA256

There are a number of reasons that multiple signature support was not added to 2015:
- The API required to sign a file with multiple signatures requires Windows 8.
- Windows Vista does support sha256 signatures with SP2 and hot fix KB2763674 which is available through Windows Update and has been available since November 2012. Only pre-Vista platforms are missing sha256 support, but these will all be out of support in another month or so.
- Windows Installer does not support multiple signatures, only PE files are supported.

Due to these factors, in addition to the engineering effort, multiple signature support was considered low priority and therefore not implemented. This is something that could be implemented in the future, but if Microsoft's push to get everyone on Windows 10 takes off, it might be somewhat irrelevant to support multiple signatures.
0 Kudos
Tobias79
Pilgrim

Re: Codesigning using SHA-2, SHA256

We use IS2010 on our products. Now I got it working wrapping SignTool.exe with our own wrapper which just forwards the command line to an Windows SDK 8.1 Version of the SignTool.exe with additional
/fd SHA 256
parameter.

But now when building a Setup.Exe with an embedded signed MSI we run into issue
Started signing certificate.msi ...
sign /f /fd SHA256 "\\ourOFS.pfx" /du "http://www.OurUrl.com" /p "OurPassword" /d "certificate" "certificate.msi"
timestamp /q /t "http://timestamp.verisign.com/scripts/timstamp.dll" "certificate.msi"
ISDEV : error -6258: An error occurred extracting digital signature information from file "D:\InstallShield 2010 Projects\My Project Name\Product Configuration 1\Interm\certificate.msi". Make sure the digital signature information provided in the IDE is correct.
Started signing My Project Name.msi ...


Certificate.msi seems to be an MSI with only purpose for temporary storing a certified MSI? Which then is read again from IS Compiler. I assume that behavior same for IS2010 until IS2014. So how to prevent IS to read the certificate from the certificate.msi or enable IS also to read an MSI with sha256 Digest Algorithm?

What are in general the drawbacks when only sign the setup.exe but nomore the embedded MSIs?

Best regards,
Tobias
0 Kudos
Tobias79
Pilgrim

Re: Codesigning using SHA-2, SHA256

Any feedback on my previous post? :)
0 Kudos
Nick_Umanski
Flexera beginner

Re: Codesigning using SHA-2, SHA256

It seems to me that most of the problem can be worked around.

1. Manually or batch file sign all the binaries before building the installer. This is how we used to do it with IS11.5 and now I've resurrected that process, only modifying it to dual sign. Fortunately, with my InstallShield 2014 installers, I had set up to NOT "Sign Files That Are Already Signed" and thus I don't need to change the installers.

2. Manually or batch file sign the Setup.exe after InstallShield has built it.

The command lines needed to do this in both instances are:

signtool sign /n %CommonName% /t http://timestamp.comodoca.com/authenticode %FileName% >> %LogFile%
signtool sign /n %CommonName% /fd sha256 /tr http://timestamp.comodoca.com/rfc3161 /td sha256 /as %FileName% >> %LogFile%

Replacing %CommonName% with the Common Name of the digital signing certificate, %FileName% being the file to be signed and %LogFile% being the name of the file to hold the results of the operation, useful when signing several hundred files as a background task.

Source: http://zabkat.com/blog/code-signing-sha1-armageddon.htm

_______________________


However, I'm left with one problem, the MSI. Some of my installers spit out an .msi file for use with active directory installment. Others embed an .msi file inside the Setup.exe

I can only sign the standalone .msi once and then only with a SHA-1 (or md5) Digest Algorithm, attempting to add the second signing produces an error. Even if you have an unsigned .msi, you cannot sign it with the SHA-256 Digest Algorithm, which is the most important of the two Algorithms. I presume this is a Microsoft problem rather than an InstallShield one?

As for the embedded .msi I simply cannot access it, but given the previous point, it wouldn't work anyway. However, although it is something I've always done, I'm uncertain whether you actually need to sign an embedded .msi or whether the signed Setup wrapper takes care of that. Can anyone confirm or deny that?

0 Kudos
Tobias79
Pilgrim

Re: Codesigning using SHA-2, SHA256

Acc. TechNet ( http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode... ) recommended strategy is to stick to SHA1 only for MSIs (e.g. MS does it for the new 2015 VCRedists).

IMHO removing signing for MSIs completely if they are embedded within an setup.exe seems ok at first glance. Short testing with IS2010 UI Build also caused trouble when using a new certificate with activated InstallShield certification.
0 Kudos