Clarify SDK vs. Runtime requirements

[Marv51]

"Starting in Windows Insider Preview Build 22000, an artifact will need to be created to show the relationship between the old certificate and the new certificate that is being used for signing."

This sentence is not clear at all. "Windows Insider Preview Build 22000" most likely should be "Windows 11".

However, it is more important to describe clearly what the requirements are: Can users on Windows 10 1909 install apps signed/prepared in this way? What happens if I do not follow these steps? I guess this process is needed if the certificate details of the old cert don't match the new ones? What fields are relevant here?

"You will still need to install the old certificate (recommended with timestamp) on the machine for the platform to install the package that was signed by the new certificate."

I saw multiple people asking about this before, but can you please expand on this crucial point?

You say "In order to use this feature and to persist the original package identity that was signed with old certificate, you will need to install the old certificate." Source

What does "install" mean in this context? How would I timestamp a public certificate? Does it matter for this if the old certificate is self-signed or publicly signed?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: fdec14ed-d6ca-9bd6-f0f7-de3b30915aa3
• Version Independent ID: 7ff21924-0311-5f70-7087-4a1669ee8afe
• Content: MSIX Persistent Identity - MSIX
• Content Source: msix-src/package/persistent-identity.md
• Product: msix
• GitHub Login: @dianmsft
• Microsoft Alias: diahar

[Marv51]

I have done the work and I can report back:

• It is definitely a runtime requirement. This publisher-bridge does not work on Windows 10 at all.
• There is no need to install any certificate on Windows 11, adding the publisher-bridge artifact and signing with a new cert was all that was needed for me.
• It seems almost hostile to me that is article does not mention how to pass the /pb parameter to makeappx when using msbuild. In my .wapproj I set:

  <PropertyGroup>
  <CreatePackageMakeAppxParameters>/pb "C:/[full-path-worked-for-me]/certificate-migration-2022-pb.txt"</CreatePackageMakeAppxParameters>
  <CreateResourcePackageMakeAppxParameters>/pb "C:\[full-path-worked-for-me]\certificate-migration-2022-pb.txt"</CreateResourcePackageMakeAppxParameters>
  <AppxPackageSigningEnabled>false</AppxPackageSigningEnabled>
  </PropertyGroup>

  I set AppxPackageSigningEnabled to false, because I can not get automatic signing to work. (Msbuild will change the manifest, based on the CN of the cert used.)

But with SignTool sign /sha1 C04580A[...] /fd SHA256 myapp.msixbundle signing all packages in the bundle in one step worked for me.

[florelis]

This sentence is not clear at all. "Windows Insider Preview Build 22000" most likely should be "Windows 11".

You are correct. It says Insider Preview Build 22000 because at the time this was introduced Windows 11 was still a surprise :) @dianmsft Can you look into updating this?

Can users on Windows 10 1909 install apps signed/prepared in this way?

No. This is a new feature in Windows, so older builds will not be able to correctly handle apps prepared in this way.

What happens if I do not follow these steps?

The publisher in the AppxManifest.xml and the cert subject must match each other for you to be able to sign and install. If your new certificate has a different subject, you can still sign the new version of your app with a different publisher, but it will be seen as a completely different app from older versions and you will not be able to update from them.

I guess this process is needed if the certificate details of the old cert don't match the new ones? What fields are relevant here?

Yes. The Publisher is the only relevant field.

What does "install" mean in this context? [...] Does it matter for this if the old certificate is self-signed or publicly signed?

"Install" should be "trust". If you are using a self-signed certificate (e.g., for dev testing), to trust it you will have to install it. For a certificate issued by a CA, the cert for the root CA will probably already be in your machine and you won't have to install anything.

How would I timestamp a public certificate?

You don't. What needs to be timestamped is the artifact (CAB), which I agree is not what the docs say. @dianmsft can you update the docs?

Msbuild will change the manifest, based on the CN of the cert used.

Yes. Unfortunately, MSBuild currently doesn't support MSIX Persistent Identity, so it always assumes that the publisher and cert subject match.

[Marv51]

@lechacon Thank you for the very thorough reply.

Please update the documentation around this feature with this feedback and the couple of other issues raised before by other customers.

Has servicing this feature to Windows 10 been considered? Honestly, this is the biggest pain point for us since we adopted MSIX.

[kpotterams]

Unfortunately, the fact that "MSBuild currently doesn't support MSIX Persistent Identity" makes this next to useless. We use the Visual Studio "Create App Package" feature, which in turn uses MSBuild, which creates a very different set of packages and files. Also unfortunately, there's no documentation regarding what commands VS issues to MSBuild, so its impossible to produce the same output while using MSIX Persistent Identity/Publisher Bridging.