为 MSIX 包签名

应用包签名是创建可部署的 MSIX 包的过程中所需的步骤。 Windows要求使用有效的代码签名证书对 MSIX 包进行签名。

若要成功安装Windows应用程序，该包不仅必须签名，还需在设备上受信任。 这意味着，该证书必须链接到设备上的某个受信任根。 默认情况下，Windows信任大多数提供代码签名证书的证书颁发机构的证书。

此外，如果要创建 MSIX 捆绑包，则无需单独对捆绑包中的所有包进行签名。 只需对捆绑包进行签名;签名涵盖捆绑包中的包。

签名选项

根据方案选择签名方法：

情景 选项 Cost
开发和本地测试 自签名证书 免费
生产部署（推荐） Azure项目签名（以前受信任的签名） 基本： ~$10/月
生产分发（替代） 来自 CA 的 OV 代码签名证书 $300–500/year
Microsoft Store分布 提交时由商店签名 免费

注释

Azure项目签名（以前称为受信任签名）是Microsoft托管代码签名服务，是生产 MSIX 签名的建议选项。 主要特征：

  • 基于标识的信誉：信誉与已验证的发布者标识（而不是特定证书）相关联，因此它会在生成中累积。 但是，与所有非应用商店分发一样，新应用仍然会显示 SmartScreen 警告，直到积累了足够的下载历史记录，这通常需要几周。 请参阅 SmartScreen Windows 应用开发人员的声誉。
  • 短期证书：每天都会颁发一个新证书，每个证书的有效期约为3天，这样在需要时可以实现精确的撤销。
  • CI/CD 就绪：支持开箱即用的 GitHub Actions（azure/trusted-signing-action）和 Azure DevOps。

公共信任证书的资格：适用于美国、加拿大、欧盟和英国的组织，以及美国和加拿大的个人开发人员。 组织必须具有三年或更多年的可验证税务历史记录。 请参阅 标识验证的重要信息。

使用 SignTool 进行签名需要额外的设置：SignTool 只有在使用工件签名客户端工具时才适用于工件签名，这些工具包括所需的 dlib 插件和 .NET 8 运行时。 您还必须提供一个包含帐户终结点和证书配置文件的 metadata.json 文件。 标准Windows SDK SignTool 调用本身不适用于构件签名。 最简单的安装是：

winget install -e --id Microsoft.Azure.ArtifactSigningClientTools

完整的设置信息请参阅 “使用工件签名设置 SignTool”。

AzureSignTool 是一个单独的社区工具，用于使用存储在Azure 密钥保管库中的证书进行签名。 它 不支持 工件签名 — 这是两个独立的服务。 有关使用 Azure 密钥保管库 在 Visual Studio 中进行签名，请参阅 使用 Azure 密钥保管库 对包进行签名。

WinApp CLI

WinApp CLI 提供了用于开发签名的便捷命令：

  • winapp cert generate — 创建用于开发的自签名证书
  • winapp sign — 使用证书对 MSIX 包或可执行文件进行签名
  • winapp tool signtool - 直接从 Windows SDK 访问 SignTool

签名主题

主题 DESCRIPTION
签名的先决条件 对应用包进行签名所需的先决条件。
使用 SignTool 如何使用 Windows SDK 中的 SignTool 对应用包进行签名。
使用 Azure 密钥保管库 签署包 如何使用存储在Visual Studio Azure 密钥保管库中的证书对包进行签名。
使用 Device Guard 签名对 MSIX 包进行签名 如何使用 Device Guard 签名对应用进行签名。
创建用于测试的未签名包 如何创建用于测试的未签名 MSIX 包。
Azure工件签名 Microsoft的托管签名服务（前身为受信任的签名）用于生产环境的 MSIX 包。

时间戳

强烈建议使用证书对应用进行签名时使用 时间戳 。 即使证书过期，时间戳也会保留允许应用部署平台接受应用包的签名。 在包裹检查时，时间戳可以用来验证包裹签名是否在签署的时间内有效。 这样，即使证书不再有效，也允许接受包。 未设置时间戳的包将针对当前时间进行评估，如果证书不再有效，Windows将不接受该包。

以下是围绕使用/不使用时间戳进行应用签名的各种应用场景：

情景 应用签名时没有使用时间戳 应用使用时间戳进行签名
证书有效 应用将安装 应用将安装
证书无效（已过期） 应用安装失败 将会安装应用，因为在签名时，证书的真实性已由时间戳机构验证

注释

如果应用在设备上成功安装，即使证书过期后，它也会继续运行，无论它是否带有时间戳。

包完整性强制实施

除了确保设备上仅安装受信任的应用程序之外，对 MSIX 包进行签名的另一个好处是，它使Windows能够在设备上部署包后强制实施包的完整性及其内容。 通过在签名的包中链接到 AppxBlockMap.xml 和 AppxSignature.p7x，Windows能够在运行时和Windows Defender扫描期间对包的完整性及其内容执行验证检查。 如果认为包被篡改Windows将阻止应用程序启动并启动修正工作流，以修复或重新安装包。 对于未通过Microsoft Store分发的包，如果包声明 uap10：PackageIntegrity 元素，并且部署在 2004 和更高版本的 Windows 上，则会强制实施包完整性。 下面是 AppxManifest.xml中包完整性强制执行的示例声明：

<Package ...
xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"  
IgnorableNamespaces="uap10">
...
  <Properties>
    <uap10:PackageIntegrity>
      <uap10:Content Enforcement="on" />
    </uap10:PackageIntegrity>
  </Properties>
...
</Package>

设备模式

Windows 10允许用户选择在“设置”应用中运行其设备的模式。 这些模式包括 Microsoft Store 应用、旁加载应用和开发人员模式。

Microsoft Store应用是最安全的，因为它只允许从Microsoft Store安装应用。 Microsoft Store中的应用通过认证过程来确保应用安全使用。

“旁加载应用”和“开发人员模式”对其他证书签名的应用的宽容度更高，前提是这些证书受信任并已链接到设备上的某个受信任根。 仅当你是开发人员并生成或调试Windows 10应用时，才选择“开发人员”模式。 有关开发人员模式及其提供的内容的详细信息，可 在此处找到。

注释

从 Windows 10 版本 2004 开始，旁加载选项默认处于打开状态。 因此， 开发人员模式 现在是一个切换模式。 企业仍可以通过管理策略关闭Sideloading。

  • Last updated on