Windows出现“Windows 已保护你的电脑”提示的原因

SmartScreen、代码签名、EV/OV证书、MSIX/Store分发的实务整理

开发并分发Windows应用时，最先容易碰到的一道坎，就是这个警告。

Windows 已保护你的电脑
Microsoft Defender SmartScreen 已阻止启动无法识别的应用。

出现这个警告后，用户会感到不安。开发者也会困惑：“明明不是病毒，为什么会被拦截”“明明已经做了代码签名，为什么还会出现警告”。

本文将从代码签名、EV/OV证书、MSIX、Microsoft Store、ClickOnce、企业内部分发的角度，整理Windows应用分发时出现的SmartScreen警告。

1. 一句话总结本文

Windows应用分发中，代码签名是必需的。
但代码签名并不是能让SmartScreen警告必然消失的魔法。

重要的是把三个观点分开来考虑。

大致的判断标准如下。

2. SmartScreen不只是“病毒判定”

出现SmartScreen警告时，用户往往会觉得“这是危险的应用吗”。

但SmartScreen并不是单纯地只看“是不是病毒”。根据 Microsoft 的说明，对于下载的文件，它主要参考以下这些信誉信息。

这里重要的一点是，新创建的文件还没有信誉。

对开发者自己而言这是正确无误的应用，但从Windows侧看，它是“第一次见到的文件”。即使已经签名，只要文件哈希或发行者的信誉尚不充分，SmartScreen警告仍可能出现。

也就是说，可以这样理解SmartScreen警告：

并不意味着被断定为恶意软件。
但确实意味着Windows尚未判断其足够可信。

如果不理解这个差异，就容易产生“已经签名了却还不好”“买了EV证书却没有变化”这类误解。

3. 代码签名到底保证了什么

代码签名所保证的，主要是两点。

1. 该文件确实由所显示的发行者签名
2. 签名之后文件未被篡改

反过来说，以下这些事情并不由代码签名直接保证。

• 该应用绝对安全
• 该应用没有bug
• SmartScreen警告不会出现
• 企业策略必然会放行

尽管如此，代码签名仍几乎是必需的。

如果没有签名，用户无法得知发行者。在企业环境中，未签名文件可能会被 App Control、EDR、Defender、代理服务器、邮件网关拦截。制作自动更新程序时，签名对于验证更新文件是否为正版也十分重要。

也就是说，代码签名不仅是为了“消除警告”，而是分发、更新、审计、企业采用的基础。

4. “买了EV证书从第一次起就不会出现警告”是过时的理解

以前普遍存在一种理解，认为使用EV代码签名证书，会在SmartScreen方面获得更有利的对待。

但现在，至少仅以规避SmartScreen为目的购买EV证书是危险的判断。根据 Microsoft 目前的说明，EV证书自动规避首次下载时SmartScreen警告的行为已经不复存在。用EV签名的文件，也需要像OV证书一样，以信誉逐步积累为前提来考虑。

EV证书并非完全没有意义。

• 企业采购上，更严格的身份核实会被评价
• 客户的安全审查中被要求使用EV
• 已经持有EV证书，因此继续使用

如果有这些理由，使用EV证书是可以的。

但不建议仅以这个目的购买EV证书。

为了从第一次起就消除SmartScreen警告而购买EV证书

如果目的仅在于此，应先重新审视分发渠道、签名方式、对初期用户的说明、更新频率，以及是否能通过Store分发。

5. 签名方式的选择

整理一下Windows应用分发中常见的签名、分发选项。

Microsoft Store / MSIX

如果要面向普通用户分发，首先值得考虑的是 Microsoft Store。

特别是MSIX与Store分发的组合，在证书管理和SmartScreen警告方面具有优势。提交到Store的MSIX包会由Microsoft重新签名，因此开发者单独购买、更新证书的负担也会减少。

不过，并非所有Windows应用都适合MSIX。

• 深度使用Windows服务
• 需要驱动程序
• 存在shell extension
• 存在旧的COM注册或ActiveX资产
• 安装时需要复杂的系统更改

在这些情况下，MSI或传统安装程序有时比MSIX更自然。

Azure Artifact Signing

Azure Artifact Signing 是 Microsoft 提供的云端代码签名服务，以前称为 Trusted Signing。

