MSIX packages must be digitally signed for successful installation on endpoints. Unlike standard packages, this is a new and mandatory requirement for MSIX packages. While this might be one additional step in your application packaging process, signing makes MSIX safe and secure.

Why sign MSIX packages?

Signing adds integrity and trust to your package, hence enhancing the overall security of the package.

When the content of an MSIX package is extracted, among various other files and folders, you will see two essential files – AppxBlockMap.xml and Appxsignature.p7x. AppxBlockMap.xml is created while building an MSIX package. This file contains the list of all the application’s files and their cryptographic hashes for each data block. The Appxsignature.p7x file is added to the package during the signing and contains the signature information. Windows verifies the information in these files to validate the integrity of the package and its content during installation. If the content of the package is tampered with, then Windows will block the application from launching. This ensures no opportunity for an attacker to add malicious files to your package, so it is sure to contain only intended files placed there by the vendor or administrator that built it.

MSIX packages must be signed with a code-signing digital certificate with time stamping obtained from a publicly registered Certificate Authority (CA); only such will be considered trusted certificates. Microsoft updates the list of registered Certificate Authorities in the Windows OS; therefore, any package signed using a trusted certificate will be automatically trusted by the OS to install successfully. While signing an MSIX package, the Publisher name of the package in the AppxManifest.xml file must match the Subject information of the digital certificate used to sign the package. If there is a mismatch, the signing will fail. This mandatory requirement ensures that the package always comes from a source who claims to be the proper source. An attacker can inject a malicious file into a package and successfully build MSIX, breaking the signature from the actual source. Although trusted certificates are susceptible assets, there is no way an attacker can get access to the trusted certificate from the actual authority to sign the package again. A tampered package will either have a broken or a false signature, making it easy for Windows OS to identify and flag such packages as untrusted, thus keeping your devices safe.

What are the different methods one can use to sign MSIX packages?

Here are a few different ways of signing an MSIX package:

Digital Certificate File (.pfx): A code-signing trusted certificate, or a self-signed certificate, which contains both public and private keys, can be used to sign an MSIX package. This will also require a certificate password. It is strongly recommended to use time stamping while signing a package. Time stamping ensures the package installation does not fail even if the certificate is expired by assuring the Windows OS that the certificate was valid when the package was signed.

Certificate Store: MSIX packages can be signed using a certificate installed in the certificate store of a machine. While installing a certificate (.pfx), the device will prompt for the certificate password, so you will not again need a certificate (.pfx) and the password during the signing. Instead, you need to point to the certificate installed from the certificate store. Certificates could be installed on a device using a GPO or other mechanism. This method will be most appropriate when the preference is not to directly share the certificate file (.pfx) and password to avoid falling into the wrong hands, thus making it a more secure process.

Device Guard Signing: Device Guard Signing is a feature available in Microsoft Store for business. This method requires an Azure account and a Device Guard signer role in Microsoft Store for Business/Education.

Azure Key Vault: Azure Key Vault is one of the services in Azure to store sensitive data like connection strings etc. Azure Key Vault can also store digital certificates. Signing using Azure Key Vault requires the following prerequisites:

• An Azure account
• Creating/importing a certificate into Azure Key Vault
• Registering a new application in Azure and obtaining ‘Application (client) ID’ and ‘Client Secret.’
• Installing AzureSignTool through .Net Core CLI. The latest version of .Net Core SDK should be installed on the machine to use .Net Core CLI to install AzureSignTool

This article was recommended by Bob Kelly and written by his colleague with the handle kmantagi (Flexera)