0x800B0100: MSIX Package Is Unsigned or Its Certificate Is Not Trusted

Fix it now

MSIX will not deploy a package whose signature it cannot verify and chain to something the machine trusts. Which of these codes you have decides the fix: two are trust-store problems, one means the package itself has been altered since it was signed and must be signed again.

CertUtil.exe -store Root
CertUtil.exe -store TrustedPeople
Import-Certificate -FilePath .\signing.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople
Add-AppxPackage -Path .\package.msix

1. Get the chain first. Right-click the package, Properties, Digital Signatures, select the signature, Details, View Certificate, Certification Path. The top entry is the root and the bottom one is the signing certificate.
2. Take the serial number of each from the Details tab of its certificate dialog, then pass it to CertUtil to see whether this machine trusts that specific certificate: CertUtil.exe -store Root <rootSerial> and CertUtil.exe -store TrustedPeople <signingSerial>.
3. Export the signing certificate to a .cer file and import it into Local Computer, Trusted People. That is the documented destination for a line-of-business MSIX signing certificate.
4. For 0x800B0004 do not import anything. That code means the package contents no longer match its signature, and the documented action is to sign the package again.

Importing a certificate changes what the machine accepts as legitimate software. Import only certificates your organisation controls, into the narrowest store that works, and never a root that arrived alongside a downloaded package.

If the package installs, you are done. If it still fails, the next section separates the four different trust decisions these codes represent.

Why it happens

Every MSIX package carries a digital signature over its contents. At deployment the engine verifies that signature, builds a chain from the signing certificate up to a root, and checks whether this device trusts that root – in the local computer context, not just the user’s. Each stage has its own failure code, and they need different responses.

0x800B0100 is TRUST_E_NOSIGNATURE, no signature present in the subject. Microsoft’s note is blunt: the package must be signed to be deployed. 0x800B0109 is CERT_E_UNTRUSTEDROOT – a chain was processed but it terminated in a root the trust provider does not trust. 0x800B0112 is CERT_E_UNTRUSTEDCA, which is different again: the chain processed correctly and one of the CA certificates in it is not trusted by the policy provider, which is what a missing intermediate looks like.

0x800B0004 does not belong with those at all. It is TRUST_E_SUBJECT_NOT_TRUSTED, and Microsoft’s app-package guidance publishes it as “the app package has been tampered with”, with the action “the package contents no longer match its digital signature. You need to sign the package again.” Importing certificates for that one cannot work, because the trust store was never the problem.

Full reference

Which store, and why it matters

Microsoft is explicit that a package must be trusted in the local computer context as well as the user’s, and that the Digital Signatures tab can therefore show a valid signature while deployment still fails. That is the single most confusing symptom in this article, and CertUtil.exe -store is what settles it.

Working the chain by hand

1. Open the package’s Properties, then the Digital Signatures tab. If the tab is missing, the package is unsigned and nothing below applies.
2. Select the signature, click Details, then View Certificate, then the Certification Path tab.
3. For each certificate in the path, open it and read the serial number from the Details tab.
4. Run CertUtil.exe -store Root <rootCertSerialNumber> and CertUtil.exe -store TrustedPeople <signingCertSerialNumber> on the target device.
5. Omit the serial number to list everything the machine trusts in that store, which is useful when you are not sure what you are looking for.
6. Import whatever is missing, into the store that matches its position in the chain, then retry the deployment.

certlm.msc opens the local machine certificate stores directly, which is easier than driving mmc by hand when you want to see Trusted People as the deployment engine sees it.

Signature codes and their neighbours

Developer-mode registration and stale signature files

0x80073D04 has a specific and easily missed cause. When you register from a loose file layout, Microsoft requires that AppxSignature.p7x and AppxBlockMap.xml are either valid or not present at all. A build directory that still holds those files from an earlier packaged version of the project will fail here every time, and the fix is to delete them rather than to re-sign anything.

Rolling the certificate out to a fleet

• Deploy the certificate with the same tool you deploy the package with, so the two never arrive out of order.
• Put it in the machine store, not the user store. Deployment does not run in the user’s context.
• Keep the intermediates with it. A chain that resolves on your build machine because the CA published there will not necessarily resolve on a laptop offline.
• Re-check after a certificate renewal. A renewed signing certificate is a different certificate, and packages signed with it need the new one trusted.

Every code this article covers

Confirm the fix worked

1. CertUtil.exe -store TrustedPeople <signingCertSerialNumber> returns the certificate on the target device, not just on yours.
2. The package’s Properties, Digital Signatures tab reports the signature as valid on that device.
3. Add-AppxPackage -Path .\package.msix completes without a 0x800B code.
4. A second device that received the certificate through the same mechanism installs it too.

Questions people ask about this