Let's Encrypt 今天的错误率更高，持续了 90 分钟

故障影响与状态页语义

• 这次事件是由于上游网络问题导致的约 90 分钟证书签发错误率升高，而不是全天宕机。
• Let’s Encrypt 员工（以个人身份发帖）表示，大多数请求仍然成功；但有些用户报告在那段时间内反复出现 400/500 错误，且没有任何成功续期。
• 对“Degraded Performance（性能下降）”的理解存在混淆：有人将其理解为接近完全失效；也有人指出状态页措辞往往会淡化严重问题。
• 在“Active Incident（进行中的事故）”期间状态横幅仍显示绿色，被批评为具有误导性，尤其是在移动端上，详细状态文本会被挡在屏幕外。

更短的证书有效期 vs. 吊销

• 关于推动证书有效期不断缩短的争论（90 天 → 45 天 → 甚至更短）。
• 一方观点：更短的有效期可限制密钥被盗后的损害，并缩小 CRL；到期本就是该模型的核心。
• 另一方观点：更频繁的续期会增加对 CA 可用性和基础设施脆弱性的依赖；应当修复吊销机制。
• 目前普遍认为吊销机制有问题，不过也有人认为更新的机制（例如 Firefox 中的 CRLite）在很大程度上解决了这一点，只是还需要更广泛的厂商采用。

运维卫生与自动化

• 许多人强调，客户端应在到期前很早就开始续期（例如在 90 天有效期中的第 60 天），并且要带重试/退避，这样短暂故障就不会成为问题。
• 批评那些只在临近到期时才尝试续期的配置；这被比作持有一张技术上仍有效、但在到期前后实际上不可用的护照。

替代方案与中心化风险

• 有人认为 Let’s Encrypt 对于大部分互联网来说已是事实上的单点故障；也有人反驳说，ZeroSSL、Google Trust Services 等替代 CA 是存在的。
• 在危机中实际切换是否可行受到质疑：缺乏内建故障转移、其他 CA 可能面临负载激增，以及为同一密钥提供多个证书的复杂性。
• 更广泛的批评指向 web PKI 模型以及对美国 CA 的依赖；提议包括通过 DNS 发布自签名密钥，或加强对网络中介的监管。

浏览器如何处理过期证书

• 对于浏览器是否应当对刚过期的证书放宽错误处理存在分歧。
• 有人认为严厉失败是必要的，可以迫使正确自动化，并避免安全上的麻痹；也有人认为，带有时间维度的更细致警告可以在不显著增加风险的情况下改善可用性。