DigiCert 的撤销截止日期将证书验证转变为一项正常运行时间的问责测试

摘要

• DigiCert 在 Mozilla Bugzilla 中报告称，它曾使用 CNAME 记录中的随机值对部分域名进行验证，但未添加必需的下划线前缀，这影响了其 OEM 验证系统中的一个路径。其事件报告称，基于该方法签发了 83,267 张有效的 TLS 证书，并且受影响的证书数量可能被高估，因为系统未能充分存储是否包含下划线。
• 吊销问题迫在眉睫。CA/浏览器论坛的 TLS 基线要求规定，对于错误签发的证书必须在规定的时间窗口内予以吊销，而 DigiCert 的延迟吊销事件报告称，它在 120 小时内吊销了全部 83,267 张受影响的 TLS 证书，而不是当时规则要求的 24 小时。
• 这起事件不仅是 CA 的编码错误。它暴露了订户证书清单管理的弱点、通过经销商和企业账户进行沟通的局限性、客户临时限制令争议带来的法律压力，以及许多组织仍缺乏快速大规模替换证书的自动化能力。
• 实际控制权是分散的。DigiCert 控制了验证实施、证书识别、客户通知、吊销执行和事件报告。根程序和 CA/浏览器论坛控制了信任预期和政策压力，但不控制客户部署。订户控制了其清单、自动化、变更窗口和服务特定的部署。最终用户几乎不控制任何风险。
• 问责的教训是，证书颁发机构不能将吊销视为罕见的文书工作，订户也不能将公开信任的 TLS 证书视为静态的基础设施。Web PKI 的安全模型依赖于在紧急情况到来前，快速替换证书是常规操作。

一个缺失的下划线成为全球性业务连续性问题

如果仅仅归结为标点问题，很容易低估 DigiCert 事件。技术问题是，在基于 DNS CNAME 的域名控制验证路径中，缺少一个必需的下划线前缀。但后果并非简单的排版修正。DigiCert 不得不识别并吊销数万张公开信任的证书，其中许多部署在云服务、电信网络、医疗环境、企业应用和面向客户的网站上。

DigiCert 在Mozilla Bugzilla bug 1910322中的公开事件记录是事实依据。DigiCert 报告称，它收到一份证书问题报告，指示其可能在 DNS 验证方法 7 的实施方面存在问题。它描述了多个与 DNS 相关的验证过程，并表示代码审查发现了一条路径，在该路径中，证书在随机值用作 CNAME 记录中的主机时签发，但未先添加下划线。在同一 Bug 的后续部分，DigiCert 的事件报告称，影响仅限于使用其 OEM 验证系统的签发者，而通过 CertCentral 和 CIS（其针对云提供商的大容量签发引擎）的验证路径正确验证了域名，未受影响。

该数字也来自公开事件记录。DigiCert 表示，基于该方法签发了 83,267 张有效证书，并且它正在吊销数据库中在修复日期之前列为使用 CNAME DNS 验证的所有有效证书。它解释说，这很可能高估了真实影响集，因为 OEM 系统控制未能充分存储是否包含下划线。这句话是问责的关键。系统可以识别风险群体，但无法清楚证明哪些证书具备合规形式。在信任系统中，合规性的不确定性可能成为吊销义务。

要求下划线的安全原因不仅仅是美观。CA/浏览器论坛验证方法区分了订户控制的名称和可能被委派或由用户在更大域下创建的域名。Bugzilla 中的讨论强调，带下划线前缀的标签有助于创建一个特殊的验证命名空间，普通主机名和许多委派子域服务可以避开。如果缺少下划线，可能破坏用于防止在用户无法控制的域下创建子域时进行非预期证书签发的假设。

这就是为什么该事件属于 DNS 委派权力范畴。域验证是将 DNS 中的证据转换为签发证书的权限的一种方式。如果从错误的位置接受证据，或者缺失了必需的边界标记，CA 可能会将较弱的 DNS 安置视为控制证明。然后，证书会向依赖方提供浏览器信任的名称信号。因此，签发权与正确解释 DNS 委派的能力紧密相连。

