.NET 4.8 Redist signatures have changed -- causing install failures

muj-beg commented 2 months ago

WiX Version

5.0.0

.NET or MSBuild or Visual Studio Version

.NET 6, VS 2022 (build 17.10.1)

HeatWave Version

1.0.4

Windows Version

Win 11 (22H2)

Repro Repo

No response

Repro Steps

Create a bundled installer exe
Run the installer on a machine that does not have .NET 4.8 (ex: Windows Server 2016)

Actual Result

Installer tried to install .NET 4.8 and fails, with the following error messages in log:

Acquiring package: NetFx48Redist, payload: NetFx48Redist, download from: https://go.microsoft.com/fwlink/?linkid=2088631
Error 0x80070490: Failed to find expected public key in certificate chain.
Error 0x80070490: Failed to verify expected payload against actual certificate chain.
Error 0x80070490: Failed to verify signature of payload: NetFx48Redist

Note that this happens even when using an installer that was built previously and worked fine until July 8, 2024. I believe this is a recurrence of this old issue: https://github.com/wixtoolset/issues/issues/6438. Note that Microsoft changed the signature of the distributable on July 8th, 2024:

Expected Result

The installer should continue to function as before -- and not fail to install .NET 4.8

Acknowledgements

[X] I acknowledge that this is a fully completed bug report. It is not a question or attempt to get help debugging my issue (because those should be sent to Discussions).

bevanweiss commented 2 months ago

Whilst a quick fix for this might be to just reference the latest certificate thumbprint, perhaps an alternative verification method might be 'better'.

Is there a reason that Authenticode verification wouldn't be enough? https://learn.microsoft.com/en-au/windows/win32/api/wintrust/nf-wintrust-winverifytrustex

petm2022 commented 1 month ago

Has anybody talked with Microsoft about the problems it makes when they are changing the content in an existing download link?

I have now reported the problem here: https://developercommunity.visualstudio.com/t/Changing-content-in-existing-download-li/10705995

wmanning commented 1 month ago

Whilst a quick fix for this might be to just reference the latest certificate thumbprint, perhaps an alternative verification method might be 'better'.

Is there a reason that Authenticode verification wouldn't be enough? https://learn.microsoft.com/en-au/windows/win32/api/wintrust/nf-wintrust-winverifytrustex

It caused issues in the past. I can't remember the exact issues. I think issue is slowness and if certificates are not up to date but that could be wrong. https://github.com/wixtoolset/issues/issues/6447 In above link

We should consider making Authenticode verification only available to RemotePayloads. That is the minimal exposure required and removes the chance that someone 'accidentally' uses signature verification when hashing is superior.

wmanning commented 1 month ago

bevanweiss commented 1 month ago

Has anybody talked with Microsoft about the problems it makes when they are changing the content in an existing download link?

I have now reported the problem here: https://developercommunity.visualstudio.com/t/Changing-content-in-existing-download-li/10705995

They have no choice, the digital certificate was expiring. Distributing such a file with an invalid certificate is pretty bad form, it would throw up complaints about the certificate not being valid. So they re-issued the download with an updated certificate. It's a relatively normal activity.. much like a web server renewing their SSL certificates. It's also unlikely that Microsoft will consider dropping their older permalinks, since they use them themselves in various places to retrieve the distributables (for which I've only known them to use Authenticode to validate).

It's in an area of code that looks a little tricky for me to attack at this stage. But if it's still open next week I might look into it (providing an option for Authenticode).

ToreDemant commented 1 month ago

@bevanweiss is that really true?

I would think that the sign is still okay as long as it was done before the certificate expired and as long as the certificate has not been revoked.

bevanweiss commented 1 month ago

The sign is only still valid if the package was Timestamped. I also believe that the Timestamp server must be online and accessible to validate the hash against the timestamp. So for offline usage, I’m pretty sure the signing cert must be valid at the time of usage. If there’s references to contradict that, I’m happy to be corrected :) https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653556(v=vs.85)?redirectedfrom=MSDN

Certificates normally expire after a period of time, such as one year. However, software is typically designed to operate for many years. If the certificate that was used to sign the code expires, the signature cannot be validated and the software might not install or run. To avoid this issue, Microsoft recommends that software publishers timestamp their digital signatures.

jchoover commented 1 month ago

Also worth mentioning, they only resigned the full package and not the web package.

barnson commented 3 weeks ago

Need to investigate:

Does new Azure trusted signing result in thumbprint changes that would invalidate signature checking even faster than expiration does now?
Are there things other than the thumbprint we can check?
Falling back to "is it signed?" is problematic for layouts, because they're not secure.

wixtoolset / issues