On MSIX and Certificates: Part 1 for Developers
Microsoft’s replacement for the ubiquitous MSI, MSIX, requires the use of code signing certificates to deploy the packages. This is part 1 of a two-part series on MSIX and Certificates. This one is aimed at developers and the second will be for IT Pros.
Part 1 Introduction
Developers can avoid the need for MSIX Certificates as they build and test their packages locally by setting their machine into “Developer Mode”, but this mode should probably not be used on your test machines and certainly your customers will not be using it. So you, or your company, is going to have to deal with signing the MSIX package.
Most third-party developed software uses certificates today, however, typically in-house developers and a lot of free tools out there do not use them. But even those using certificates today may need to learn a little bit a new knowledge to make the move to signed MSIX packages.
To be able to deploy MSIX files outside of your development environment, the MSIX package 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 also (at least those that aren’t redistributable components of others).
If your app is an in-house app (not deployed to those outside of your company), a self-signed certificate can be used, covered later in this article. But if your company is going to distribute the packages to people/customers outside of your company, then read on here.
There are two different paths to take, depending on if you will be using the Microsoft Store.
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 there is the potential of wider distribution, and they take care of the sales and updating process, this comes at a cost. And if you’ve already have this infrastructure you might not want to go that route. But if you do, and smaller companies are more likely to want to, you’ll need to understand the submission process.
Ultimately, the package delivered from the Microsoft Store will be signed using a Microsoft Code Signing certificate that is, by default, trusted by every Windows machine. Microsoft actually takes care of this signing for you as part of the submission process. But, 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 to you.
The way the process is supposed to work is this:
- Your company gets a developer account from Microsoft.
- You log into the developer portal and reserve your product name.
- You get a developer code signing cert from the portal.
- You export the pfx file for your cert, preferably requiring a password.
- You extract the subject name field and use it in your AppXManifest.xml file.
- You sign the MSIX with that cert, and upload the signed package as part of your submission.
- Microsoft re-signs with the public cert as part of the process.
In a larger company, the individual developer probably should not have access to that pfx file and password for that signing. A single “gatekeeper” inside your company will own that, so you’ll build a process around that. Possibly the gatekeeper is the only one that interfaces with the developer portal, or possibly they act just as a signer and returns the signed package back to the developer who deals with the rest of the store.
This means that there may be a need for the developer signing the package to use a “self-signed” certificate for internal testing by the QA staff. The key to making this work is to ensure that the subject name of the self-signed certificate matches that of the developer certificate (I’ll cover this in Part 2 of the series). The Self-signed certificate should have a short shelf life and only be installed on test machines that need it. So the developer signs using the self-signed certificate for internal testing, and the gatekeep re-signs using the developer certificate from Microsoft, and finally Microsoft re-signs it themselves. Does everyone feel safer now? Don’t all speak up at once!
If you are using Advanced Installer to create the package, you can specify your own certificate in Digital Signatures page, or create a self-signed certificate with one click. The key there is to have that self-signed certificate installed into the local machine root certificate store of the build machine, where Advanced Installer also adds the certificate when it creates it.
Not using the Microsoft Store
If you are not using the Microsoft Store for distribution, there will be a couple of options on how to proceed. If you intend only 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 just 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 shouldn’t ever 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; something like 15 or 20 years or more.
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. You could also make a unique certificate for each package, in which case you make it possible 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 quite happy to take your money and sell you a certificate. The differences between them are cost, and the services offered. The job of the CA is to provide not only the certificate, but to provide verification to the world that you are who you say you are. I feel that the only downside to the low cost certs are the potential for the CA to get a bad name and have folks rejecting all certificates from the CA. So shop wisely.
When you go to get the certificate, there are regular certificates and there are Extended Verification (EV) certificates. The latter require a higher degree of verification that you are who you say you are and cost significantly more. That’s a trade off your company will have to decide upon. Unlike server certs for your website, with a code-signing certificate most customers won’t notice if you have the EV level of certificate. Those that do care will have to give more scrutiny to your package whether you go with EV or not. Today customers are probably glad your package is signed at all, but, over time as MSIX signed packages become the norm they may begin to get pickier.
Both Microsoft Store and Private Distribution
The Microsoft Store offers a place to help customers find you, can handle licensing for you, and acts as a distribution arm. But that comes at a cost. Reimbursement rates are changing all of the time, and lower priced products want to be aware of little details, such as getting a bigger cut by getting your users to use a URL with an extra CID tag showing you drove them to the store instead of letting them go to the store and search for your product.
One strategy, especially if you already have your own licensing enforcement, might be to distribute through the store to gain drive-by purchases, but sell the bulk through your own website and avoid the store tax. You should be able to avoid duplicate builds for these two distribution channels by making sure your public cert uses the same subject field as for your developer account.
Conclusion for Part 1
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.
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.