规则发挥了作用：它们强制要求采取行动

CA/浏览器论坛的TLS 基线要求是本次事件的核心公开规则集。它们定义了公开信任的 TLS 服务器证书的域验证方法和证书吊销义务。本文无需引用每条要求来解释问责结构：如果证书被错误签发或验证未遵循基线要求，CA 必须在适用期限内吊销，除非规则本身允许其他路径。

DigiCert 在Mozilla Bugzilla bug 1910805中的延迟吊销报告明确陈述了合规冲突。DigiCert 表示，它原本力争在 24 小时内吊销所有证书，但在与根程序和社区讨论影响后，决定延迟并在 120 小时内吊销所有受影响证书。其后续事件报告总结了影响：DigiCert 在五天内吊销了 83,267 张证书，而不是现行基线要求所要求的 24 小时。

这一承认很重要，因为它区分了两个事件。Bug 1910322 涉及域验证不合规。Bug 1910805 涉及延迟吊销。第一个问题是证书如何被认为不合规。第二个问题是生态系统如何处理从信任中移除这些证书的义务，而客户仍然依赖它们提供实时服务。

这种区分避免了肤浅的争论。有人可能会说，DigiCert 本应立即吊销并遵守规则。这是清晰的策略立场。也有人可能会说，立即吊销会造成关键服务中断，因此延迟是务实的做法。这是操作立场。事件显示了这两者之间令人不安的差距。公开信任规则旨在保护依赖方免受无效或错误签发的证书之害。现实世界中的订户通常将证书视为难以替换的资产，绑定到维护窗口、设备、负载均衡器、嵌入式系统和变更审批流程。

根程序在权限方面很谨慎。在 Bugzilla 讨论串中，Chrome 根程序代表表示，他们没有权限授予 CA/浏览器论坛基线要求的例外，并且这些要求是共识驱动的，而非由某个根程序独有。Chrome 根程序政策提供了更广泛的浏览器根上下文：CA 根据程序期望、事件评估和持续合规压力参与根存储。但根程序在危机中的咨询并非公开规则的魔法豁免。

Mozilla 的根存储政策和CA 事件响应指南具有类似功能。它们使事件报告和响应成为信任治理的一部分。它们不操作订户的服务器，也不清点客户基础设施内的证书。它们创建了公开的问责论坛，DigiCert 必须在此论坛中解释发生了什么以及将采取什么改变。

DigiCert 的报告对组织原因的坦诚非同寻常

DigiCert 事件报告中最有价值的部分并非证书数量，而是根本原因的描述。它说，该问题是在部署更改以整合域验证流并在多种方法间复用随机值时暴露出来的。它说，系统中的一个路径在使用 CNAME 验证时未包含下划线。它确定根本原因包括：工程与合规之间的孤岛、未能认真对待不包含序列号的证书问题报告，以及缺乏工程严谨性。

这种坦诚很重要，因为 Web PKI 事件经常被视为狭隘的合规缺陷。缺失验证前缀可以被描述为代码错误，但 DigiCert 自己的报告将其界定为组织系统故障。合规关键工程不能与合规解释处于不同的思维世界。不带序列号的证书问题报告仍可能是真实的警告。整合项目可以改进系统，同时暴露从旧工作流边界继承的缺陷。

同一 Bugzilla 记录中，DigiCert 领导层承认，内部团队并非总是按需协作，而依赖他们的世界使这变得不可接受。这不是法律结论，但这是一个强烈的机构承认：公开信任的证书颁发机构不仅仅是另一个 SaaS 供应商。其验证代码做出的声明，浏览器、操作系统、网站、机构、银行、医院和用户都会依赖，却看不到 CA 的内部工作流。

