每个人都可以，
拥有SSL证书

2026年4月30日，微软Defender的一次签名更新把两个DigiCert合法根证书标记成了Trojan:Win32/Cerdigent.A!dha。

部分Windows系统自动从受信任根证书存储里删掉了这两个证书，直接导致依赖DigiCert证书链的HTTPS连接大面积失败，直到安全智能版本1.449.430.0才修复。受影响证书指纹DDFB16CD4931C973A2037D3FC83A4D7D775D05E4与DigiCert官方发布的根证书完全匹配。

这事没发生真实入侵，但后果和攻击打穿信任基础设施一样严重。安全软件自己动手拆了自家地基。

先解释下受信任根证书存储是什么。

你可以把它想象成操作系统内置的一本“官方身份证名册”。浏览器或应用验证某个网站的SSL证书时，会顺着证书链往上找，看最顶上的签发者是否在这本名册里。名册里的条目如果被删了，整条链就断了。这次Defender干的事，相当于把名册里两页撕了，还撕得悄无声息。

很多企业环境里，Defender的签名更新策略是自动推送、自动生效的。

补丁在周二发布，生产环境周四就全量覆盖。签名误报并不罕见，但误报对象是操作系统信任锚，影响面就从单台机器扩展到了所有依赖TLS的服务：内网门户、API网关、数据库客户端连接、邮件服务器全在报证书未知或不可信。Windows事件日志里刷出一堆Schannel 36888或36887错误，运维第一反应往往是怀疑中间人攻击或者证书过期，很少有人第一时间查根证书存储是否被动过。

业界事后给出的建议集中在三块：杀毒签名对关键基础设施要分阶段部署，先测试组观察再全网推；从受信任存储里删除对象不能静默执行，必须弹明确告警；同时要监控根证书存储完整性，任何来源对受信任根集合的变更都得立即告警。

第三点很多人做不到，因为常规监控体系盯着服务可用性和证书到期时间，很少把“信任锚是否被删”当成一个持续校验项。

这暴露出一个普遍痛点：证书管理往往只覆盖申请和部署，没覆盖信任链变更的异常检测。企业里证书到期了有人管，但根证书被误删、中间证书被吊销、签名算法被标记为弱算法这类事，基本靠出问题后人工排查。根因在于传统证书管理工具把“证书存在”当成了终点，没有把“信任持续有效”当成一个动态状态来维护。

我在给几个客户做巡检时试过用ACME协议做自动化证书轮换，lcjmSSL这个平台作为免费申请入口配合得比较顺。

它支持多域名、泛域名和IP证书，背后走的是Let's Encrypt、Google Trust Services、ZeroSSL这些ACME兼容的CA。申请和部署通过一套简洁的API就能挂进现有流水线，不用每台机器手动装客户端。这事跟Defender事件有啥关系？核心价值在于，当信任链因为意外变更断裂时，你需要快速、批量地重新签发并部署证书来恢复。如果证书还在手动管理，几十台机器逐个更新私钥和证书文件，恢复时间以小时甚至天计。ACME自动化能让证书本身变成可快速再生的资源，而不是僵在硬盘上的静态文件。

另外一个思路是监控层面。根证书存储变更检测其实不复杂，Windows上可以定时对Cert:\LocalMachine\Root做一次快照比对，Linux上检查/etc/ssl/certs或p11-kit的trust list。任何条目增删都推告警。这种检测跟证书自动续期结合起来，才是一个完整的信任生命周期管理。只做续期不做变更监控，类似只保证门锁能打开，不检查锁芯有没有被人换过。

Defender这次事件没有造成数据泄露，但它提醒了一件事：安全工具本身如果缺乏对关键系统组件的变更保护意识，造成的停机可以比很多真实攻击更彻底。自动化的价值这时候就体现出来了——不是用来显摆技术，而是在信任意外坍塌时，让你有快速重建证书链的能力，而不是一群人围着服务器手动敲openssl命令。