EV code signing .msix packages that are published for sideloading

%3CLINGO-SUB%20id%3D%22lingo-sub-2313604%22%20slang%3D%22en-US%22%3EEV%20code%20signing%20.msix%20packages%20that%20are%20published%20for%20sideloading%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2313604%22%20slang%3D%22en-US%22%3E%3CP%3EI'm%20using%20VS%20to%20create%20an%20.msix%20package%20which%20is%20then%20uploaded%20to%20an%20installation%20location%20for%20clients%20to%20sideload.%20This%20is%20a%20LOB%20deployment%20that%20does%20not%20use%20Windows%20Store.%20Currently%20I%20sign%20with%20a%20.pfx%20certificate.%20I%20like%20this%20deployment%20because%20VS%20keeps%20the%20package%20versions%20nicely%20organized%20and%20the%20client%20gets%20all%20the%20updates%20automatically.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20want%20to%20update%20my%20code%20signing%20strategy%20to%20EV%20which%20uses%20a%20token%20USB%20key%20and%20signtool.%20However%2C%20I%20don't%20see%20a%20way%20to%20sign%20with%20EV%20within%20VS%20as%20a%20part%20of%20the%20%22publish%22%20function.%20So%2C%20I%20may%20need%20to%20publish%20the%20package%20unsigned%20and%20then%20sign%20the%20package%20prior%20to%20copying%20to%20installation%20location.%20I%20don't%20want%20to%20break%20the%20versioning%20stored%20within%20the%20.appackage%20file.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20seems%20like%20complicated%20workflow.%20Is%20there%20a%20better%20way%3F%20Stick%20with%20.pfx%20signing%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2337181%22%20slang%3D%22en-US%22%3ERe%3A%20EV%20code%20signing%20.msix%20packages%20that%20are%20published%20for%20sideloading%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2337181%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F692340%22%20target%3D%22_blank%22%3E%40mjhock%3C%2FA%3E%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWe%20do%20not%20currently%20support%20EV%20signing%20in%20the%20UWP%2FWapProj%20packaging%20wizard.%20Like%20you%20said%2C%20the%20only%20solution%20I%20can%20think%20of%20would%20be%20to%20package%20the%20application%20unsigned%20and%20then%20to%20sign%20it%20in%20some%20post-build%20step.%20Would%20you%20mind%20clarifying%20how%20this%20solution%20would%20%22%3CSPAN%3E...break%20the%20versioning%20stored%20within%20the%20.appackage%20file.%3C%2FSPAN%3E%22%3F%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThank%20you%20for%20your%20feedback.%20I%20will%20look%20into%20developing%20a%20solution%20that%20fits%20your%20needs.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThank%20you%2C%3C%2FP%3E%0A%3CP%3EJames%3C%2FP%3E%3C%2FLINGO-BODY%3E
New Contributor

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 Replies

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

@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.