DigiCert 还表示，受影响的路径仅限于 OEM 验证系统，而非 CertCentral 和 CIS。这个界限很重要。它防止事件被夸大为每个 DigiCert 验证通道的故障。但这个界限也引发了一个控制问题：为什么一个验证系统路径的合规行为不同？为什么数据模型未保留足够详细信息以便在事后区分合规与不合规案例？

高估的决定是可以理解的。如果 CA 无法确定哪些证书是在缺失下划线的情况下签发的，那么为了依赖方的信任，吊销风险集中的所有证书比留下可能不合规的证书更安全。但过度吊销会增加订户中断和支持负担。这正是证书签发数据中缺乏足够取证精度所付出的代价。

因此，对 CA 的问责教训是双重的。首先，验证实现需要针对基线要求进行严格的测试覆盖率。其次，签发系统需要保留足够详细的证据记录，以支持精确的修复。CA 不应因其自身系统未保留合规关键事实而不得不在吊销不足和大规模过度吊销之间做出选择。

订户方将政策变为痛点

DigiCert 在 Bugzilla 上的最初更新称，83,267 张证书影响了 6,807 个订户。它还称，许多运营关键基础设施、重要电信网络、云服务和医疗行业的客户在进行吊销时若没有重大服务中断风险，是不现实的。这份声明并非一揽子豁免，而是表明订户生态系统中的很大部分在运营上未做好快速替换的准备。

CISA 的DigiCert 证书吊销预警显示了公共服务影响。CISA 表示，DigiCert 正在吊销一批 TLS 证书，原因是域控制验证不合规，并警告吊销可能导致依赖这些证书进行安全通信的网站、服务和应用程序出现临时中断。CISA 敦促客户检查其 DigiCert 账户，并重新签发或更换密钥。其 7 月 31 日的更新指引客户关注更新的信息和截止日期，并鼓励在更新后的吊销截止日期前，如无法重新签发或更换密钥，则联系 DigiCert。

Google Cloud 的DigiCert 吊销事件事件页面很有用，因为它显示了 CA 事件如何变成云客户的工作。云提供商可能没有导致验证缺陷，但他们有客户，其服务、负载均衡器、API、网关或托管产品可能依赖受影响的证书。当证书颁发机构大规模吊销时，中间商必须识别受影响的资产、进行沟通、提供替换路径和减少停机。

对于中小型组织，痛苦可能更加尖锐。中小企业可能将证书安装于托管面板、防火墙、VPN 设备、销售点系统、邮件网关、身份提供商、API 网关、移动应用后端、SaaS 集成或供应商管理的平台。订购证书的人可能已经离开。DNS 验证联系人可能是经销商。证书可能被跟踪在电子表格中，或根本没有跟踪。替换可能需要非工作时间的变更审批或供应商工单。24 小时对脚本而言很长，对脆弱的组织而言很短。

这就是为什么“中小企业服务连续性”这一标签很贴切。事件通过安全控制的纠正威胁了可用性。一张证书在数学上很小，但在运营上很关键。如果证书过期或被吊销且未替换，浏览器和客户端将拒绝连接，API 失败，用户看到警告，那些看起来不像“证书基础设施”的服务将变得不可用。

订户的责任是真实的。运营公共服务的组织应了解他们拥有哪些证书、部署在哪里、由哪个 CA 签发、何时到期、如何替换、谁批准变更以及是否具备自动化。但 CA 的责任也是真实的。知道吊销是强制性的 CA 应设计验证、清单、通知和客户工具，以应对紧急替换，而不仅仅是常规续期。

经销商和客户渠道是故障面的一部分

Bugzilla 讨论中包括对经销商可能未向订户提供吊销信息以及仅通过电子邮件通知造成混乱的担忧。DigiCert 后来表示，它添加了控制台内消息以提醒用户，但在短时间内以电子邮件以外的方式沟通是困难的。这是一个有重大后果的实际细节。

