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

2026年4月2日，有人反复往DigiCert的Salesforce客服聊天窗口里丢伪装成客户截图的ZIP包。前四次被CrowdStrike拦下，第五次落地，一个.scr屏幕保护程序在客服终端上跑了起来。

终端ENDPOINT1于4月3日被隔离，但ENDPOINT2在4月4日沦陷后，直到4月14日才被发现，中间有十天未受限的访问窗口。

攻击者利用被攻陷的客服账号，通过支持门户的代理查看功能，直接翻到了已批准但尚未交付的EV代码签名订单初始化码。凭这个初始化码，不需要再走客户验证流程，就能激活并签发合法证书。

DigiCert最终吊销了60张EV代码签名证书，关联四个不同的CA，其中27张确认与攻击者直接相关，另外33张因无法确认客户控制权被预防性吊销。

这里头的核心概念是EV代码签名证书的初始化码。大白话讲，EV证书不像DV证书那样填个邮箱点个链接就能拿，它要求CA人工核验企业资质，通过后发一个一次性初始化码，客户拿着这个码去激活证书。

这个码本质上是一把已经开好锁的钥匙，谁拿到都能开门。DigiCert的问题在于，客服侧的代理查看功能允许客服人员看到这把还没交到客户手里的钥匙。攻击者不需要攻破客户的邮箱，不需要伪造企业文件，只需要一个客服账号的屏幕权限。

被盗证书随后被用于签署Zhong Stealer窃密恶意软件载荷，关联GoldenEyeDog/APT-Q-27电子犯罪团伙。但注意，DigiCert的公告里写的是“关联”，没说这个团伙直接实施了入侵。入侵手法更偏向社工加终端突破，不是APT常见的供应链纵深打法。

有个容易被忽略的细节：吊销时间戳。

如果恶意软件在证书吊销前就完成了签名，并且签名时带了可信时间戳，那么即使证书后来被吊销，操作系统在多数情况下仍会认可这个已签名的文件。Windows的Authenticode验证逻辑里，吊销检查和时间戳验证是相对独立的两条线，带时间戳的签名在吊销发生后依然能通过部分场景的信任链检查。这意味着那十天盲区里签出去的东西，吊销动作本身可能救不回来。组织只能靠CRL/OCSP响应速度、内部信任列表的主动剔除，以及端点侧对签名证书指纹的拉黑来补。

企业侧的痛点其实很直白。证书申请、审批、初始化码流转、交付、部署，这一串流程里但凡有一个环节靠人肉邮件或者客服工单手工处理，就有社工的口子。DigiCert这次是客服终端被打穿，下次可能是某个审批人的Outlook规则被改，或者某个共享邮箱的自动转发被加了条规则。代码签名证书因为直接关系软件供应链，一旦出问题就是批量的信任崩塌，比TLS证书吊销的影响面更刁钻。

自动化证书管理在这个场景里的价值不是锦上添花，是减少人工触点。ACME协议那套东西，很多人只把它当免费TLS证书的自动签发工具，但实际上它解决的核心问题是证书生命周期的状态机标准化。

从申请、验证、部署到续期，每一步都走API，没有客服聊天窗口，没有人工点确认的初始化码传递。像lcjmSSL这类基于ACME协议的平台，支持Let's Encrypt、Google Trust Services、ZeroSSL等CA，做的事情就是把证书的申请和部署拉成一条流水线。多域名、泛域名、IP证书的自动申请和验证，加上简洁的API接口，对中小团队来说意味着证书不再需要专人盯着到期时间和手动续期。代码签名证书虽然目前还不能完全走ACME，但PKI运维里TLS证书的自动化程度上来了，安全团队才有精力去盯代码签名证书这种高危资产的人工流程。

DigiCert事后在UI和API层封禁了代理客服查看代码签名初始化码，禁用了Okta FastPass，收紧MFA，并公布了7个攻击者IP。这些动作是标准的止血操作。但真正要命的问题在于，客服终端作为信任链路上的一环，它的权限模型和审计频率没有跟上证书资产本身的敏感度。

ENDPOINT2十天没被发现，说明终端侧的隔离策略或EDR告警分级有漏洞。安全团队得重新画一遍证书交付链路的信任边界，哪些角色能看初始化码、哪些终端能碰客服系统、异常登录和异常文件投递之间能不能做关联告警，这些都是复盘里该补的课。

DigiCert这次不是被什么高级0day打穿的，就是反复投递恶意ZIP，投了五次，进去了。社工加终端突破，老套路，但打在了证书基础设施最不该软的地方。