Windows 软件发布中的 SHA-256、自签名与受信任代码签名分别证明什么

Windows 工具发布时，经常会同时出现几种说法：文件有 SHA-256、EXE 带签名、证书是自签名、SmartScreen 仍提示未知发布者。

这些说法并不矛盾，因为它们回答的是不同问题。

下载地址证明“从哪里拿到”

正式 Release 页面提供的是发布入口。用户应从项目公开的 Release 获取文件，避免从不明网盘、二次打包站或聊天附件运行可执行程序。

但 HTTPS 和官方页面只能说明传输入口可信，不能单独证明你保存到磁盘的文件没有被替换、下载不完整或选错版本。因此还需要独立校验文件内容。

SHA-256 证明“文件是否一致”

SHA-256 会把文件内容映射成固定长度摘要。只要文件发生变化，摘要通常就会改变。

在 PowerShell 中可以这样计算：

Get-FileHash -Algorithm SHA256 -LiteralPath '.\Your-Installer.exe'

把输出与 Release 页面或 .sha256 sidecar 对照，可以回答：

我下载的这个文件，是否与发布者公开的那个文件逐字节一致？

它不能回答发布者身份是否经过第三方认证，也不能自动证明软件没有漏洞。若攻击者同时控制了文件和公布 hash 的页面，单独的 hash 也无法建立新的信任。

Authenticode 签名证明“签名后是否被改动”

Windows Authenticode 把发布者证书与可执行文件签名绑定。签名后文件内容若被修改，验证会失败。

可以用 PowerShell 查看：

Get-AuthenticodeSignature -LiteralPath '.\Your-Installer.exe' |
  Select-Object Status, StatusMessage, SignerCertificate

这里要继续区分证书来源。

自签名证书不是公共信任证书

自签名证书适合开发测试、内部可复现构建或确认“这些测试包由同一把测试密钥签出”。但普通 Windows 电脑默认不信任它，所以 SmartScreen 或签名状态仍可能提示未知、未受信任。

这时发布页面应该明确写：

• 当前使用自签名测试证书；
• Windows 默认不会把它视为受信任发布者；
• 用户仍需核对 Release 地址和 SHA-256；
• 不要求用户关闭 SmartScreen 或安全软件。

最危险的做法，是把“文件里存在一个签名”描述成“已经获得 Windows 官方信任”。

受信任代码签名增加了什么

由面向目标分发渠道的受信任证书签名后，Windows 可以沿证书链验证发布者身份。配合时间戳服务，即使证书之后到期，签名也可以证明文件是在证书有效期内完成的。

它改善的是身份与分发信任，不会替代：

• SHA-256 sidecar；
• 安全设计和代码审查；
• 安装、升级、卸载和 rollback 测试；
• 清楚的权限与数据边界；
• 对历史 Release 资产的不可变管理。

小型项目的推荐发布清单

1. 从固定的正式 Release 页面发布，不复用临时下载链接。
2. 为安装器和便携包分别生成 SHA-256 sidecar。
3. 在 Release notes 中记录文件名、版本、架构和签名状态。
4. 签名后再次计算最终分发文件的 hash，因为签名会改变 EXE 内容。
5. 不静默替换已经发布的同名资产；需要修复时发布新版本。
6. 在干净环境验证下载、校验、启动、安装与卸载。
7. 对未签名或自签名状态如实说明，不引导用户绕过系统保护。

用户验证的合理顺序

确认正式 Release 地址
  -> 确认版本、文件名与架构
  -> 计算并核对 SHA-256
  -> 查看 Authenticode 状态与证书
  -> 阅读权限和已知限制
  -> 再决定是否运行

结论

SHA-256 解决文件一致性，自签名主要服务开发或受控测试，受信任代码签名补充发布者身份。三者不是互相替代的营销标签，而是一条发布信任链上的不同证据。

对独立项目来说，暂时没有公共信任证书并不可耻；真正重要的是把状态说清楚、保留校验方式、不要静默替换资产，也不要让用户通过关闭安全机制来换取“安装成功”。