证书颁发机构通常通过账户层级、经销商、企业采购团队、托管服务提供商和云中间商进行运营。控制实时端点的订户可能不是接收 CA 电子邮件的账户持有人。经销商可能收到通知并需要转发。中央安全团队可能拥有 CA 账户，而应用所有者负责部署。托管服务可能代表客户持有私钥和证书。每次交接都在 24 小时吊销窗口内消耗时间。

这使吊销沟通成为一种控制措施，而非礼貌之举。紧急通知应送达技术联系人、账户联系人、经销商联系人和机器可读端点。它们应识别受影响的证书序列号、域名、产品、替换步骤、截止日期以及不作为的后果。它们应可通过账户控制台、API、电子邮件和状态频道获取。它们应使订户能够轻松导出完整的受影响清单。

DigiCert 的吊销事件通知（由 CISA 链接并在 Mozilla 讨论中出现）扮演了面向客户的通知角色。DigiCert 的状态门户status.digicert.com也被 CISA 引用，用于获取更新的时间线。这些页面很重要，即使档案访问不完美，因为公共机构和根程序讨论在事件期间引导客户指向它们。

沟通还必须避免造成吊销是可选的虚假承诺。一位 Bugzilla 参与者批评了客户请求延迟的想法，因为这可能暗示强制性吊销是可协商的。DigiCert 自己也表示，他们不希望建立一个延迟请求表格，因为延迟吊销是不允许的，这样的表格可能传递它们是允许的信息。这种紧张关系是真实的。CA 需要听到关键基础设施的风险，但规则的存在是为了保护未参与私下对话的依赖方。

更好的答案不是沉默，而是准备就绪、政策一致的沟通。订户应预先知道 CA 可能会在未经长时间协商的情况下吊销。他们应具备快速替换的自动化能力。CA 应具备精确的清单和多渠道通知。根程序应保持公开事件讨论足够可见，以免例外的请求变成私下交易。

法律压力暴露了强制吊销的薄弱环节

延迟吊销报告称，DigiCert 收到通知，一名客户已申请针对吊销的临时限制令。公开案卷Alegeus Technologies LLC v. DigiCert是事件记录的一部分，因为它显示了订户连续性压力如何与 CA 义务发生冲突。后来的 Bugzilla 评论说，双方之间已解决了法律问题。

对这一法律纠纷不应过度解读。临时法院申请并非对 DigiCert 正确或错误的最终裁定，也不是订户拥有阻止吊销的永久权利。这反映了事件期间的压力。如果认为吊销会造成损害，面临停机的订户可能采取法律手段。面对根程序义务的 CA 可能需要根据订户协议和公开信任规则捍卫其吊销权。

这是 Web PKI 的一个结构性问题。全球各地的依赖方依靠 CA 迅速吊销错误签发的证书。单个订户依赖其自身服务的持续运行。法院、合同和紧急申请可能是地方性的，而浏览器信任是全球性的。如果一家 CA 因为一个订户获得法律救济而延迟，风险并不限于该订户，而是成为公开信任记录的一部分。

因此，订户协议和企业合同应明确规定。CA 必须保留在基线要求或根程序政策要求时吊销证书的权利。客户应了解运营不便并非延迟的保证。同时，CA 应设计客户方案，以便在多年将证书视为手动资产后，紧急吊销不会意外到来。

事件还表明，法律准备是 CA 事件准备的一部分。CA 在下一次大规模吊销前应了解，谁能审查限制令请求，订户合同如何支持强制吊销，可以做出哪些公开声明，以及如何与根程序协调而不要求它们授予其并不拥有的权力。时间太短，无法临时拼凑。

自动化是缺失的韧性层

延迟吊销的 Bug 包含了整个事件中最清晰的陈述：吊销完成后，DigiCert 表示，组织无法在 24 小时内替换的首要原因是，行业中绝大多数的组织仍未使用自动化来签发、维护和替换证书。这就是运营上的教训。

