SMadden
Pilgrim

Error -6258. msi signing stopped working from one day to the next

Hi,

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
Labels (1)
0 Kudos
40 Replies
rbaiwar
Flexera beginner

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.

0 Kudos
Superfreak3
Occasional contributor

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.

0 Kudos
Superfreak3
Occasional contributor

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!

0 Kudos
siever
Occasional contributor

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.

0 Kudos
Superfreak3
Occasional contributor

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.

0 Kudos

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.

0 Kudos
Superfreak3
Occasional contributor

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!

0 Kudos

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.

0 Kudos

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 😉

0 Kudos
Superfreak3
Occasional contributor

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.

0 Kudos
m_schmeller
Occasional contributor

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"

@m_schmeller  where do you mention the timestamp URL in Installshield ism project?

0 Kudos

Awesome. Thanks a lot. That worked. You are a savior Man 🙂
0 Kudos
siever
Occasional contributor

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"/>

Superfreak3
Occasional contributor

Worked here too!  THANK YOU!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

0 Kudos
Superfreak3
Occasional contributor

I changed it to match what I saw in IS 2020's Settings.xml...

Screenshot 2020-12-30 110322.png

0 Kudos

Hi

I am using IS 2016, where can I change the setting.xml?

0 Kudos

THIS WAS IT!!!!!!!!!!!!!!

many thanx

Harald

0 Kudos

Thanks, this helped me out.

0 Kudos