Error -6258. msi signing stopped working from one day to the next
Over the long Thanksgiving weekend all our builds that sign the windows installer package have stopped working. No code or system changes were made. I triple checked that the signing certificate is still valid for another 6 months and that it's not corrupt. It's the same on all build servers and my local dev machine. We use a pfx with password. The certificate was created using SHA-1, which will be deprecated, but according to the documentation it should still work if the certificate was created before Jan 1st 2016 (which it was).
I'm running out of ideas what it could be. Did anybody else run into an issue like this before? Here is the full error.
Media table successfully built
Started signing certificate.msi ...
ISDEV : error -6258: An error occurred extracting digital signature information from file "...\PROJECT_ASSISTANT\Interm\certificate.msi". Make sure the digital signature information provided in the IDE is correct.
Started signing BCU.msi ...
ISDEV : error -6258: An error occurred extracting digital signature information from file "...\BCU\PROJECT_ASSISTANT\SINGLE_EXE_IMAGE\DiskImages\DISK1\BCU.msi". Make sure the digital signature information provided in the IDE is correct.
ISDEV : error -6003: An error occurred streaming '...\PROJECT_ASSISTANT\SINGLE_EXE_IMAGE\DiskImages\DISK1\BCU.isc' into setup.exe
Any suggestions on what to try are welcome 🙂
Our certificate vendor is Digicert and we are still facing the same issue. It has something to do with Flexera and Installshield. Something changed between yesterday and today and Flexera team needs to provide with some help here. I think with so many people facing same issue today, it is established that something is wrong with Flexera/Installshield. Someone from the product team please help. All the builds are broken for us and we are stuck.
In my case, I temporarily worked around the issue by setting the Sign Output Files to None in the Releases view. This allows me to get installs to QA, but is in no way an acceptable solution for deployment to end users.
I've responded to support instructing them to check out this post!
Yes if I run the installation with Sign Output Files ="None" for sure this works fine but this is not my intension. All actions which are described in:
are not applicable for me. The same IS project was running a few days ago without the error. Other exe files by using the same certificate can be signed without any problems today.
Also, not sure if upgrading to 2020 will work for everyone as they may not have access to that release. I do and can move in that direction, but will wait to see if InstallShield remedies the problem for all, as they should.
This is very strange. It seems there is something in the InstallShield code that is date sensitive maybe to force upgrade or adhere to their end of life stance on certain versions.
We have about 40 installers in a single branch. So making a change to the installer ism does not seem to be a viable option assuming we have to change it back once there is some fix from Flexera. Thanks for suggesting the workaround of Signing the msi post build though.
No problem. I'm just scrambling to get things "working again". It will be a pain for me to0 as we have more than a few installation packages as well.
Looking into my crystal ball, I'm seeing InstallShield instructing to upgrade to 2020. We can upgrade to that version, but the problem is that I already have that version installed on a different server for a newer version of our product. I couldn't install that version on our other server as only one instance is allowed. To migrate the problematic version to that server would be a lot of work and we are nearing release.
In short, they better fix it!
Same thing is happening to me today too, on three build machines (one with full product, two with SAB utility) running InstallShield 2015. It was fine yesterday, and today is not. No code changes, no installer changes, and my certificate is valid through July 2023.
I have InstallShield 2020 and was planning an upgrade, but wasn't planning to be forced to upgrade today on-the-fly.
I've written how this issue can be workaround - I would suggest to use it, as this is a holiday season, so the Flexera team response probably will be slow. If they want to fix it 😉
I have a workaround idea in my head too....
Keep the Sign Output Files option off.
Use a pre-compression event to sign the .msi using SignTool
Use a post build step to sign the .exe using SignTool.
I'm not sure if this will work as there are items to be entered into the MsiDigitalCertificate table.
I'll get a build through without signing output and maybe play around with this hail mary.
Slow response due to the holiday or their desire to fix it is on them, but I do realize it is reality.
in our case the problem could be resolved by changing the timestamp server.
Installshield 2014 uses "http://timestamp.verisign.com/scripts/timstamp.dll" by default.
This timestamp url seems to be deprecated and its certificate was only valid until last night (30.12.2020 00:59:59).
We changed to the following timestamp url "http://timestamp.digicert.com"
yes that was the solution in our case:
We changed the code in "settings.xml" from verisign to digicert and now it does not throw out any errors.
Thanks to "m_schmeller"
<!-- <DigitalSignature Timestamp="http://timestamp.verisign.com/scripts/timstamp.dll"/> -->