不需要使用实体USB令牌，容易集成到CI/CD中，这是其魅力所在。作为Store外分发的签名方式很有力，但存在可用地区和账户条件的限制。

根据2026年时点的Microsoft资料，组织用户面向美国、加拿大、欧盟、英国，个人开发者面向美国、加拿大。如果是日本的法人或个人使用，请务必确认使用条件。如果无法使用，传统的OV代码签名证书是现实的候选方案。

此外，即使用Azure Artifact Signing签名，SmartScreen的信任也不会立即授予。与OV证书一样，信誉会随着分发实绩逐步积累。

OV代码签名证书

对于日本的开发者或法人在Store外分发Windows应用，OV代码签名证书如今仍是现实的选择。

使用OV证书后，用户会看到发行者名称。相比未签名，这明显是更好的状态。不过，对于新应用或新文件，仍可能出现SmartScreen警告。

使用OV证书时，需要注意以下几点。

• 持续使用同一个发行者名称
• 每次都以同一发行者身份签名
• 签名后不改动文件
• 添加时间戳
• 不只EXE，还要检查DLL、MSI、updater
• 准备证书更新时的迁移计划

自签名证书

自签名证书对开发和验证很方便。

但在公开分发中基本无法使用。因为从用户的Windows看，该证书并非受信任的证书。

自签名证书适用于以下环境。

• 开发者的本地PC
• 测试者的验证环境
• 可通过Intune或GPO分发受信任证书的企业内部终端
• 能够完全管理终端配置的封闭环境

即使使用自签名证书，也需要管理“何时删除”“谁将其加入受信任列表”“是否混入生产环境”这些问题。

6. 实务中应该对什么签名

“只对EXE签名就结束了”是不够的。

Windows应用分发时，需要逐一确认签名对象。

使用SignTool时，在目前的Windows SDK中，/fd与/td的指定很重要。典型做法是指定SHA256。

signtool sign /fd SHA256 /tr <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

关键在于对最终成果物签名。

如果在签名之后改写EXE、替换ZIP内的文件、在安装程序制作之后更改内嵌文件，签名可能会被破坏，或导致验证结果与预期不同。

在构建流水线中，需要固定这个顺序。

构建
  ↓
收集依赖文件
  ↓
制作安装程序 / 打包
  ↓
签名
  ↓
签名验证
  ↓
记录哈希
  ↓
分发

7. 各分发方式的思路

MSI / EXE安装程序

以MSI或EXE安装程序分发时，必须对用户最先运行的文件签名。

此外，安装后部署的EXE和DLL也应重新纳入签名对象来审视。即使只有安装程序签名，如果部署后的updater或helper未签名，在企业环境中可能会被拦截。

要考虑的事情大致是固定的。

• 对安装程序本体签名
• 对内含的EXE/DLL也签名
• 分离出需要UAC提升的处理
• 将updater或service helper作为单独对象进行审计
• 稳定下载页面的URL
• 向初期用户告知发行者名称

MSIX

MSIX是包一致性较强的方式。

如果能通过Store分发，在SmartScreen警告和证书管理方面会相当好处理。而在企业内部侧载或Store外分发时，需要认真设计MSIX包的签名与证书信任。

列出一些注意点。

• 开发、验证阶段可以用自签名
• 生产分发要用公开受信任的签名方式
• 使appxmanifest中的Publisher与证书的Subject一致
• 在Store外分发时，要假定可能出现SmartScreen警告
• 事先确认是否存在不适合MSIX的OS集成

ClickOnce

ClickOnce对于向普通用户分发WinForms/WPF等.NET业务应用很方便。

不过，并不是因为使用了ClickOnce，SmartScreen问题就会消失。用户下载并启动的路径、清单签名、分发渠道、更新时的文件变化，都与此相关。

ClickOnce需要确认以下这些方面。

• 应用程序清单与部署清单的签名
• 分发源URL或共享文件夹的管理
• 更新时证书变更的处理方式
• 是否会被企业内部代理或Defender拦截
• 首次安装时对用户的说明

ClickOnce的优势在于“容易分发”，但如果不把发行者信任和分发渠道也一并纳入设计，在实际现场仍会被拦截。

xcopy / ZIP分发

只放一个文件夹、只解压一个ZIP，这种分发方式很简单。

