|
|
I have a package that released in June that was digitally signed with
credentials that have since expired. We have a new digital certificate
from verisign and have applied that to the current MSI setup build.
However, I cannot get the patches to work correctly.
1. I exported the digital signature from the original release and
imported it into the msiDigitalCertificate table.
2. I then created a new record in the msiPatchCertificate that points
to this entry.
3. I can install the minor upgrade and I can view the INSTALLDIR and
verify that the new files are present.
4. However, I cannot run the application. I double click on the EXE
and nothing happens. No errors in the EventViewer, no MSI Log files,
notta! So I am flying blind here for debugging the issue.
5. If I go to Programs and Features and try to run repair on the
installation I get the error 1330 "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."
Any ideas on what I can do to accommodate the previous digital
signature?
|
|
I have also noticed the following items:
1. My installation development software divides the feature.cab file
into two files, feature.cab and feature1.cab. Feature.cab is signed
while feature1.cab is not signed.
2. All other CAB files are signed and have a timestamp.
I am beginning to wonder if we have done something wrong when getting
a new digital signature. I wonder if there was a way to simply upgrade
our current license so that the expiration date is extended to 2011?
Any ideas out there? Thanks.
|
|
"Install.Me.Dan" <Daniel.Lee.ME[ at ]gmail.com> wrote in message
news:65020feb-e5d6-4c43-b171-742cecf6d8cc[ at ]o40g2000prn.googlegroups.com...
[Quoted Text] > I have also noticed the following items:
> 1. My installation development software divides the feature.cab file
> into two files, feature.cab and feature1.cab. Feature.cab is signed
> while feature1.cab is not signed.
> 2. All other CAB files are signed and have a timestamp.
> I am beginning to wonder if we have done something wrong when getting
> a new digital signature. I wonder if there was a way to simply upgrade
> our current license so that the expiration date is extended to 2011?
> Any ideas out there? Thanks.
AFAIK there's no way to "extend" the lifetime of the signature so you are
stuck with finding a solution to your problem.
Let's see if I got this right. Your original MSI's MsiDigitalCertificate
table contained certificate data [from OLDcert - it was ok in June but is
expired now] and you used OLDcert to sign feature.cab. The original MSI
contains MsiDigitalSignature table with mapping between the Media table
entry for feature.cab and OLDcert. There is no signature on feature1.cab
and so there is no MsiDigitalSignature entry mapping it to OLDcert.
Not sure why you mentioned MsiPatchCertificate... this only has to do with
MSP signatures not external CABs.
Now you have created a minor upgrade but are using a new certificate
[NEWcert]. What did is in these various tables now?
Is it possible that feature1.cab is accidentally listed in
MsiDigitalSignature associating it with NEWcert or OLDcert for that matter?
What I would be afraid of here is the old cached MSI being used somehow with
new cabs (which would have mismatced certificate data). But that doesn't
explain why it stops on the unsigned cab rather than the signed one...
Sincerely,
Adrian Accinelli
|
|
On Nov 20, 7:54 pm, "Adrian Accinelli"
<hclnospamali...[ at ]newsgroup.nospam> wrote:
[Quoted Text] > "Install.Me.Dan" <Daniel.Lee...[ at ]gmail.com> wrote in message
>
> news:65020feb-e5d6-4c43-b171-742cecf6d8cc[ at ]o40g2000prn.googlegroups.com...
>
> > I have also noticed the following items:
> > 1. My installation development software divides the feature.cab file
> > into two files, feature.cab and feature1.cab. Feature.cab is signed
> > while feature1.cab is not signed.
> > 2. All other CAB files are signed and have a timestamp.
> > I am beginning to wonder if we have done something wrong when getting
> > a new digital signature. I wonder if there was a way to simply upgrade
> > our current license so that the expiration date is extended to 2011?
> > Any ideas out there? Thanks.
>
> AFAIK there's no way to "extend" the lifetime of the signature so you are
> stuck with finding a solution to your problem.
>
> Let's see if I got this right. Your original MSI's MsiDigitalCertificate
> table contained certificate data [from OLDcert - it was ok in June but is
> expired now] and you used OLDcert to sign feature.cab. The original MSI
> contains MsiDigitalSignature table with mapping between the Media table
> entry for feature.cab and OLDcert. There is no signature on feature1.cab
> and so there is no MsiDigitalSignature entry mapping it to OLDcert.
>
> Not sure why you mentioned MsiPatchCertificate... this only has to do with
> MSP signatures not external CABs.
>
> Now you have created a minor upgrade but are using a new certificate
> [NEWcert]. What did is in these various tables now?
>
> Is it possible that feature1.cab is accidentally listed in
> MsiDigitalSignature associating it with NEWcert or OLDcert for that matter?
>
> What I would be afraid of here is the old cached MSI being used somehow with
> new cabs (which would have mismatced certificate data). But that doesn't
> explain why it stops on the unsigned cab rather than the signed one...
>
> Sincerely,
> Adrian Accinelli
Thanks for the reply.
Here is a timeline that should help clarify the situation.
June 2008 - release 6.0, msiDigitalCertificate = Old.Cer (feature1.cab
is listed in the signature table as being signed when in fact it is
not signed, all other cabs listed are signed)
Oct 2008 - release 6.1, msiDigitalCertificate = Old.Cer (feature1.cab
and all other cabs are now signed - we did not know about feature1.cab
NOT being signed in 6.0 but patching and repair are not affected by
this)
Nov 2008 - developing 6.2 msiDigitalCertificate = New.Cer (all cabs
are signed)
If I install 6.1 and run the patch, I still get the 1330 error. The
interesting thing to me is that the error reports WinVerify return
Error 0, which according to MSDN is ERROR_SUCCESS, meaning it passes.
In the MSI log file, the repair errors out when trying to get a file
from the original media. The original media is accessible by the test
machine. The file is drvfp.hlp, which is a file from a third party
merge module.
If I build a patch from a setup build that is not signed and install
that with 6.0 or 6.1 then repair works correctly after the patch is
applied.
It seems to me that the scenario we are seeking should be possible,
patch a previous install using a newer cert file and still have
resiliency work as expected following the patch.
I will probably be making a call to Microsoft today to open a ticket
with them. I am just trying to rule out 'operator error' (e.g., me
making a mistake) as a factor in this process. :)
Thanks for any help anyone can provide.
|
|
"Install.Me.Dan" <Daniel.Lee.ME[ at ]gmail.com> wrote in message
news:de7ac4cf-99ce-4706-9109-c740c153b1f4[ at ]t39g2000prh.googlegroups.com...
[Quoted Text] > On Nov 20, 7:54 pm, "Adrian Accinelli"
> <hclnospamali...[ at ]newsgroup.nospam> wrote:
>> "Install.Me.Dan" <Daniel.Lee...[ at ]gmail.com> wrote in message
>> news:65020feb-e5d6-4c43-b171-742cecf6d8cc[ at ]o40g2000prn.googlegroups.com...
>>> I have also noticed the following items:
>>> 1. My installation development software divides the feature.cab file
>>> into two files, feature.cab and feature1.cab. Feature.cab is signed
>>> while feature1.cab is not signed.
>>> 2. All other CAB files are signed and have a timestamp.
>>> I am beginning to wonder if we have done something wrong when getting
>>> a new digital signature. I wonder if there was a way to simply upgrade
>>> our current license so that the expiration date is extended to 2011?
>>> Any ideas out there? Thanks.
>> AFAIK there's no way to "extend" the lifetime of the signature so you are
>> stuck with finding a solution to your problem.
>> Let's see if I got this right. Your original MSI's MsiDigitalCertificate
>> table contained certificate data [from OLDcert - it was ok in June but is
>> expired now] and you used OLDcert to sign feature.cab. The original MSI
>> contains MsiDigitalSignature table with mapping between the Media table
>> entry for feature.cab and OLDcert. There is no signature on feature1.cab
>> and so there is no MsiDigitalSignature entry mapping it to OLDcert.
>> Not sure why you mentioned MsiPatchCertificate... this only has to do
>> with MSP signatures not external CABs.
>> Now you have created a minor upgrade but are using a new certificate
>> [NEWcert]. What did is in these various tables now?
>> Is it possible that feature1.cab is accidentally listed in
>> MsiDigitalSignature associating it with NEWcert or OLDcert for that
>> matter?
>> What I would be afraid of here is the old cached MSI being used
>> somehow with new cabs (which would have mismatced certificate data).
>> But that doesn't explain why it stops on the unsigned cab rather than
>> the signed one...
>> Sincerely,
>> Adrian Accinelli
> Thanks for the reply.
> Here is a timeline that should help clarify the situation.
> June 2008 - release 6.0, msiDigitalCertificate = Old.Cer (feature1.cab
> is listed in the signature table as being signed when in fact it is
> not signed, all other cabs listed are signed)
> Oct 2008 - release 6.1, msiDigitalCertificate = Old.Cer (feature1.cab
> and all other cabs are now signed - we did not know about feature1.cab
> NOT being signed in 6.0 but patching and repair are not affected by
> this)
> Nov 2008 - developing 6.2 msiDigitalCertificate = New.Cer (all cabs
> are signed)
> If I install 6.1 and run the patch, I still get the 1330 error. The
> interesting thing to me is that the error reports WinVerify return
> Error 0, which according to MSDN is ERROR_SUCCESS, meaning it passes.
> In the MSI log file, the repair errors out when trying to get a file
> from the original media. The original media is accessible by the test
> machine. The file is drvfp.hlp, which is a file from a third party
> merge module.
> If I build a patch from a setup build that is not signed and install
> that with 6.0 or 6.1 then repair works correctly after the patch is
> applied.
> It seems to me that the scenario we are seeking should be possible,
> patch a previous install using a newer cert file and still have
> resiliency work as expected following the patch.
> I will probably be making a call to Microsoft today to open a ticket
> with them. I am just trying to rule out 'operator error' (e.g., me
> making a mistake) as a factor in this process. :)
> Thanks for any help anyone can provide.
Just a hunch but did you try renaming the cabinets in your upgraded image?
The idea being that old files from the RTM package would reference the
original cabs and all existing links between Media/File/MsiDigitalSignature
and MsiDigitalCertificate would remain as is.
With new cabinet you would have unique associations between NEWcert and
patched files (since File table sequence would be higher). At least this
way there's no possibility of original file X from feature1.cab trying to
resolve source from the updated feature1.cab or worse the Windows Installer
looking up the MsiDigitalCertificate table and expecting OLDcert but instead
getting NEWcert.
Also if you perform a repair from an upgraded administrative image you don't
have a problem right?
Sincerely,
Adrian Accinelli
|
|
On Nov 24, 12:32 pm, "Adrian Accinelli"
<hclnospamali...[ at ]newsgroup.nospam> wrote:
[Quoted Text] > "Install.Me.Dan" <Daniel.Lee...[ at ]gmail.com> wrote in message
>
> news:de7ac4cf-99ce-4706-9109-c740c153b1f4[ at ]t39g2000prh.googlegroups.com...
>
>
>
> > On Nov 20, 7:54 pm, "Adrian Accinelli"
> > <hclnospamali...[ at ]newsgroup.nospam> wrote:
> >> "Install.Me.Dan" <Daniel.Lee...[ at ]gmail.com> wrote in message
> >>news:65020feb-e5d6-4c43-b171-742cecf6d8cc[ at ]o40g2000prn.googlegroups.com....
> >>> I have also noticed the following items:
> >>> 1. My installation development software divides the feature.cab file
> >>> into two files, feature.cab and feature1.cab. Feature.cab is signed
> >>> while feature1.cab is not signed.
> >>> 2. All other CAB files are signed and have a timestamp.
> >>> I am beginning to wonder if we have done something wrong when getting
> >>> a new digital signature. I wonder if there was a way to simply upgrade
> >>> our current license so that the expiration date is extended to 2011?
> >>> Any ideas out there? Thanks.
> >> AFAIK there's no way to "extend" the lifetime of the signature so you are
> >> stuck with finding a solution to your problem.
> >> Let's see if I got this right. Your original MSI's MsiDigitalCertificate
> >> table contained certificate data [from OLDcert - it was ok in June but is
> >> expired now] and you used OLDcert to sign feature.cab. The original MSI
> >> contains MsiDigitalSignature table with mapping between the Media table
> >> entry for feature.cab and OLDcert. There is no signature on feature1.cab
> >> and so there is no MsiDigitalSignature entry mapping it to OLDcert.
> >> Not sure why you mentioned MsiPatchCertificate... this only has to do
> >> with MSP signatures not external CABs.
> >> Now you have created a minor upgrade but are using a new certificate
> >> [NEWcert]. What did is in these various tables now?
> >> Is it possible that feature1.cab is accidentally listed in
> >> MsiDigitalSignature associating it with NEWcert or OLDcert for that
> >> matter?
> >> What I would be afraid of here is the old cached MSI being used
> >> somehow with new cabs (which would have mismatced certificate data).
> >> But that doesn't explain why it stops on the unsigned cab rather than
> >> the signed one...
> >> Sincerely,
> >> Adrian Accinelli
> > Thanks for the reply.
> > Here is a timeline that should help clarify the situation.
> > June 2008 - release 6.0, msiDigitalCertificate = Old.Cer (feature1.cab
> > is listed in the signature table as being signed when in fact it is
> > not signed, all other cabs listed are signed)
> > Oct 2008 - release 6.1, msiDigitalCertificate = Old.Cer (feature1.cab
> > and all other cabs are now signed - we did not know about feature1.cab
> > NOT being signed in 6.0 but patching and repair are not affected by
> > this)
> > Nov 2008 - developing 6.2 msiDigitalCertificate = New.Cer (all cabs
> > are signed)
> > If I install 6.1 and run the patch, I still get the 1330 error. The
> > interesting thing to me is that the error reports WinVerify return
> > Error 0, which according to MSDN is ERROR_SUCCESS, meaning it passes.
> > In the MSI log file, the repair errors out when trying to get a file
> > from the original media. The original media is accessible by the test
> > machine. The file is drvfp.hlp, which is a file from a third party
> > merge module.
> > If I build a patch from a setup build that is not signed and install
> > that with 6.0 or 6.1 then repair works correctly after the patch is
> > applied.
> > It seems to me that the scenario we are seeking should be possible,
> > patch a previous install using a newer cert file and still have
> > resiliency work as expected following the patch.
> > I will probably be making a call to Microsoft today to open a ticket
> > with them. I am just trying to rule out 'operator error' (e.g., me
> > making a mistake) as a factor in this process. :)
> > Thanks for any help anyone can provide.
>
> Just a hunch but did you try renaming the cabinets in your upgraded image?
> The idea being that old files from the RTM package would reference the
> original cabs and all existing links between Media/File/MsiDigitalSignature
> and MsiDigitalCertificate would remain as is.
>
> With new cabinet you would have unique associations between NEWcert and
> patched files (since File table sequence would be higher). At least this
> way there's no possibility of original file X from feature1.cab trying to
> resolve source from the updated feature1.cab or worse the Windows Installer
> looking up the MsiDigitalCertificate table and expecting OLDcert but instead
> getting NEWcert.
>
> Also if you perform a repair from an upgraded administrative image you don't
> have a problem right?
>
> Sincerely,
> Adrian Accinelli
Hmm, is this possible without creating new features which would
necessitate a major upgrade?
I have not tried this approach. According to the online documentation
for upgrades and digital signatures is that the process I am using now
should work.
|
|
"Install.Me.Dan" <Daniel.Lee.ME[ at ]gmail.com> wrote in message
news:f0a8294b-a1b6-4796-a2cd-ccd3fc17819d[ at ]t39g2000prh.googlegroups.com...
< SNIP >
[Quoted Text] >> Just a hunch but did you try renaming the cabinets in your upgraded
>> image? The idea being that old files from the RTM package would
>> reference the original cabs and all existing links between
>> Media/File/MsiDigitalSignature and MsiDigitalCertificate would remain
>> as is.
>> With new cabinet you would have unique associations between NEWcert and
>> patched files (since File table sequence would be higher). At least this
>> way there's no possibility of original file X from feature1.cab trying to
>> resolve source from the updated feature1.cab or worse the Windows
>> Installer looking up the MsiDigitalCertificate table and expecting
>> OLDcert but instead getting NEWcert.
>> Also if you perform a repair from an upgraded administrative image you
>> don't have a problem right?
>> Sincerely,
>> Adrian Accinelli
> Hmm, is this possible without creating new features which would
> necessitate a major upgrade?
> I have not tried this approach. According to the online documentation
> for upgrades and digital signatures is that the process I am using now
> should work.
Whatever the solution I don't think new features will be required. It's
more of a Media table/source resolution issue I believe.
It seems to me that the installation is failing because it is trying to
resolve the source for the RTM version of your files. The signature change
clearly causes this somehow but the question is how did Microsoft expect it
to work in the first place?
Does your original June MSI with external cabs signed with expired
certificates still install? I'm interested to know what Windows Installer
does when it hits expired cabs in a "Not Installed" scenario.
If it doesn't work at all then you shouldn't expect a patch of the same
product and source to work either and I would classify this behaviour as "by
design". In essence if this is the case you are supposed to tell your
customers to update their source locations for your product and invalidate
all cached MSI files [essentially patching through REINSTALL=vmous and new
source image rather than MSP]. Once you have updated to the new source (at
least once) then subsequence MSP files can be applied.
If it does work then what you are seeing is probably a bug in Windows
Installer itself. I say that because there should not be a difference in
source resolution between original install and patch/repair and clearly you
are seeing a difference. I'd classify that as a bug (perhaps a design
flaw). Of course the same source image swap during repair should ALSO work
in this case as a workaround.
Sincerely,
Adrian Accinelli
|
|
It appears that the problem is created by the cached MSI and merging
changes from the .MSP file in a repair scenario.
1. The msiDigitalSignature table for 6.0 has records that point to the
old certificate. This is accurate for the 6.0 version.
2. When the .msp file is merged in a repair process, the transforms
within the .msp now change the value of the records in the
msiDigitalSignatures table. This makes the setup think that the .cab
files from the 6.0 setup should be signed with the new certificate.
This is false.
I wish I had the ability to tell the patch creation process to ignore
any changes in the msiDigitalSignature table, since these changes are
never applicable to the original source files.
|
|
"Install.Me.Dan" <Daniel.Lee.ME[ at ]gmail.com> wrote in message
news:4b904473-2ee1-4bc1-9b10-aec4a83362fa[ at ]e1g2000pra.googlegroups.com...
[Quoted Text] > It appears that the problem is created by the cached MSI and merging
> changes from the .MSP file in a repair scenario.
> 1. The msiDigitalSignature table for 6.0 has records that point to the
> old certificate. This is accurate for the 6.0 version.
> 2. When the .msp file is merged in a repair process, the transforms
> within the .msp now change the value of the records in the
> msiDigitalSignatures table. This makes the setup think that the .cab
> files from the 6.0 setup should be signed with the new certificate.
> This is false.
> I wish I had the ability to tell the patch creation process to ignore
> any changes in the msiDigitalSignature table, since these changes are
> never applicable to the original source files.
Ok this explains why it fails. Bottomline is that *you* have complete
control over the MSP creation but maybe not over the tool that initiates it.
For instance to prevent msiDigitalSignature table from being modified you
just have to ensure that the MSI file that is pointed to by each
UpgradedImages PK in your PCP file *does not have the change*.
When you are "manually" building admin images for Upgraded Images use this
is easy since you just don't modify the table but if you are using a tool to
rebuild your MSI for this purpose you will have to perform an extra step
before you start the MSP creation process itself. Ultimately the how is up
to you and your environment but in general you could use a script or even a
transform to "undo" the changes to MsiDigitalSignature table. Worst case
you can can drop the table and insert a new one (from extracted IDT of RTM
Msi even).
The final result is that if there are no changes to MsiDigitalSignature
table when msimsp/patchwiz.dll does its job then the final MSP will not
contain the problematic changes you discovered.
Sincerely,
Adrian Accinelli
|
|
|