2026 年 9 月 11 日上午，全球最大的免费证书颁发机构 Let’s Encrypt 出现服务中断。据IT之家报道，官方状态页面显示「部分服务中断（Partial Service Disruption）」，域控制验证（Domain Control Validation，DCV）失败率异常升高，直接影响证书签发与续期。
好消息是，这次故障并未持续太久。从官方首次响应到标记恢复，全程约 59 分钟，目前已恢复正常。
一、事件时间线：不到一小时完成定位与恢复
根据 Let’s Encrypt 官方状态页原始记录，本次事件的完整时间线如下（括号内为协调世界时 UTC）：
| 时间（北京时间） | UTC 时间 | 状态 | 官方说明 |
|---|---|---|---|
| 09:40 | 01:40 | 调查中 | 正在调查过去一小时内域控制验证失败率升高的问题，该问题可能导致订阅者无法获取证书。 |
| 10:11 | 02:11 | 已定位 | 问题定位为次级验证（secondary validation）中的 DNS 解析器，相关变更正在回滚，预计 15 分钟内恢复运营。 |
| 10:39 | 02:39 | 已解决 | 事件已解决，验证恢复正常（Validations are succeeding）。 |
受影响的服务组件为两个 ACME 接口：acme-v02.api.letsencrypt.org（生产环境）与 acme-staging-v02.api.letsencrypt.org（测试环境），涉及的机房为两个高保证数据中心（High Assurance Datacenter 1 与 2）。
二、故障根源：次级验证里的 DNS 解析器
官方在 10:11 的更新中给出了关键线索——问题出在次级验证（secondary validation）环节的 DNS 解析器上。这里需要解释一下 Let’s Encrypt 的验证机制，才能理解为什么一个内部组件的变更会卡住全球证书签发。
Let’s Encrypt 签证书前必须确认申请者真的控制了该域名，这个过程就是域控制验证（DCV）。为了防御 BGP 劫持一类的网络层攻击——攻击者把验证流量劫持到自己的服务器，从而骗取合法证书——Let’s Encrypt 从 2020 年起采用了多视角验证（业内标准化为 MPIC，Multi-Perspective Issuance Corroboration）：除了从自家数据中心发起验证，还会从全球多个独立网络视角同时发起验证请求，只有当多数视角的结果一致时才算验证通过。
这套机制正是本次故障的关键：验证请求的第一步是解析域名 DNS，而「次级验证」用的 DNS 解析器一旦异常，多个远程视角的验证就会集体失败，表现为 DCV 整体失败率飙升。故障性质是内部变更引发，不是外部攻击，官方给出的处置方式是直接回滚该变更。
这也说明一个常被忽略的事实：像 Let’s Encrypt 这类高度自动化的基础设施，其可用性风险往往来自内部变更而非外部攻击。回滚能在一小时内完成收尾，属于成熟运维的表现。
三、影响范围：3 亿网站依赖，错误会向下游传导
Let’s Encrypt 由互联网安全研究小组（ISRG）运营，是世界上最大的证书颁发机构，超过 3 亿个网站使用其服务。几个关键判断：
- 已签发的证书不受影响。这点很重要——正在运行的网站不会因为这次故障立刻掉 HTTPS，中断只发生在新签发与续期环节，所以表现为「流程卡住」而非「网站挂掉」。
- 影响会向下游平台传导。云厂商的状态页给出了实证：MongoDB Atlas 在事件期间同步发布公告，称因 Let’s Encrypt 故障导致证书签发错误率升高，免费版与 Flex 层集群的开通出现延迟。也就是说，PaaS 平台的自动化建站、自动化签约流程会跟着受影响。
- 对正在部署 HTTPS 的站点影响最直接。如果你正好卡在证书到期前的那几天做续期，这类故障会让人非常被动。
四、如果遇到类似故障，站长应该怎么做
先明确一个原则：证书故障期间，第一件事不是换 CA，而是先看自己的证书还剩多少天。Let’s Encrypt 的证书有效期 90 天，官方建议在剩余约 30 天时自动续期，这意味着正常情况下你有 30 天的缓冲——一次几小时的中断，完全等得起。
第 1 步：先做现状排查
用一条命令确认证书的剩余有效期和签发者：
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates重点看 notAfter。如果还有 20 天以上，什么都不用做；如果已经进入 14 天以内的红色区间，才需要考虑下面第 3 步的应急方案。
第 2 步：确认失败原因，避免白折腾
强制重试一次续期，把错误信息看清楚：
certbot renew --dry-run常见的续期失败其实和 CA 无关：80/443 端口被防火墙拦截、webroot 路径写错、DNS 解析异常。这三个自查项能解决绝大部分续期失败。如果错误信息明确指向验证请求超时或 DCV 失败，且时间点和官方故障窗口吻合，那就是 CA 侧的问题，直接等恢复即可。
第 3 步：确实紧急时的两条应急路线
路线 A：强制续期指令。如果判定故障已恢复、只是本机还在等待下一次定时任务，可以直接强制触发：
# certbot
certbot renew --force-renewal
# acme.sh
acme.sh -f -r -d yourdomain.com路线 B：临时切到备用 CA。ZeroSSL 是免费 ACME 生态里最常用的替代选择，支持 90 天 DV 证书与通配符，在 certbot、acme.sh、Caddy 里都能通过改一行配置切过去。
但这里有个极其容易踩的坑：CAA 记录。很多站长在申请 Let’s Encrypt 证书时，顺手在 DNS 里加了限制性 CAA 记录：
# 查看当前 CAA 记录
dig CAA yourdomain.com +short如果返回结果里只有 issue "letsencrypt.org"，那么它会明确告诉所有其他 CA「不允许为我签发证书」——你切到 ZeroSSL 也会失败，而且报错通常不够直观。正确做法是先修改 CAA 记录，把新 CA 加进去或直接移除限制，等 DNS 生效（通常几分钟）后再执行续期。另外，各家 CA 都有速率限制，故障期间不要批量迁移几百个站点，只处理真正紧急的那几个。
第 4 步：故障恢复后，回头检查「静默失败」
真正危险的不是这次中断本身，而是续期任务失败了却没人发现。建议做三件事：把 ACME 客户端的续期结果接入监控告警（失败即通知，而不是让脚本默默写日志）；在证书剩余 20 天时设置一次人工巡检；条件允许的话配置双 CA 冗余——主用 Let’s Encrypt，备用 ZeroSSL，通过 acme.sh 的 CA 切换能力做自动降级。
五、写在最后
这次故障本身不算严重：59 分钟完成定位与恢复，已签发证书零影响，属于一次「有惊无险」的演练。但它暴露了一个值得所有站长警惕的结构性问题——证书生态的集中度太高了。约六成以上的 HTTPS 站点依赖 Let’s Encrypt，而当行业同时推动证书有效期从 90 天向 45 天甚至 6 天演进时，单次 CA 故障造成的影响窗口会被显著放大：90 天证书在剩余 30 天续期还有 30 天缓冲，45 天证书只剩 15 天，6 天短周期证书的缓冲只有几个小时。
换句话说，证书自动化程度越高、有效期越短，对监控告警和备用方案的要求就越高。建议每个站长都做一次简单的自查：你的证书还有多少天到期？续期任务是自动执行的吗？失败了有人知道吗？这三个问题的答案，决定了下次 CA 出问题时你是从容等待还是手忙脚乱。
如果你的站点在应对证书到期、HTTPS 配置上遇到问题，或者需要处理大流量攻击、WAF 防护一类的安全需求，可以了解速度网络的相关高防产品（包年包月，买多少峰值防多少，无任何后付费），作为站点安全防护体系的一环。
