Wix Burn fails to download exePackage

Question

I am using the exePackage attribute to download an exe pacakge - actually the VSTO runtime from microsoft.

It fails to get the package.

I believe this is the correct way to add it to the CHAIN

    <ExePackage Id="VSTORuntime" SourceFile="vstor_redist.exe" Permanent="yes" Vital="yes" Cache="no" Compressed="no"
            DownloadUrl="http://go.microsoft.com/fwlink/?LinkId=158917"
            PerMachine="yes"
            InstallCommand="/q /norestart"
            DetectCondition="VSTORFeature"
            InstallCondition="NOT VSTORFeature OR NOT (VSTORVersionV4R >=v10.0.40303) OR NOT (VSTORVersionV4 >=v10.0.21022)" />

This is the log file part. It does this about three times.

[0D98:06A8][2013-07-22T11:47:31]w343: Prompt for source of package: VSTORuntime, payload: VSTORuntime, path: F:\vstor_redist.exe
[0D98:06A8][2013-07-22T11:47:31]i338: Acquiring package: VSTORuntime, payload: VSTORuntime, download from: http://go.microsoft.com/fwlink/?LinkId=158917
[16A0:0BE4][2013-07-22T11:47:37]e000: Error 0x80070490: Failed to find expected public key in certificate chain.
[16A0:0BE4][2013-07-22T11:47:37]e000: Error 0x80070490: Failed to verify expected payload against actual certificate chain.
[16A0:0BE4][2013-07-22T11:47:37]e000: Error 0x80070490: Failed to verify signature of payload: VSTORuntime

Seriously nobody? Why. What is wrong with my code? This is a pretty common package to need and surely Microsoft has its packages signed etc. — darbid, Jul 25 '13 at 04:45
There are now 2 answers... could you please upvote the answer(s) that worked and comment on the answer(s) that did not work. Thanks! — Nicolas Raoul, Sep 17 '14 at 06:47

score 2 · Accepted Answer · answered Oct 10 '13 at 18:59

i think you need to specify Certificate key in the RemotePayload tag, like this :

<ExePackage Id="VSTORuntime" SourceFile="vstor_redist.exe" Permanent="yes" Vital="yes" Cache="no" Compressed="no"
        DownloadUrl="http://go.microsoft.com/fwlink/?LinkId=158917"
        PerMachine="yes"
        InstallCommand="/q /norestart"
        DetectCondition="VSTORFeature"
        InstallCondition="NOT VSTORFeature OR NOT (VSTORVersionV4R >=v10.0.40303) OR NOT (VSTORVersionV4 >=v10.0.21022)">
<RemotePayload ProductName="Windows Installer 4.5"
               Description="Windows Installer 4.5 Setup"
               CertificatePublicKey="F321408E7C51F8544B98E517D76A8334052E26E8"
               CertificateThumbprint="D57FAC60F1A8D34877AEB350E83F46F6EFC9E5F1"
               Hash="86E1CC622DBF4979717B8F76AD73220CDB70400B"
               Size="3327000"
               Version="4.5.0.0" />
</ExePackage>

it's just an idea ... or Try to use fiddler to find if they'r an error 404 or something like this ...

score 2 · Answer 2 · edited Sep 17 '14 at 06:45

2

I've encountered this problem when the bootstrapper bundle is compiled with one version of the exe package, but another version is sitting alongside the installer executable when you try to run it. I suspect that Burn automatically pulls the certificate information out of the source file when you compile the bundle.

If for example your Setup.exe file was in C:\Downloads and C:\Downloads also contains a version of vstor_redist.exe which is different to the one present when you built Setup.exe, you'll see this error. You can work around the problem by deleting vstor_redist.exe from C:\Downloads - Setup.exe will then go off and download the correct version from the URL you specified.

edited Sep 17 '14 at 06:45

Nicolas Raoul

58,567
58
222
373

answered Nov 12 '13 at 12:46

Samuel Jack

32,712
16
118
155

This was issue was tracked in https://github.com/wixtoolset/issues/issues/3640, and fixed in v4.0. A workaround from that issue - "I'm not sure how practical this is, but in v3.x a BA could call `IBootstrapperEngine::SetLocalSource` for every payload before calling Apply. It would set it to an absolute path that didn't exist in order to get the engine to skip the probing of local paths during the payload's acquisition, causing an `OnResolveSource` event." – Sean Hall Jan 13 '22 at 15:17

score 0 · Answer 3 · answered Jan 13 '22 at 15:15

It appears that Microsoft had updated the package behind that URL, and changed the certificate that was used to sign it. This is indistinguishable from an attacker serving up a malicious file, so the only thing you can do is build a new bundle from the new file with the updated certificate. In later versions of 3.x, you had to specify SuppressSignatureVerification="no" when not using RemotePayload and you wanted signature verification instead of hash verification.

Wix Burn fails to download exePackage

3 Answers3