Still have SHA256 timestamp issue in released InstallShield 2016

[delderkidasa]

To get SHA256 time stamps I changed the settings.xml file timestamp entries to look like this:




so that the time stamps would be SHA256.

This works on the MSI and EXE files that get built by InstallShield. These files show an SHA256 time stamp.

Symantec SHA256 TimeStamping Signer - G1

However, unsigned EXE files embedded in the MSI and EXE installers that I have InstallShield sign via the Releases signing tab, Include patterns and files option still get timestamped with an SHA1 signature:

Symantec Time Stamping Services Signer - G4

It is still unclear to me the importance of having SHA256 time stamps. So far, I have not seen it addressed in any of the Microsoft sky is falling SHA256 documents, but it would be nice if there was a way to make this work for EXE files signed via the Patterns and Files option.

[joshstechnij]

For reference, the code path for signing files in a package (from the Release setting, including or excluding files to sign based on the include and exclude filters on the Signing tab) is exactly the same as signing a release setup.exe or MSI file. This means for each file to be signed in a given release (setup.exe, .msi, or packaged file), the following steps are taken:
1. Read the Digital Certificate Information setting from the release. If the certificate setting does not point to a certificate store, assume a pfx is being used file for signing and verify the pfx file exists.
2. Read the Certificate URL setting.
3. Read the timestamp server from settings.xml using XPath 'DevStudio/Build/DigitalSignature', read the 'Timestamp' attribute from the first returned element.
4. Read the Signature Description setting. If this is empty, use the file name as the description. For signing package files, the signature description is always ignored and the file name is used.
5. Determine if we are signing a software tag file (.swid) or a binary. For binary files, pass the information read from the above steps into code that wraps the Win32 Signer* APIs used to sign files and timestamp signatures.

Based on this code path, the timestamp server is read from the same element/attribute in settings.xml for each file signed. Unless settings.xml is changing while a build is in progress (which introduces a race condition), all files should receive a timestamp from the same server specified in settings.xml. If no timestamp server is configured in settings.xml, build warning -1027 will occur for each file to be signed. The code does not include any default or fallback timestamp server if one is not configured or in the event the timestamp APIs fail (warning -1027 will occur for all these cases; the file signature will not contain a timestamp).

Please note that InstallShield does not attempt to sign (and therefore timestamp) any packaged files that are already signed. If a packaged file that would be included to be signed by the InstallShield build is already signed, the message 'File %1 is already signed' is logged in the build log and output. Note that this message does not have a warning or error attached to it, so it will appear as a normal build output line.

Please verify that the packaged files you are expecting to be signed are not already signed and are not listed as already signed in the build log. If they are, either remove the signatures or do not sign the files outside InstallShield, or set the release setting 'Sign Files That Are Already Signed' setting to Yes on the Signing tab of a release.

[delderkidasa]

The files in the filter list are not already signed.

The single MSI file or EXE file is properly signed with the supplied PFX file and time stamped with the SHA256 time stamp server from the settings.xml file.

The unsigned files that get signed with the filter are signed with the supplied PFX file, but time stamped with the default SHA1 time server, which seems to be hard coded in your isdev.exe program rather than from the settings.xml time stamp server.

Rather than quoting to me how it is supposed to work, why not just try it yourself and see what happens.

In the meantime I have switched to pre-signing the unsigned files using signcode, and removing the files from the signing filter.

[joshstechnij]

Which project type are you working with? Since MSI files timestamping correctly had been mentioned in the original post, we have been working on the assumption that this is an MSI (Basic MSI or InstallScript MSI) project. The information we had previously provided was based on and accurate for MSI project types. Please let us know if you are working with a pure InstallScript project, as this detail creates a significant difference.

[delderkidasa]

The problem exists in both Basic MSI projects which result in a single MSI file and Installscript projects which result in a single EXE file.

The only files which are not time stamped properly are unsigned EXE files which are listed in the to be signed filter list.

It appears that in both cases the settings.xml file setting for the Time Stamp server is ignored. Even though the settings.xml file specifies a SHA256 time stamp server and the PFX file that I supply is an SHA256 certificate, the time stamp applied to these files in the filter list are always signed by your default SHA1 time stamp server, not the SHA256 server listed in the settings.xml file.

Surely you could simply try it yourselves to see what happens.

[joshstechnij]