RFC 8555定义的 ACME 旨在自动化证书签发和管理。自动化不仅限于 ACME，并非每个企业系统都支持 ACME。但基本原则是：证书应可通过经过测试的工作流来续期和替换，而不是每年一次的手动仪式。CA/浏览器论坛的SC-063 投票关于短期证书和自动化激励表明，在此事件之前，行业已在推动更短的有效期和更高的敏捷性。

Chrome 根程序在 Bugzilla 上的评论表达了相同的观点。Chrome 代表说，他们优先考虑提高整个 Web PKI 的敏捷性和韧性，使吊销事件的破坏性更小，并指出自动化和 ARI 风格的方法在没有 CA 和订户广泛采用的情况下的好处有限。ACME 续期信息扩展草案与此相关，因为它旨在让 CA 向 ACME 客户端发送续期时间信息。它不是所有延迟吊销问题的完整解决方案，但反映了正确的方向：机器可读的续期和替换协调。

自动化对清单也很重要。订户无法替换他们无法找到的东西。证书管理应该能够快速回答基本问题：哪些证书链到 DigiCert，哪些受 CA 事件影响，哪些系统使用它们，哪些私钥可用，哪些所有者负责，哪些替换已经部署，哪些端点仍在使用已吊销或旧的证书。许多组织在紧急情况下才发现他们的证书清单只是空想。

对于 CA，自动化必须包括受影响证书的发现和客户通知。在 Bugzilla 中，DigiCert 讨论指出，收集证书和联系人信息涉及一个中央数据湖和商业智能团队。这一细节应引起任何 CA 的担忧。如果在 24 小时截止日期内需要事件响应团队以外的团队来组装列表，那么流程就没有充分运作化。吊销所需的数据应该具备事件就绪性。

自动化不是逃避问责的方式。它是使问责在互联网规模上成为可能的手段。要求快速吊销的规则，只有在 CA 和订户能够无需每次进行英勇的手动努力即可执行快速替换时才可信。

替换工作流还应包括对成功的验证。订户不应将新下载的证书视为事件结束。它必须确认证书已安装在每个端点上，中间链正确，旧证书未被辅助负载均衡器或灾备站点继续提供，监控不再看到已吊销的序列号，并且依赖客户端接受替换。在大型环境中，这些检查需要扫描和服务所有者认证，而不是一张控制台截屏。DigiCert 的事件表明了为什么证书敏捷性是一门生命周期纪律：发现、签发、部署、验证、监控和退役。遗漏其中任何一步，都可能将 CA 合规纠正转变为挥之不去的客户停机。

同样的教训适用于管理监督。证书替换应被视为韧性演练进行排练，而不是由一位基础设施负责人处理的安静续期杂务。董事会和风险委员会不需要检查每个序列号，但应该知道关键公共服务是否能在年度续期季节之外替换证书，例外请求是否能快速到达法律和运营团队，以及组织能否在吊销影响用户之前证明完成。从这个意义上说，DigiCert 事件也是一场许多订户在时钟开始后才发现需要参与的桌面推演。

受影响的证书是信任问题，而非必然的利用发现

公开记录支持不合规验证和大量吊销的结论。从这些来源来看，它不支持广泛发现攻击者利用 DigiCert 缺陷获取主要服务证书的情况。Bugzilla 参与者询问 DigiCert 是否检查了利用情况，并讨论了涉及允许用户创建任意子域的相关风险场景。这些问题很重要，但问题不是调查结论。

这个界限很重要。夸大利用情况是不负责任的。低估风险也是错误的。域控制验证的目的是防止向不控制相关域的方签发证书。如果验证方法放宽了必需的边界，CA 必须将通过该路径签发的证书视为可疑，即使没有已知的攻击者使用了它。公开信任依赖于规则遵守，正因为依赖方无法调查每个签发事件。

