分享一次证书过期导致站点不可用的复盘，希望能帮到同样在用自动续期的同学。以下是社区整理的排查与修复过程。
「复盘：SSL 证书到期、自动续期却静默失败踩的坑」提醒我们一个朴素的事实：证书管理与 HTTPS 加固靠的不是临场发挥，而是平时的体系化建设。告警是否准确、日志是否齐全、权限是否收敛，决定了故障来临时是从容处置还是手忙脚乱。
现象
浏览器报 HTTPS 证书过期，而自动续期任务"看起来一直在跑"，证书却始终没更新。
根因
用 acme / Let's Encrypt 的 webroot（http-01）方式验证时，80 端口配置了无条件 301 跳转到 https，导致验证请求 /.well-known/acme-challenge/ 也被重定向，签发方拿不到验证文件，续期失败——而且是"静默失败"，直到证书过期才暴露。
排查
看续期日志、手动跑一次续期看具体报错、从外网访问验证路径确认是否可达（有没有被跳转或被防火墙挡住）。
修复
在 80 端口对 /.well-known/acme-challenge/ 放行，其余请求再做 301；确认验证目录权限与 nginx location 的匹配优先级；修复后手动续期成功并 reload。
预防
加"证书剩余天数"监控告警（如低于 20 天告警）、续期失败要能通知到人、定期演练续期流程。
小结：自动续期一定要配到期监控与失败告警，别让"静默失败"演变成"线上事故"。
到期监控要有三重保险，续期成功也要验证
自动续期只是把手动操作换成了定时任务，它并没有消除失败的可能。真正稳妥的做法是让「证书快到期」这件事有多个相互独立的发现渠道，并且在续期之后确认证书确实生效了。
- 外部拨测：用不依赖自身服务器的第三方监控检查证书剩余天数，低于设定阈值就告警。它的好处是即使本机定时任务全部失效，这条渠道依然有效。
- 内部巡检：定时读取本机实际加载的证书到期时间并上报，与续期日志放在一起看，能快速判断是「没续期」还是「续了但没生效」。
- 人工台账：把域名、证书类型、续期方式、验证方式、负责人记在一张表里，人员变动时不至于无人知晓，也不会出现某个二级域名被整体遗漏。
- 续期后验证：确认服务已重载新证书、证书链完整（缺少中间证书会在部分客户端报错）、多域名与泛域名的覆盖范围正确。
- 链路上的其他节点：如果流量经过 CDN、负载均衡或网关，证书需要在这些节点同步更新，只换源站并不会让访问者看到新证书。
使用文件验证方式时还要记住两个前提：验证路径必须在 80 端口可达且不被重定向，验证目录的写入权限与 Web 服务的路径匹配优先级要正确。这两点配错时续期任务会持续失败，而日志里往往只有一行不起眼的错误，等到浏览器弹出警告才发现就已经太晚了。
一份可执行的日常清单
- 暴露面盘点：定期梳理对外端口与服务，关闭不必要的开放。
- 权限最小化：账号与密钥按最小权限分配，定期回收闲置权限。
- 告警治理：清理长期无人响应的告警，保证留下的告警都值得处理。
- 预案演练：对高频故障场景准备处置预案并定期演练。
清单不复杂，难在坚持；而证书管理与 HTTPS 加固的差距，恰恰体现在坚持上。
把证书管理与 HTTPS 加固交给更专业的协作方
安徽卓牛为客户提供云上的安全加固、监控体系搭建与运维托管服务，能够结合阿里云安全与可观测产品，帮助团队建立可持续的运维安全体系，而非一次性整改。
若你希望就「复盘：SSL 证书到期、自动续期却静默失败踩的坑」涉及的内容做一次现状评估，可通过官网在线客服联系安徽卓牛，获取针对性建议。