Unfortunately we are unable to reproduce the behavior you are seeing in MSI type projects. We've tried the following steps:
[LIST=1]

Install IS 2016 on a clean Windows 10 build.

Create a new Basic MSI project; add one feature, one component, one file.

Create a new release in the project of type 'network image', compressed, no setup launcher. Use a self signed sha256 certificate (.pfx) (this isn't strictly necessary, the timestamp is independent of the signature). Sign the MSI, setup.exe, and files in package; select the EXE added from step 2 in the files to include.

Build and install the MSI. Confirm that the timestamps on the installed test EXE are from 'Symantec Time Stamping Services Signer - G4' with a digest algorithm of sha1 and the signing time similar to the build time.

Edit \Program Files (x86)\InstallShield\2016\Support\0409\settings.xml. Change the Timestamp attribute of the DigitalSignature element to 'http://sha256timestamp.ws.symantec.com/sha256/timestamp' and save the file (granting permissions to the current user since all files in Program Files are read/write only for administrators).

Uninstall the previous test MSI.

Rebuild the MSI project in IS 2016.

Install the MSI. Confirm that the timestamps on the installed test EXE are from 'Symantec SHA256 TimeStamping Signer - G1' with a digest algorithm of sha256 and the signing time similar to the build time.

We can confirm that there is an issue following the above steps with pure InstallScript projects. The InstallScript build does not read the timestamp settings from settings.xml and results in always timestamping with a sha1/Authenticode timestamp for signing files included in the package. Work order IOJ-1773314 has been created to track this issue.

If you can provide any additional information that differs from the above steps, or anything else we may have missed for signing packaged files in MSI type projects, please let us know and we will continue to try reproducing the issue.

[delderkidasa]

Thanks for confirming half of my bug report.

The EXE installers I create are pure Installscript projects, thus I DO see the bug in those.

I agree that MSI projects do NOT have the bug, after I took my own advice I tried it for myself, again.

Hopefully you can get the Installscript bug fixed at some point. These are trusty updater type Installscripts that started out in InstallShield 3.0 way back in the 90s.

The source location for some of the .exe files included are shared between the .MSI based installs and the pure Installscript EXE based installs so I either need to pre-sign the EXEs or have InstallShield do the signing, so I guess I will need to continue to pre-sign until you can get the Installscript bug fixed.

[joshstechnij]

Work order IOJ-1773314 should be resolved for an upcoming service pack for IS 2016 as the fix is a relatively simple change. Unfortunately this issue was caused by an oversight in changes made a number of releases ago when support for configurable timestamps was originally added. We apologize for any inconvenience this has caused.

[hidenori]

I'm pleased to announce that InstallShield 2016 SP1 is released today, and IOJ-1773314 has been fixed in the service pack.

[crich65]

delder,

I feel your pain on this one,

Now that it is April 2017, I am getting 1027 errors all over as if SHA1 is being forced.

Did Flexera ever get your sha256 problems resolved?

Thank you in advance,

[gastaro]

I use InstallShield 2016 SP1(Japanese).

So I changed the Settings.xml file in InstallShield Program Files \Support\0411.

Before:
After:

However, an EXE file that I have sign via the Releases signing tab still get timestamped with an SHA1 signature:
Symantec Time Stamping Services Signer - G4

However choose Based on certificate hash or SHA-256 in Certificate Selection Dialog Box Settings - Signature Digest,
still get timestamped with an SHA1 signature.

I would like to know the way to make to get timestamped with an SHA256 signature.

[Stefan_M]

I changed the signature settings to:




the first line for SHA1 and the second line for SHA256

http://helpnet.flexerasoftware.com/installshield23helplib/helplibrary/whats_newIS2016.htm
Digital Signature Updates
Beginning with InstallShield 2015, support was added to enable you to use digital certificates that use the SHA-256 hashing algorithm for signing your installations and files at build time.

In InstallShield 2016, support for SHA-256 digital certificates has been enhanced for Windows Installer and InstallScript projects to:

• Give you the ability to specify a digest type using the new Signature Digest drop-down on the Certificate Selection Dialog Box
• RFC3161 timestamping is now supported and can be specified in settings.xml, noting that:
• DigitalSignature/@Timestamp can be an Authenticode or RFC3161 server for .msi, .exe, and .dll files
• DigitalSignature/@TimestampRFC3161 used for UWP app package files must be an RFC3161 server