Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a new code signing certificate for a sideloaded WinUI 3 app creates duplicate app installations #10006

Open
kirwan-safesurfer opened this issue Sep 22, 2024 · 1 comment
Labels
bug Something isn't working needs-triage Issue needs to be triaged by the area owners

Comments

@kirwan-safesurfer
Copy link

kirwan-safesurfer commented Sep 22, 2024

Describe the bug

We use DigiCert to sign our WinUI 3 app that we need to sideload (because our app isn't applicable for the Microsoft Store). If we package a new MSIX installer with a newly issued code signing certificate, this inadvertently treats the updated app installer as a new app, which means that two versions (an older and a newer) now exist on the client.

DigiCert state the following (for SSL/TLS certs, but it's still applicable):

Industry standards require Certificate Authorities to hard-code the expiration date into certificates. When a certificate expires, it is no longer valid and there is no way to extend its life. So, when you 'renew' your certificate, DigiCert must issue a new one to replace the expiring one, and you must install the new certificate on your server.

This Stack Overflow post is related (although I didn't get a warning that "a different package with the same name is already installed" for some reason): https://stackoverflow.com/questions/73155730/windows-considers-it-a-different-app-after-changing-signing-method

Steps to reproduce the bug

  1. Sign an app with a code signing certificate and install it on a client workstation.
  2. Sign the same app with a newly issued code signing certificate and attempt to install it on a client workstation. App Installer will treat the app as a new app (even though the package name is identical) and offer to "Install", rather than "Update".
  3. There are now two installations of the same app on the client workstation.

Expected behavior

App Installer should be looking for the package name (being Package.appxmanifest > Name="Company.AppName"), rather than the same certificate, because new code signing certificates for the same sideloaded app will need to be applied to updated versions of the app in the future.

Screenshots

No response

NuGet package version

None

Windows version

Windows 11 (22H2): Build 22621

Additional context

No response

@kirwan-safesurfer kirwan-safesurfer added the bug Something isn't working label Sep 22, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Sep 22, 2024
@whiskhub
Copy link

The package identity must stay identical, including the PublisherId. It is derived from the certificate, see microsoft/WindowsAppSDK#650.

If you are unable to convince the certificate authority to issue a certificate with the exact same identity string, it won't work. Starting Windows 11 there is a "fix" for it, but it's not a great one: https://learn.microsoft.com/en-us/windows/msix/package/persistent-identity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage Issue needs to be triaged by the area owners
Projects
None yet
Development

No branches or pull requests

2 participants