Patching existing applications using a newer digital signature

[DLee65]

I am hoping someone in the community can point me in the right direction. I have an application that was signed with a digital signature that has since expired. We have renewed the digital signature and I have updated the setup so that it uses the new credentials for signing files. However, patching an existing setup creates problems.

To the msiDigitalCertificate table I have added the credentials used in the previous releases. In the msiPatchCertificate table I have added a reference to the msiDigitalCertificate table.

However, after installing the patch, I cannot run the application on XP. No errors occur display in the event viewer application view. If I run repair I get an error 1330 saying "A file that is required cannot be installed because the cabinet file \\server\app\feature1.cab has an invalid digital signature. This may indicate that the cabinet file is corrupt. Error 0 was returned by WinVerify Trust."

Obviously this is related to the digital signature. It appears after I patch that setup cannot resolve which signature applies to which file.

Is there a way to get digital signatures to work?

For Vista, at least the application starts, but then auto repair starts and the same 1330 error occurs.

Prior to having to updating the digital signature patches worked without problems.

Has anyone else had any experience / success with this or is a major upgrade the only solution?

Thanks.:confused:

EDIT: I am trying another build where I make sure in the msiDigitalCertificate table I use the same name for the certificate. In my first tests I had given it a different name. It just occurred to me that the msiPatchCertificate would be using a lookup to the other table and will get confused with names.

[DLee65]

Well my attempt at making sure the DigitalCertificate value was the same as the original application, ReleaseCertificate1, did not work.

I had streamed the certificate information from the original install and then imported this into the msiDigitalCertificate table, thinking this was the right thing to do, however, now I am not sure.

Any ideas on what to look at next?

Thanks.

[MichaelU]

Does the signature on \\server\app\feature1.cab have a timestamp? If not, and the certificate has since expired, that would explain why the signature is invalid. If that's the case, I doubt the row keys for your certificates will matter (although if you're just making the previous one use the same, and the new one use a new row, that's a good thing). I'm not sure what you can do short of avoiding that cab; since auto-repair certainly can refer to it, the major upgrade sounds best to me. If the cab is timestamped, this might require better ideas.

[DLee65]

Thanks for the reply MichaelU.

I checked the release and the .cab file does have a timestamp.

However, I noticed something interesting. There is a feature.cab file which has a digitial signature and has a timestamp. However, there is also a feature1.cab that does NOT have a digital signature. It appears that the .cab was divided due to size (e.g., feature1.cab is ~512MB, feature.cab is ~141MB).

[DLee65]

I also noted that repair is choking on the feature1.cab and not the feature.cab. Now this may be just coincidental.

I have submitted a ticket to InstallShield but I am also going to follow up with verisign to see if they have any ideas either. Hopefully somewhere in this mess I can find a way to avoid the large cost of uninstalling and reinstalling our application.

[DLee65]

In the June 2008 release of our product the Core1.cab file was not signed. However, in the October 2008 SP1 release it was signed. So I decided to try installing with SP1 installed instead of the original release.

I did this and then ran the minor update. Below is the information found in the event viewer that triggers the resiliency install. Something is screwed up.

Detection of product '{3237E527-970C-420E-AA6E-E75918BF806C}', feature 'Core', component '{58724586-8E73-CB9E-1943-AEFF7EA8ABB0}' failed.  The resource 'C:\Program Files\DeLorme\XMap 6\XMap6CustomRequired.df2' does not exist.

The event viewer reports that the minor upgrade succeeded. However, when I try to run the app the above shows up.

Another event viewer entry

Detection of product '{3237E527-970C-420E-AA6E-E75918BF806C}', feature 'Core' failed during request for component '{F07F5E83-6A29-6828-BD4C-77858368C264}'

[DLee65]

Well, here is what I think is happening so far. I still do not have a solution to this. InstallShield support was not able to come up with anything and I am now working with Microsoft to attempt a solution.