CCADB 公开站点为根存储和 CA 使用的透明度基础设施提供了上下文，而crt.sh和证书透明度日志帮助社区检查已签发的证书。在 Bugzilla 讨论串中，社区成员对照证书透明度数据分析了 DigiCert 提供的证书列表。这是 Web PKI 的优势：存在供外部审查的公开证据。这也提醒我们，签发后的透明度不能替代签发前正确的验证。

事件报告称，尽管风险集很可能高估，DigiCert 仍将吊销其中的所有证书。这是一个保守的信任决策。但保守的信任决策会带来可用性成本。因此，Web PKI 必须在两方面投入：通过更好的验证控制减少错误签发，通过更好的替换自动化减少中断。

这种区分对最终用户也很重要。看到吊销证书警告的浏览器用户不知道底层证书是被主动滥用、通过不合规路径签发，还是被保守高估导致的。用户只看到一个服务问题。这就是问责不能止步于吊销的原因。它必须包括客户沟通和快速补救，以便安全信号保持有意义，而不是成为用户点击忽略警告的又一个理由。

根程序是监督者，而不是客户正常运行时间的运营者

Mozilla、Chrome、Apple 和 Microsoft 的根程序塑造了公开信任的 CA 生态系统。Mozilla 的根存储政策、Chrome 的根程序政策、Apple 的证书透明度和受信任证书计划信息以及 Microsoft 的受信任根程序要求都帮助定义了 CA 运营的信任环境。具体政策不同，但共同理念是，根库包含是有条件的，取决于可信的 CA 行为。

DigiCert 事件显示了这种监督的局限性。根程序可以要求报告、评估模式、不信任某个 CA、要求行动项并推动全行业改进。但它们无法重新部署医院的证书、更新电信公司的负载均衡器、重写客户的变更管理流程，或让经销商即时转发通知。防止中断的工作是分布式的。

这并不使根程序被动。它们的公开 Bugzilla 评论很重要，因为它们抵制私下的例外做法并保持对基线要求的压力。Chrome 关于无权授予例外的评论是一项问责声明。Mozilla 后来对延迟吊销政策修订的讨论表明，该事件可以反馈到根程序治理中。公开的根程序论坛是 CA 解释可以被不仅受影响的客户和 CA 本身之外的更多人审查的地方。

CA/浏览器论坛是另一个层面。该论坛通过 CA 和浏览器的共识编写基线要求。TLS 基线要求页面因此不是强加于 DigiCert 的外部法规。DigiCert 和其他 CA 参与创造这些义务的生态系统。当 CA 事后发现义务在操作上痛苦时，这是一个改进生态系统敏捷性的信号，而不是证明义务是任意的。

最难的治理问题是，对于低严重性的不合规和高可用性风险，吊销时间线是否应更灵活。Web PKI 社区中理性的人有不同意见。本文不解决这一政策辩论。它确定了问责事实：截至事件发生时，DigiCert 承认 24 小时要求，然后花了 120 小时完成吊销。这种不匹配是一个公开信任事件。

DigiCert 控制了什么，订户控制了什么

DigiCert 控制了验证代码路径、工程与合规审查流程、对证书问题报告的响应、修复、受影响证书识别流程、客户通知、公开事件报告、吊销执行和后续行动项。它还控制着其系统是否保留了足够的数据，以精确区分哪些验证使用了合规下划线。在公开记录中，这种数据精度是缺失的。

DigiCert 不控制每个订户的证书部署。它不控制每个经销商交接、每个企业变更委员会、每个设备限制、每个云客户的架构或每个医院的维护窗口。它也不单独控制基线要求。它对遵守它们负责，并对未遵守负责。

订户控制了清单、所有权、自动化、部署架构、续期测试、供应商升级和变更管理准备。一个无法在一天内替换公开 TLS 证书的订户，无论即时触发是否是 DigiCert 的过错，都存在可用性风险。下一个触发可能是密钥泄漏、短期证书政策、紧急不信任事件、私钥暴露或过期错误。