在封闭网络或企业内部工具中，这种方式有时是有效的。但对于面向普通用户的Web分发，这也是最容易受到SmartScreen、Defender、Mark of the Web影响的方式。

如果要采用xcopy分发，以下这些要点需要坚持。

• 对EXE/DLL签名
• 不只依赖ZIP，也要验证内部文件
• 固定分发渠道
• 明确标注版本、哈希、更新历史
• 若后续追加自动更新功能，要加入签名验证

不应认为“不制作安装程序所以简单”，而应认为“要由自己承担安装程序原本承担的责任”。

自研updater

自研updater很方便，但它本身就是一个安全边界。

updater会获取新文件并替换现有文件，某些情况下还以管理员权限运行。这里出问题，比应用本体更危险。

至少要确认以下这些。

• 对更新metadata签名
• metadata中包含version、hash、size、channel、expiry
• 下载后验证hash与签名
• 验证失败时以fail-closed方式停止
• 准备rollback步骤
• 决定updater自身的更新方式
• 将生产签名密钥与开发环境分离

这个主题，与既有文章《自动更新的安全设计》一起考虑会更容易理解。

8. 企业内部分发只看SmartScreen是不够的

对企业内部应用，常见一种误解。

因为只在企业内部使用，所以不需要签名

这是危险的想法。

在企业内部环境中，不仅是SmartScreen，还有多个机制会牵涉进来。

特别是在使用App Control for Business的环境中，不仅“是否已签名”，“该发行者是否被允许”“是否经由managed installer”“哈希或路径是否被允许”都会成为问题。

Microsoft的部署指南也指出，App Control的策略变更应先以审核模式部署，确认拦截事件是否符合预期后，再逐步扩展到强制模式。

企业内部分发时，按以下顺序设计比较现实。

1. 划分目标终端
   - 开发者
   - 测试者
   - 部分部门
   - 全公司

2. 决定分发渠道
   - Intune
   - GPO + 文件共享
   - 企业内部门户
   - VDI / RemoteApp
   - 封闭网络的手动分发

3. 决定信任规则
   - 发行者规则
   - 证书分发
   - managed installer
   - 哈希许可
   - 路径许可

4. 用审核模式确认
   - 什么会被拦截
   - 有哪些DLL或helper被遗漏
   - 更新时是否会被当作不同文件处理

5. 分阶段展开
   - 小范围分发
   - 查看日志
   - 调整许可规则
   - 扩大范围

企业内部分发的要点不是规避SmartScreen，而是让分发渠道对Windows而言可以被解释、被说明。

9. 常见的误解与正确的思路

10. 发布初期该如何向用户说明

新应用在最初几周或初期用户阶段，可能会出现SmartScreen警告。

此时，仅告知用户“即使出现警告也请执行”并不合适。安全的说明应包含需要确认的信息。

列举应纳入说明中的项目。

• 正式的下载URL
• 显示的发行者名称
• 文件名
• 版本号
• 发布日期
• 必要时的SHA-256哈希
• 确认已签名的方法
• 不执行来自不明渠道获取的文件

例如，面向企业内部用户，以下这样的说明是安全的。

本应用仅通过企业内部门户以下页面进行分发。
请确认显示的发行者名称为“○○股份有限公司”。
请不要执行通过邮件附件或聊天工具转发的EXE文件。
如出现SmartScreen警告，请将截图共享给信息系统部门。

面向普通用户时，应优先考虑通过Microsoft Store分发，或在下载页面上加入发行者确认说明。

11. 判断流程

在决定分发方式时，按以下顺序思考会更容易做出判断。

flowchart TD
    A[分发Windows应用] --> B{是否面向普通用户}
    B -->|是| C{能否上架Microsoft Store}
    C -->|是| D[优先选择Store / MSIX]
    C -->|否| E[使用OV证书或Artifact Signing签名]
    B -->|否，面向企业内部| F{是否有终端管理}
    F -->|有Intune/GPO| G[签名 + 证书分发 + App Control审核]
    F -->|无管理| H[固定分发源 + 签名 + 用户说明]
    E --> I[预计会出现初期SmartScreen警告]
    G --> J[从审核模式开始分阶段展开]
    H --> J

实务上的第一候选可以这样整理。

12. 最低限度的检查清单

