How and why PublisherID, PackageFullName and CA's break the upgrade cycle


In the past I have complained about the method by which the subject field of the certificate (aka Publisher) is hashed and used in the Package Full Name as I suspected it would cause problems for Microsoft partners that create software down the road.  And now I have run into the problem full tilt.


We are 3 years in so my code signing certificate has now expired.  After 2 months of effort, I still have not found a CA that can actually produce a new certificate with the same subject field.  And this is without my company being bought or renamed in the interim (which others will face).  The latest issue is that the CA decided to remove postal information from the field on all new certs.


This changes the SHA256 hash and the uuencoded PublisherID that is used to make up the Package Full Name.  And that means my existing customers cannot upgrade their current packages.  Removal and Install (with loss of configuration) is required and that is not acceptable. I might be the first to face this problem, but by no means will I be the last unless the upgrade process is adapted.


AppInstaller recognition of a package as an upgrade of an existing package should not depend on this mechanism.

4 Replies
Thanks for posting about this. We are actively looking into this and will share updates as they come.
In case you think I might be alone, there is a thread in the msixmgr github repository here:
This issue seems to still occur as of today.

@Dian Hartono  Well I had intend to mean the Registry.dat as that's one of the places they are stored when a package is captured by the Microsoft MSIX packaging tool (see attached image). ANother copy is also stored in the User.dat file, so whichever source the installer uses I mean that one.


By the way, it would be nice to know if one of those is a mistake and need not be in the package.  My tooling makes duplicate changes in both of those files when editing the package.