经销商和托管服务提供商控制了 CA 通知与端点运营者之间的交接。如果他们收到通知但未转发，或无法将其映射到实时系统，他们就成了中断面的一部分。云提供商控制了托管证书层和对其运营服务的客户沟通。CISA 等公共机构控制了公开预警和客户指导，而非 CA 的系统。

最终用户几乎什么都不控制。他们依赖浏览器和客户端执行证书信任，依赖 CA 正确验证，依赖服务运营商替换证书，并依赖根程序让 CA 负责。如果证书被吊销和服务失败，用户的选择是停止使用服务、在客户端允许绕过的前提下接受风险，或等待。这种不对称就是负担落在机构身上的原因。

为下一次事件提供更好的证据和控制

一个更好的事后控制集始于验证设计。每个 CA 都应维护可执行测试，直接映射到它支持的每个基线要求验证方法。如果方法措辞要求带下划线前缀的标签，测试应在缺少时失败。如果多个产品或 OEM 系统实现相同的方法，它们应共享经过合规审查的验证库，或证明等效行为。

DigiCert 后来在github.com/digicert/domain-control-validation上公开了域控制验证代码，在Maven Central提供了包信息，并在javadoc.io上提供了文档，这与此相关。开放实现材料可以帮助客户和社区了解验证行为，尽管仅开放代码不代表生产配置或消除组织风险。

其次，签发记录应保留合规关键事实。CA 应该能够回答，对于每张有效证书，使用了哪种验证方法、哪个系统路径执行了验证、观察到了哪条 DNS 记录、是否包含必需的前缀、验证何时发生、涉及哪个账户或经销商，以及哪些证书依赖该验证。这些信息应可在事件压力下查询，无需临时拼凑商业智能工作。

第三，吊销沟通应是机器可读的。订户应能通过 API、仪表板和自动化钩子拉取受影响的序列号和替换要求。电子邮件是必要但不充分的。控制台横幅有帮助，但可能错过不每天登录的操作者。经销商应负有合同义务和技术机制，以快速传递通知。

第四，订户应维护证书物料清单。它应包括公开和私有证书位置、续期负责人、自动化状态、密钥存储、依赖服务、替换操作手册和紧急联系方式。证书清单应通过在年度续期季节之外替换证书进行测试。从未在压力下替换证书的操作手册只是一个愿望。

第五，根程序和 CA/浏览器论坛应继续公开讨论延迟吊销，同时不允许私下例外文化变得正常。如果规则演变，它们应透明地演变。如果规则不演变，CA 和订户必须建立运营以迎接它们。

持久的教训

DigiCert 2024 年的吊销事件是一堂关于信任和正常运行时间如何碰撞的紧凑课程。一条验证路径缺失了必需的下划线。CA 无法精确分离每个合规与不合规案例。规则要求快速吊销。客户缺乏足够的自动化。一些关键服务运营商面临中断。出现了法律挑战。征求了根程序意见，但无法豁免规则。CISA 警告了公众。DigiCert 最终在五天内吊销了受影响的 TLS 证书，并承认了组织原因。

这个事件中的攻击者（如果存在的话）不是公开记录的重点。记录是关于机构控制的。DigiCert 控制了验证和吊销。根程序控制了信任监督。订户控制了部署准备。经销商和云提供商控制了沟通路径。用户承担了后果。

实践标准很明确。证书颁发机构应能证明其支持的每个验证方法都严格按照要求实现，证书记录保留足够详细的信息以供精确补救，并且紧急吊销无需进行英勇的数据收集即可执行。订户应能快速、反复地并通过自动化替换公开证书。根程序应保持事件报告足够公开，使信任决策可见。

Web PKI 的可信度取决于规则中令人不适的部分：错误签发或不合规的证书必须迅速从信任中移除，即使这在操作上是痛苦的。答案不是假装吊销总是无痛的。答案是建立证书运营，以便下一次强制吊销是一个受控的维护工作流，而不是围绕截止日期的全球混乱。