发布、分发Windows应用之前的检查项目。

签名

• EXE已签名
• DLL已签名
• MSI或安装程序EXE已签名
• updater已签名
• 已添加时间戳
• 签名后未改写文件
• 已用signtool verify验证

分发

• 已确定正式的分发URL
• 下载页面已显示发行者名称
• 已显示版本号与发布日期
• 已预计可能出现初期SmartScreen警告
• 已考虑是否能上架Microsoft Store
• Store外分发时，已考虑OV证书或Artifact Signing

更新

• 更新文件也已签名
• 自研updater已对metadata签名
• 已验证hash、size、version
• 失败时以fail-closed方式停止
• 有rollback步骤

企业内部分发

• 已确认Intune / GPO / App Control的有无
• 已决定证书分发方法
• 已用审核模式查看拦截事件
• 已按目标部门分阶段展开
• 已确认更新时不会再次被拦截

13. 结语

Windows应用不是做完就结束，分发的文件需要从Windows、用户、企业策略的角度来看都处于“可被信任的形态”。

需要把握的要点大致如下。

• SmartScreen关注的是文件与发行者的信誉
• 代码签名是必需的，但不能保证警告为零
• EV证书不应以立即规避SmartScreen为目的选择
• 面向普通用户分发时，优先考虑Microsoft Store / MSIX
• Store外分发时，使用OV证书或Artifact Signing，并预计会出现初期警告
• 企业内部分发不仅要看SmartScreen，还要看Intune、GPO、App Control
• updater不是单纯的分发功能，而应作为产品的安全边界来设计

用一句话总结，就是：

Windows应用的分发，不是“如何放置”，而是“如何让Windows信任”的设计问题。

相关阅读

• Windows应用分发方式的选择指南
• ClickOnce 入门：分发、更新、选择标准
• 自动更新的安全设计
• 守住Windows应用开发最低限度安全的检查清单
• Windows管理员权限的“需要/不需要”边界
• Windows单一二进制文件化的局限与实践

参考链接

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

为什么会出现“Windows 已保护你的电脑”这个警告？

这是因为 Microsoft Defender SmartScreen 判断该文件尚未获得足够的信任。SmartScreen 并不是单纯地判定病毒，而是综合考察发行者的信誉、文件哈希的信誉、是否有签名、分发渠道等因素。新创建的文件对 Windows 来说是“第一次见到的文件”，即使已经签名，在信誉尚未积累起来之前也可能出现警告。这并不意味着该文件被断定为恶意软件，但确实意味着 Windows 尚未判断其足够可信。

代码签名之后，SmartScreen警告就会消失吗？

并不一定会消失。代码签名能够保证的只有两点：该文件确实由所显示的发行者签名，以及签名之后文件未被篡改，并不能保证警告数为零。即使已经签名，只要文件或发行者的信誉尚不充分，警告仍可能出现。尽管如此，代码签名仍几乎是分发、更新、审计、企业采用的基础，几乎是必需项。如果没有签名，在企业环境中，文件可能会被 App Control、EDR、Defender 等拦截。

购买EV证书，是否从第一次下载起就不会出现SmartScreen警告？

这是过时的理解。根据 Microsoft 目前的说明，EV 证书自动规避首次下载时 SmartScreen 警告的行为已经不复存在，用 EV 签名的文件也需要像 OV 证书一样，以信誉逐步积累为前提来考虑。如果因为企业采购要求或客户的安全审查而被要求使用 EV，使用它是有意义的，但不建议仅以规避 SmartScreen 为目的购买 EV 证书。如果目的仅在于此，应先重新审视分发渠道、签名方式，以及能否通过 Store 分发。

要减少SmartScreen警告，应该如何分发？

如果要面向普通用户大范围分发，首先应考虑 Microsoft Store / MSIX。提交到 Store 的 MSIX 包会由 Microsoft 重新签名，因此在 SmartScreen 方面是最容易保持稳定的途径。如果无法通过 Store 分发，则应使用 OV 证书或 Azure Artifact Signing 进行签名，并假定初期仍可能出现警告，同时向用户提供正式的下载 URL、发行者名称、版本、哈希等信息。企业内部分发时，除了签名之外，还需要设计包含 Intune / GPO / App Control 的整体分发路径。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。