MSIX签名失败，代码签名证书与Publisher怎样对应

给MSIX签名时，日志若明确报出Publisher不符，就把成品包清单的Identity Publisher与所用代码签名证书的完整Subject逐字核对。这里比较的是包清单声明的身份和证书主体，软件界面上的公司简称、图标旁的品牌名称，都不能代替这项匹配。

这一问题容易出现在测试包转正式发布、替换签名证书，或者构建脚本选错证书时。排查对象应是准备交付的那个MSIX或AppX单包。源码中的设置正确，还要确认打包结果采用了它；签名成功以后，也要继续验证目标电脑能否安装和更新。

显示给用户的名称与签名身份分开查看

清单中的PublisherDisplayName位于Properties一节，Windows可以用它向用户呈现发布者的友好名称。这里允许使用经过业务确认的品牌表达。采购人员看到安装界面上的公司简称时，需要知道它与签名身份不是同一个配置项。

真正需要与证书对应的是Identity元素里的Publisher属性。证书Subject则是“颁发给谁”的主体信息，应与“谁颁发了证书”的Issuer分开读。把颁发机构名称抄进Publisher，即使那是一家可信机构，也没有完成软件发布者的匹配。

假设一张用于演示的证书，其Subject为“CN=ExampleTools, O=ExampleTools, C=CN”。清单只写产品名“ExampleTools”，或者把O与C两项省掉只填CN，都没有保留这个Subject的完整值。示例中的组织名称仅用于解释字段，不对应实际签发结果。

填写时应以所用证书的完整主体为依据，保留属性、取值及顺序，并留意大小写与空格。证书有几个属性就核对几个，不自行补入公司地址，也不为配合中文界面而翻译主体值。

对照时可以把清单Publisher、证书Subject和显示名称抄成三行。研发应指出Identity填错了哪一项，或者签名取用的是不是另一张证书；显示行采用品牌简称本身，不代表身份配置错误。这样也方便研发与证书管理人员交流，避免双方都说“公司名”，实际看的却是不同字段。

第一步，读取成品包里的Publisher

找到本次准备签名的文件，记下完整路径和版本号，避免把上一次构建留下的同名包拿来分析。解包工具MakeAppx随Windows SDK提供。下面演示把Client.msix中的内容释放到InspectClient目录，运行前需让命令窗口能够找到该工具。

MakeAppx unpack /p Client.msix /d InspectClient

解包完成后，打开InspectClient中的AppxManifest.xml，找到Identity，再读取Publisher。不要把Properties中的显示名称当成待比较值，也不要从程序标题或安装界面的文字反推清单内容。

回到项目配置中寻找这个值的来源。Visual Studio项目、打包项目、发布配置或构建任务，都可能参与生成最终清单。若源文件填的是正式主体，成品包里却仍留着测试主体，应查构建时究竟采用了哪份配置，而不是在证书后台反复重新申请。

可以把源码配置和解包所得的清单同时打开，先核对Publisher，再看包版本是否对应这次构建。若发现输出目录里混有旧版，先确认流水线上传和签名步骤使用的实际文件路径。不要直接清空目录掩盖问题，保留有差异的那份包，更容易追到是哪一步引用了旧文件。

MSIX Bundle里的外层清单与单包清单不是同一结构，不能照着单包的检查位置随意修改。遇到bundle，应按SDK的bundle处理方法检查对应内容，不要为了套用命令把扩展名改成msix。

第二步，确认签名工具实际用了哪张证书

开发电脑上同时保存测试证书、正式证书和历史证书时，“机器里已经有正确证书”仍不足以说明本次签名选中了它。查看签名日志中的选择结果，再读取对应证书的Subject和指纹，才能与刚才的Publisher放在一起比较。

手里只有公开证书文件，也可以用Windows证书查看器读取主体信息，或者运行“certutil -dump publisher.cer”。请把命令里的publisher.cer换成签名日志指向的证书副本，而不是任意下载的同名文件。查看公开证书不需要把私钥导出后发给别人，私钥也不参与这次人工抄值比较。

使用SignTool时，/a表示让工具自动选择合适证书。若采用/n，后面的字符串会用于匹配证书主体名称；需要指定某一证书时，还可以向/sha1提供它的SHA-1指纹。名称相近或同时存在新旧证书的环境，更应核对筛选结果，不能只看脚本里出现了公司的简称。

这里的/sha1是选证书的参数，并不要求用SHA-1给安装包做摘要。文件摘要由/fd指定，其取值要依据块映射文件AppxBlockMap.xml的HashMethod确定。默认使用SHA256打包的包，应按对应算法签名，不要因为参数名称相似就一起改动。

证书放在当前用户还是本机存储，也会影响工具能找到哪些候选证书。服务账号执行构建时，其可见范围不一定等于开发人员登录桌面后的范围。排查人员要记录实际执行账号、证书存储位置和所选指纹，避免只在另一用户的证书列表里确认一遍。

看到错误码后先看具体日志

