- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Error -6258. msi signing stopped working from one day to the next
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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 🙂
Thanks,
Sandra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
From support..
https://community.flexera.com/t5/InstallShield-Knowledge-Base/Build-Error-6259/ta-p/3726
I'm highly doubting all of us are experiencing issues related to this attempted fix.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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:
https://community.flexera.com/t5/InstallShield-Knowledge-Base/Build-Error-6259/ta-p/3726
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Agreed.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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 😉
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello,
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"
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@m_schmeller where do you mention the timestamp URL in Installshield ism project?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hello,
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"/> -->
<DigitalSignature Timestamp="http://timestamp.digicert.com/scripts/timstamp.dll"/>
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Worked here too! THANK YOU!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
I changed it to match what I saw in IS 2020's Settings.xml...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hi
I am using IS 2016, where can I change the setting.xml?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
THIS WAS IT!!!!!!!!!!!!!!
many thanx
Harald
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Thanks, this helped me out.
