To sign an MSIX package, the Subject of your signing certificate must match the Publisher value in the package manifest. If they differ, signing fails. Fix it by changing the manifest to the certificate subject, or by using a certificate issued for the identity your manifest declares.
Definitions
An MSIX package is a Windows app package with a manifest file named AppxManifest.xml. The Publisher is an attribute of the Identity element in that manifest. The Subject is the identity field inside the signing certificate. Windows compares the two.
The rule
Microsoft's certificate guide says that to use a certificate to sign an app package, the Subject in the certificate must match the Publisher section in the app manifest. Its example shows an Identity element with a Publisher value made of a common name, an organization and a country, and says that exact string is what you use when creating the certificate.
The match includes the structure and order of the name parts, not only the organization name. A small difference, such as a missing country field or a changed company suffix, causes a mismatch.
Why it bites teams
Mismatches appear when:
- A company renames itself, and the manifest still has the old string.
- A certificate authority issues the certificate with a slightly different subject format than the one you used in testing.
- A team uses a self-signed test certificate with a made-up name, then switches to a production certificate.
- A managed signing service issues certificates for a verified identity that differs from the string in the manifest.
Because the manifest ships inside the package, you must correct it before the package is built, not after.
How to check before you sign
- Read the Publisher value from the manifest.
- Read the Subject from the certificate you plan to use.
- Compare them character by character, including order.
- Make the check a build step so mismatches fail early.
If you use a test certificate, Microsoft's guide notes it must be created with the manifest's publisher as its subject, and that for an end entity code signing certificate you set the code signing usage and mark it as not a certificate authority.
Bundles and Store distribution
Two details from Microsoft's signing overview save effort. For a bundle, you do not sign each package inside it. Only the bundle needs a signature, and that signature covers the packages in the bundle. For Microsoft Store distribution, the package is signed by the Store on submission.
Trust is a separate step
A matching subject lets you sign. It does not make the device trust the package. Microsoft says the package must be signed and trusted on the device, meaning the certificate must chain to a trusted root. By default Windows trusts certificates from most certificate authorities that provide code signing certificates. A self-signed certificate must be imported into a trust store on each test machine, which has side effects covered at /resources/blog/self-signed-code-signing-certificate-when-is-it-acceptable.
Add a timestamp
Microsoft highly recommends timestamping when you sign. Without it, a package is evaluated against the current time, and once the certificate expires Windows will not accept the package for installation. With a timestamp, the package still installs. Microsoft adds that an app already installed keeps running after the certificate expires either way.
Where Safeguard fits
Matching names confirms who signed a package. It does not describe the libraries inside. Safeguard scans dependencies and produces SBOMs, with a free scan at gold.safeguard.sh/scan.
Quick check
Do I sign every package in an MSIX bundle?
No. Microsoft says only the bundle needs to be signed, and the signature covers the packages inside it.
Does an expired certificate stop an installed MSIX app?
Per Microsoft, an app that is already installed continues to run. Without a timestamp, new installs of the package fail after expiry.
Sources
Last reviewed: 19 October 2026.
