First published on MSDN on Sep 06, 2018
So, as we noticed a certificate is needed to sign the MSIX package.
Especially for those with a history in packaging, signing an AppX/MSIX-package could potentially be the first time you're ever faced with the requirement. So….
Why should we sign packages?
Signing code or binaries nowadays is common practice. Starting with executables, drivers and scripts code signing ensures source, integrity and alignment with release processes of the given code. Starting with Microsoft Store this was introduced into Windows as a requirement to deploy AppX successfully.
Beside the use in production environments, during package creation and testing there are possibilities to bypass this requirement.
We have 2.5 options:
How to configure the PKI for code signing certificates:
Since we got no test environment set up whatsoever, that would be the 0.5 option
What to do when
Focusing on AppX/MSIX there are four major scenarios present with different possibilities:
During packaging Codesigning can be bypassed via the Developer-Mode in Windows 10.
Developer-Mode will not help during package testing. Best would be to Test-Sign the package internally with your own PKI infrastructure or a Self-Signed Certificate:
Private Deployment means deployment only on company owned and managed devices. In this case code signing using your PKI infrastructure is perfectly fine and the most stable implementation.
Having a public deployment on an AppX/MSIX package most likely means uploading it to Microsoft Store. Only once you need to create a developer account for your company, which will give you access to the required upload area. During the process of final package checks the package will automatically get signed and all Windows 10 Clients will trust the resulting package.
Ingmar Oosterhoff, Johannes Freundorfer and Matthias Herfurth
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.