Basically the following happens:
1. User installs the original 6.0 release that is signed with the now expired certificate.
2. User installs the new 6.2 patch that is signed with the new certificate. The setup on which the 6.2 patch is based is signed using the new certificate as well.
3. In a repair scenario, the contents of the cached MSI and the cached MSP are merged. The cached MSP thinks that the the .CAB files referenced in the msiDigitalSignature table are signed with the latest certificate. When setup tries to authenticate the .CAB files it fails because it is not signed with the newest certificate.

The bug / problem here is that when a patch is created, it should ignore changes to the msiDigitalSignature table and not include these changes in the transforms used to make the .msp.

Another possible solution is that Windows Installer, if the first credential check fails, should go back and look at the msiDigitalCertificate table. If the cab file is signed with any of the records in here then it should authenticate the .CAB file and continue.

[DLee65]

I have found one bug, but it was not the magic bullet fix that I was hoping for.

Using DirectEditor in IS2008 and IS2009, try to add a new record to the msiDigitalCertificate table. Click in the CertData cell and import a valid CER file.

After the import finishes, click again, but this time choose to save the binary data to a file - specify a different file name than the first file.

After the file has been saved use a good binary diff tool such as Beyond Compare to compare the two files. The two files will be vastly different when they should be identical.

Now, make sure the ISM file format is binary. Close the project file and then use Orca to open the .ISM file. Goto the msiDigitalCertificate table and try to import the cer file. After save the project file. Open the project back in InstallShield and save the file as a unique filename. Now do a difference between the original and the new files. They are the same.

So basically all my testing and trials over the last two weeks were bogus because I was working on the assumption that the CER file I had added to the .ISM file was the same as the one I used to sign the original setup.

I have reported this finding to Acresso.

After fixing the ISM using Orca, I did a quick test and the test failed, I am still getting an error 1330 when trying to do a repair after installing a patch. Also I am being prompted for an administrator password on Vista when trying to patch as a standard user account. *SIGH* I was sooo hoping this was my magic bullet.

However, I need to retest my other possible solutions such as modifying the msiDigitalSignatures table prior to building the patch. Basically I am trying to trick the patch to use the original certificate when validating .CAB files on the user's machine.

[loralynne]

I'm having the same problem. In our product, say version 1.0.1, that has been released, the installer was signed (including a timestamp) with a certificate that is now expired. I'm now working on version 1.0.2 which is being signed with a different certificate. I created a patch, but I'm also getting error 1330 when I run the patch.

Did this problem ever get resolved?

Thanks,
Lora

[DLee65]

Lora,

Unfortunately there isn't a very pretty answer.

1. If your current license has not expired then you can add the certificate to the MsiDigitalCertificate and MsiDigitalSignatureTable yourself. I forget how I had worked out this process as it was nearly six months ago and it wasn't a solution that we could pursue since our certificate had expired. The idea is to document all previous patch signatures - but this requires that the signature used in those patches not be expired.

2. Perform a major upgrade - this is the safest alternative and the alternative we chose. It was a costly choice but the least problematic. Fortunately for us there were other business decisions that also led to the need to make this a major upgrade as well.

3. I believe I was also working on another solution which would would work for one and only one patch cycle. It involves building the MSI, then modifying the MsiDigitalCertificate and MsiDigitalSignatureTable before building the patch.

I still have the perl script that I created to do #3 but unfortunately I will not have time to interpolate the perl language if you are not familiar with it. Hopefully you understand it. There are several script files in the zip file I included - mainly to give you context if you need it.

[loralynne]

Thanks for your input DLee65. I actually tried adding the certificate to the MsiDigitalCertificate and MsiPatchCertificate tables, but that didn't seem to work for me.

I ended up reporting an incident to InstallShield, and they suggested creating a transform. So I'm going to try that.

Thanks,
Lora

[loralynne]

I encountered this error again, and the way I fixed it was in the ism file, I changed the "Sign Output Files" setting from "Setup.exe and Windows Installer Package" to "None". After I build the installer, I have a script that signs *.mst, *.cab, and the .msi file.