签名返回0x8007000B，不能直接得出“公司名称填错了”的结论。包发布者与证书主体不符、签名摘要与块映射不一致，以及包内容损坏，都可能对应这一错误码。

签名排错应读取名为“Microsoft-Windows-AppxPackaging/Operational”的日志，可在事件查看器的AppxPackagingOM分类中找到。按签名时间筛选错误事件，再打开详细消息。只有消息明确指出Publisher与Subject不匹配时，才把这两个完整值作为本轮修复对象。

日志报出签名摘要与块映射不相符时，应依据块映射中的HashMethod重新设置/fd。包损坏则要重新检查构建产物，以及打包之后有没有修改文件。不要把几个错误都归为证书过期，也不要一次改动Publisher、算法和证书选择，导致下一次失败时无法判断哪项改动有效。

已经发布的软件要先保护原有更新关系

尚未交付的测试项目，可以在确认正式主体后修正打包配置，重新生成并签署安装包。已有用户安装的产品，则应先保存旧版本的Identity和发布证书信息，再决定是否调整Publisher。

Windows会结合包名称、Publisher等属性识别包身份。为了让新证书签上而直接改Publisher，可能影响新旧版本的身份对应关系，不能默认新包会继续覆盖旧包。公司更名、主体变化与普通换证，应分别评估，不能只看证书采购日期。

普通换证也不一定需要改Publisher。如果新旧证书保持了相同的完整Subject，应先检查实际选用的证书及其他签名条件。私钥或指纹变化，并不等于清单中的发布者身份必须跟着改；反过来，公司中文简称没变，也不能证明完整主体没有变化。

微软提供了在特定条件下迁移发布者并保留包身份的机制。这类方案有系统版本、旧证书及部署要求，已有用户的产品应根据目标环境核实适用性。不能将测试电脑上能安装，直接写成所有用户都能平滑更新。

最后重新打包，并按正式分发方式复测

确定Publisher与目标证书相匹配后，应修改负责生成清单的配置，再重新打包。不要打开已经签署的成品包，直接替换其中的AppxManifest.xml，然后把它当作修好的安装文件继续交付。

新打出的包不能沿用上一份成品的签名，应对新文件完成签署，再运行下面的验签命令。

SignTool verify /pa /v Client.msix

记录工具返回的验证结果。命令中的文件名仍要指向本次构建产物，验证失败时保留完整输出，再按消息定位问题。

接着在计划支持的Windows环境中测试安装。有旧版本用户的产品，还应从一份保留旧版的测试环境执行更新，观察版本是否正确替换，以及应用数据是否符合预期。新装与从旧版升级应分别留下测试结果，避免把前者通过误记成后者也已通过。

签名通过与目标电脑信任分属不同检查

Publisher与Subject完全对应，解决的是包声明的身份能否由所选证书签署。目标电脑是否信任这张证书，还要检查其证书链和适用的安装策略。开发电脑上存在测试证书，不代表客户设备也配置了同样的信任。

如果签名已完成，安装阶段却提示证书不受信任，应保留安装错误和签名验证输出，转查目标设备的信任环境。不能为了消除提示，让客户随意导入来源不明的根证书，也不能继续改Publisher碰运气。

企业受管设备有自己的证书部署流程时，应按批准的方式处理。面向外部用户分发时，则要在代表性目标设备上验证安装条件。把这项结果与字段匹配分别记录，技术支持才能知道签署已经完成，剩下的是安装信任问题，还是仍有别的包部署错误。

交付记录应能说明本次包的Publisher、签名证书指纹、包版本和构建来源。下一次更换代码签名证书时，团队就能先比较具体身份值，知道问题发生在打包、选证书还是分发验证环节，而不是重新猜测软件名称该填哪一处。

MSIX代码签名证书常见问题

1、为什么改了PublisherDisplayName还是签名失败？

因为显示字段不承担签名身份匹配。应核对Identity中的Publisher和实际签名证书的Subject。展示文字改得再接近证书主体，也不能替代这两个字段的匹配。

2、代码签名证书有效，为什么MSIX仍签不了？

有效期只是条件之一。Publisher匹配、证书用途、私钥可用性、工具选证书结果及包摘要算法，都需要满足相应要求。先看具体失败消息，不要用“证书没过期”排除整个签名配置问题。

3、证书申请时公司名填错，能在本地改证书内容吗？

不能把公开证书当作普通配置文件修改。应向签发机构核对申请和更正流程，取得符合真实主体的证书。调整清单也不能成为冒用其他公司身份的办法。

4、只检查包里的EXE签名够不够？

不够。内部EXE的签名与MSIX包签名是不同的检查对象，EXE验签成功不能证明外层包已经正确签署。处理Publisher问题时，要检查准备分发的包及其清单。

5、准备提交Microsoft Store的包也按公司简称填Publisher吗？

不应自行猜填。Store分发应遵循应用在Partner Center关联的身份要求，不能直接套用企业自行分发包的示例主体。渠道改变时，应重新核对打包身份配置及提交要求。

相关阅读：代码签名证书错误