EV code signing .msix packages that are published for sideloading

[mjhock]

I'm using VS to create an .msix package which is then uploaded to an installation location for clients to sideload. This is a LOB deployment that does not use Windows Store. Currently I sign with a .pfx certificate. I like this deployment because VS keeps the package versions nicely organized and the client gets all the updates automatically.

I want to update my code signing strategy to EV which uses a token USB key and signtool. However, I don't see a way to sign with EV within VS as a part of the "publish" function. So, I may need to publish the package unsigned and then sign the package prior to copying to installation location. I don't want to break the versioning stored within the .appackage file.

This seems like complicated workflow. Is there a better way? Stick with .pfx signing?

[#2]

Hi @mjhock,

We do not currently support EV signing in the UWP/WapProj packaging wizard. Like you said, the only solution I can think of would be to package the application unsigned and then to sign it in some post-build step. Would you mind clarifying how this solution would "...break the versioning stored within the .appackage file."?

Thank you for your feedback. I will look into developing a solution that fits your needs.

Thank you,

James

[#3]

@japarson 

Within .appinstaller file is a <MainBundle class with, among other properties, a Publisher property. It appears that the Publisher information is lifted from the signing certificate. So I assume, if there's now signing until after the package is created, I may need to create this manually in the manifest.

The version appears to remain correctly incremented.

I need to figure out the workflow if I am to use an EV signature external to VS. There is a pause in the VS wizard after creation of the package where VS asks to "Copy and Close" (copy the package to the installation folder). I guess I could use signtool at this point and then complete publication by clicking the "Copy and Close" button. That could work (but an expensive experiment if it fails). Do I need to sign both the .appinstaller and .msixbundle files or just the .msixbundle file?

Also, if I use the .pfx technique, a certificate is included in the installation folder after "Copy and Close". No such certificate is included if I don't sign while creating the app package. If I then sign with an EV, I don't know if a certificate is added to the folder or if it's needed for successful publication.

So, I'm not really sure if pursing the EV technology is worthwhile at this point.

[#4]

In regard to the first paragraph in the last reply

"Within .appinstaller file is a <MainBundle class with, among other properties, a Publisher property. It appears that the Publisher information is lifted from the signing certificate. So I assume, if there's now signing until after the package is created, I may need to create this manually in the manifest."

The appinstaller file uses the package name and a hash of the publisher field of the manifest (equal to the subject field of the certificate) to form the full package name field that you must add. Once you know the hash, it remains the same. I have a blog https://www.tmurgent.com/TmBlog/?p=3270 that goes into the details on how it is generated, but if you sign something once you can install and look at the hash the installer used. So as long as you know the certificate you'll use, with this information you can know what to put into the appinstaller file prior to any signing.

As to the certificate inside the package, we should let Microsoft explain; I'm not sure what the value is if all of the exe files inside the package were also previously signed.

If the app is a LOB app for use only inside your own company, I don't see the value in an EV cert anyway.

[#5]

Hello. Are there any updates on this as of 2024?
We have the exact same issue here, and need a solution.