Signing MSIX Packages

[kmantagi]

MSIX packages must be digitally signed for successful installation on endpoints. Unlike traditional packages like MSI, EXE, etc., 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 a safe and secured package.

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 important files – AppxBlockMap.xml and Appxsignature.p7x. AppxBlockMap.xml is automatically created while building an MSIX package. This file contains the list of all the application’s files along with their cryptographic hashes for each block of data. The Appxsignature.p7x file is added to the package during the signing and contains the signature information. Windows verifies the information in these two files to validate the integrity of the package and its content during installation and when launching the application. If the content of the package is found to have been tampered with, then Windows will block the application from launching. This ensures there is no opportunity for an attacker to add any malicious files into 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 with the Subject information of the digital certificate used to sign the package. If there is a mismatch, signing will fail. This mandatory requirement ensures that the package is always coming from a source who claims to be the proper source. It is possible for an attacker to inject a malicious file into a package and successfully build MSIX, but that will break the signature from the actual source. Trusted certificates are extremely sensitive assets, there is no way an attacker can get access to the trusted certificate from the actual source to sign the package again, so a tampered package will either have a broken signature or a false signature making it easy for the Windows OS to identify and flag such packages as untrusted, thus keeping your devices safe.

What are different methods one can 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. During the installation of a certificate (.pfx), the device will prompt for the certificate password, so you would not again need a certificate (.pfx) and the password during the signing, instead you will need to point to the installed certificate 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 them 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

After all the above prerequisites are met, run the command to sign MSIX using AzureSignTool while passing Application (client) ID, Client Secret, Time stamping server, and other required parameters. Azure Key Vault signing is well suited in a software development environment for signing MSIX packages in a CI/CD pipeline. Below is an example of the command for signing using AzureSignTool:

AzureSignTool sign -kvu "<URL of your Azure Key Vault>" -kvi "<Application (client) ID>" -kvs "<Client Secret>" -kvc "Name of the certificate in your Key Vault" -tr "Timestamp server URL" -v "Path of MSIX package"

How to sign MSIX packages?

You may use signtool.exe, a command-line tool in Windows SDK, for signing MSIX packages. Below is an example of how to use signtool for signing:

signtool.exe sign /f C:\Certs\TestCertifcate.pfx /p password /fd sha256 /tr http://timestamp.digicert.com "C:\TestPackage\SampleMSIX.msix"

However, AdminStudio tools like MSIX Editor, Application Manager, Automated Application Converter (AAC), and Repackager provide a simple and intuitive user interface to make signing MSIX packages easy. While you can use MSIX Editor and Application Manager to sign your existing MSIX packages, you can configure a digital certificate in Repackager and AAC to make signing part of the conversion process, so the output MSIX package is already signed and ready for deployment.

Can a self-signed certificate be used for signing MSIX packages?

It is a security best practice and a strong recommendation to always use a trusted certificate obtained from a CA, however, there could be few scenarios where the use of self-signed certificates is acceptable without posing a significant risk. Self-signed certificates could be used only when the MSIX packages are not to be distributed outside of an organization, for example, an in-house line of the business application meant for internal use. A packaging team within an organization may repackage certain vendor-supplied packages from MSI and/or EXE into MSIX format, such packages could be signed using a self-signed certificate for testing the deployment and installation however, to install MSIX packages signed with a self-signed certificate, the certificate must be installed into the certificate store of that computer and added to the Trusted Roots folder of the system store. Some benefits of using a self-signed certificate are that you can generate a self-signed certificate on your own without having to go through the hassle of getting it from a CA, so you can generate it and start using it right away, and it is free of cost.

Below you will find a simple PowerShell Script you may use to generate a self-signed certificate. When the script is executed, it will prompt for the Publisher name, password, and certificate file name. Provide the values as you desire to generate a self-signed certificate for testing your MSIX packages.

#Powershell script to generate a self-signed digital certificate (.pfx)

#============================================================================

$Publisher=Read-Host "Enter the Publisher name"
$CertificateName= Read-Host "Enter the certificate file name"
$Password= Read-host "Enter the password for the certificate"
$DirPath = "C:\Certificates" #NOTE: The certificate will be saved in this directory; you can change this directory path as you desire
if(-Not(Test-Path($DirPath)))
{
New-Item -ItemType directory -Path $DirPath
}
$FilePath="C:\Certificates\$Certificatename.pfx"
$Val= New-SelfSignedCertificate -type CodeSigningCert -Subject $Publisher -KeyUsage DigitalSignature -FriendlyName $CertificateName -CertStoreLocation "Cert:\LocalMachine"
$Key = $Val.Thumbprint
Get-ChildItem | Format-Table $Publisher, $CertificateName, $Key
$pwd = ConvertTo-SecureString -String $Password -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\LocalMachine\My\$Key" -FilePath $FilePath -Password $pwd 

Please comment if you have additional questions on signing or any other questions about MSIX packages. If you are curious about MSIX and would like to learn more about MSIX in detail, grab your free copy of the book ‘A Developer’s guide to MSIX’.