MSIX and Code Signing Certificates: What Developers Must Know

Written by Tim Mangan (guest) · June 30th, 2021

While for MSIs, this was an optional step, signing your MSIX package is mandatory. Microsoft’s MSIX technology requires the use of code signing certificates to deploy packages.

Learn more about signing MSIX packages, the different methods and more in our MSIX Digital Signing article.

What are some tips and best practices that developers can follow to meet this requirement? That's what this post is about.

Enabling MSIX Digital Signing

Although developers can use “Developer Mode” to technically avoid the need for MSIX digital signing as they build and test their packages locally, this is not recommended for test machines. Instead, you should adjust your build process to include MSIX package signing to ensure the packages are signed.

Most third-party developed software uses certificates today, however, typically in-house developers and a lot of free tools do not use them. But even those using certificates today may need to be updated to make the move to signed MSIX packages.

To be able to deploy MSIX files outside of your development environment, MSIX packages must be signed using a code signing certificate that is trusted by the end device.

The subject field in the certificate, a string in the form “CN=xxx” must also be identical to a field in the AppXManifest.xml file that is contained inside of the package. The field in that XML file is called “Id” under the Properties element.

While it is not required that the executable files inside the package are signed, it is never a bad idea to sign those (at least those that aren’t redistributable components of others).

If you're working with an in-house app (not deployed to those outside of your company), you can use a self-signed certificate as I will cover later in this article. But, if your company is going to distribute the packages to people/customers outside of your company, then two different paths to take:

1. Using the Microsoft Store
2. Using private distribution channels

Using the Microsoft Store

Your company may or may not want to utilize the Microsoft Store for the distribution of your MSIX packaged software.

While Microsoft Store has benefits such as the potential of wider distribution, along with a built-in sales and auto-updates platform, it comes at a cost. And some companies prefer not to take that route.

If you are planning to use the Microsoft Store, there are some aspects you’ll need to consider for a successful submission process.

Ultimately, the package delivered from the Microsoft Store will be signed using a Microsoft Code Signing certificate that is trusted by default by every Windows machine. Microsoft takes care of the signing for you as part of the submission process.

Currently, you still have to sign the package yourself first to send it to them. And you must do so using a code signing certificate that they provide.

Here's how the process works:

1. Your company gets a developer account from Microsoft.
2. You log into the developer portal and reserve your product name.
3. You get a developer code signing cert from the portal.
4. You export the pfx file for your cert, preferably requiring a password.
5. You extract the subject name field and use it in your AppXManifest.xml file.
6. You sign the MSIX with that cert, and upload the signed package as part of your submission.
7. Microsoft re-signs with the public cert as part of the process.

Here is a step by step article on how to publish your MSIX package in the Microsoft Store.

In larger companies, the developer probably should not have access to that pfx file and password for that signing. A single “gatekeeper” inside your company will own that.

Usually, the gatekeeper is the only one that interacts with the developer portal, or acts as a signer and returns the signed package back to the developer. Then, the developer is the one who deals with the rest of the store. In this case, the developer signing the package may need to use a trusted “self-signed” certificate for internal testing.

The key to making this work is to ensure that the subject name of the self-signed certificate matches the developer certificate.

The self-signed certificate should have a short shelf life and should only be installed on test machines that need it. The process works like this:

1. The developer signs the package using the self-signed certificate for internal testing,
2. The gatekeeper re-signs using the developer certificate from Microsoft,
3. Finally Microsoft re-signs it.

If you are using Advanced Installer to create the package, you can specify your own certificate in the Digital Signatures page, or create a self-signed certificate with one click. You must have the self-signed certificate installed into the local machine root certificate store of the build machine. You can find more information here.

Signing MSIX Packages Published via Private Distribution Channels

If you are not using the Microsoft Store for distribution, tyou have a couple of options to proceed.

If you only intend to distribute the software inside your company, you can use a self-signed certificate to sign the MSIX package.

Otherwise, you will want to purchase a certificate from a well-respected Certificate Authority and use that.

The Self-Signed Route

A Self-signed certificate is a certificate with an EKU for code signing. Self-signed certificates may be created in a variety of ways:

• A couple of PowerShell lines
• Active Directory Certificate Services

You will want to think about the expiration date for the certificate. My feeling is that if the package isn’t going to be re-signed by a gatekeeper, then code signing certificates should never expire. Unlike other uses of certificates, we are certifying that the MSIX file was signed. So I feel you should just establish a long expiration that will outlive the lifespan of the package.

Use a timestamp to keep your certificates from expiring, read our article Digital Signing: Why You Should Always Include a Timestamp for more information.

This certificate must be trusted by all computers in your company that are going to receive the software. You could go with a single certificate and sign all package with it, in which case you only distribute the certificate once.

Or you could also make a unique certificate for each package, allowing you to revoke the certificate for an individual package. My feeling is that I’ll use other ways to get rid of a package (since revoking might only affect new installs) so a single certificate is probably OK.

The Public Certificate Route

There are plenty of public Certificate Authorities out there where you can acquire a certificate - varying in prices and services.

The job of the CA is to provide the certificate, and to provide verification about your identity. The only downside I find to using a low cost certificate is the potential for the CA to get a bad name and lose its trustworthiness. I recommend you research and make an informed decision when shopping for a CA.

When purchasing a certificate, you will find there are Regular certificates and Extended Verification (EV) certificates. The latter require a higher degree of verification about your identity and cost significantly more. That’s a trade off your company will have to decide upon.

Unlike server certificates for your website, with a code-signing certificate most customers won’t notice if you have the EV level certificate. However, the OS does care and it can make your life easier in certain scenarios.

Conclusion

The long-term benefits of MSIX to the developer are really about how it protects your application at the customer site, reducing instances of other applications, or the end-user themselves, from damaging the app can causing work for your customer support staff.

Developers, and their companies, will have to use certificates for their installer packages with MSIX. It might be a little bit of a hassle getting started with them, but once you get the process down it will be easy.

How do you handle MSIX Certificates? Let us know in the comments below.