证书过期多半不是没提醒，而是续期链路断了：cert-manager 该看哪些信号

上午 9 点 42 分，一个主域名的 HTTPS 握手开始大面积失败。浏览器给出 NET::ERR_CERT_DATE_INVALID，App 端直接白屏，支付回调在两分钟内积压了上千条超时。运维第一反应是"不是装了 cert-manager 吗，怎么会过期"，然后一边回滚到一张临时买的一年期证书，一边翻日志。28 分钟后站点恢复。

复盘会上最有价值的一条记录出现在 cert-manager 控制器的容器日志里：21 天前，一次 DNS-01 校验失败，报错是 DNS 服务商 API 返回 403，子账号的写权限被回收了。之后控制器按退避策略反复重试，同一条错误在日志里累计出现了 40 多次。换句话说，事故前整整三周，系统一直在喊，只是喊的地方是容器 stdout，没有任何一条告警规则在读它。

更尴尬的是，事故当天上午有人查过这张证书的剩余天数：还剩 6 天。监控阈值设的是 3 天，所以没响。而对一张有效期 90 天的证书来说，续期窗口早在到期前 30 天就该打开了，那 21 天里旧证书始终处于"有效"状态，任何只看剩余天数的监控都会认为一切正常。

真正断掉的从来不是提醒，是续期链路，而监控盯错了对象。

三周前就有失败日志：这次事故里提醒其实一直存在

把这次事故的时间线按天排出来，问题会看得更清楚。T-30 天，cert-manager 判定证书进入续期窗口，创建 CertificateRequest，向签发机构下 Order，Order 拆出两个域名各自的 Challenge。T-21 天，其中一个域名的 Challenge 进入 processing，控制器去调 DNS 服务商接口写 _acme-challenge 的 TXT 记录，拿到 403，Challenge 落为 invalid。T-21 到 T-1，控制器按指数退避重试，退避间隔从几分钟一路拉到几十分钟，每小时大约两次新增日志。T-0，旧证书到期，网关手里拿的还是那张过期证书。

这中间有三层"提醒"其实是存在的：Kubernetes 里 Challenge 资源的 status.state 一直是 invalid，Event 里写着 Challenge failed，日志里刷了三周。三层都没人看，因为告警体系里只挂了一条规则——证书剩余天数小于 3 天。而这条规则在整个风险期里从头到尾都是绿的。

这类事故的共性在于，失败发生在旧证书仍然有效的阶段。旧证书有效意味着用户无感、业务指标无波动、SLO 无异常，所有"结果型"监控都会沉默。等结果型监控终于响起来的时候，能用的处置时间已经从三周压缩成了几个小时，而且此时你面对的往往是两件事叠加：DNS 凭据要修，速率限制窗口可能也要等。

所以复盘时该换成另一个问法：为什么续期链路断了三周，我们没发现。

把证书当资源看：签发、校验、存储、加载四个环节

cert-manager 里一张证书不是一份文件，是一串有状态的 Kubernetes 资源。Certificate 是用户声明的期望：域名列表、有效期、用哪个 Issuer、私钥算法与位数。控制器据此生成 CertificateRequest，里面是一份 CSR。如果签发方是 ACME 协议，CertificateRequest 会对应一个 Order，Order 再按域名拆出若干 Challenge。全部通过后，最终产物是一个类型为 kubernetes.io/tls 的 Secret，里面放着 tls.crt 与 tls.key，有时还有 ca.crt。

这条链可以拆成四个环节，每个环节的失败模式完全不同，但最终表现都是"证书过期"四个字。

第一个环节是签发。Issuer 或 ClusterIssuer 里保存着 ACME 目录地址、账号私钥、以及 solver 配置。Issuer 是命名空间级资源，ClusterIssuer 是集群级。签发环节常见的问题是账号私钥 Secret 丢失导致重新注册账号、目录地址写错指向了 staging 却以为在生产、以及账号本身被签发机构限流。

第二个环节是校验，也就是 Challenge。签发机构要确认你真的控制着这个域名，方式只有 HTTP-01 和 DNS-01 两种，外加内部 CA 场景下的"不走校验"。这是整条链路上最脆的一环，因为它依赖集群外部的东西：80 端口能不能被公网访问、DNS 服务商的 API 能不能写。

第三个环节是存储。校验通过后证书被写进 Secret。这一环的失败通常不是失败，是"看起来成功"：Secret 被更新了，但更新的是旧的、或者只更新了一半。

第四个环节是加载。Ingress controller、Gateway API 实现、以及集群外那些不在控制器视野里的边缘节点，需要从 Secret 变更事件里拿到新证书并重新加载。这一环最容易被忽略，因为它不在 cert-manager 的管辖范围内——cert-manager 只保证 Secret 是对的，不保证网关真的加载了。

HTTP-01 与 DNS-01：两种校验方式的失败模式完全不同

HTTP-01 的原理是：签发机构拿着一个 token，用 80 端口去访问 http://<域名>/.well-known/acme-challenge/<token>，期望拿回的内容恰好等于 token 加上一个点再加上账号公钥的 JWK 指纹，逐字节一致，多一个换行都不行。这意味着它有三个硬性前提：该域名在公网能解析到你的入口 IP、80 端口从公网可达、以及这个路径的请求没有被你的 Ingress 规则半路截走。

它的失败模式很集中。最常见的是 80 端口只开在负载均衡上而节点安全组没放，签发机构的请求在建连阶段就超时。第二常见的是全站强制跳转——80 端口返回一个 301 到 HTTPS 首页，challenge 路径丢了，签发机构拿不到正确的响应体。第三类是 Ingress 上没有为这条路径配规则，请求被 default backend 接走，返回的是一个 404 页面或者首页 HTML。第四类是 cert-manager 的 solver Pod 只调度到了一个节点，而流量被负载均衡分到了其他节点。

DNS-01 的原理是：控制器往权威 DNS 写一条 TXT 记录，名字是 _acme-challenge.<域名>，值是一串 base64url 编码的摘要，一般 43 个字符上下。签发机构从自己的递归解析器去查这条记录，查到且值匹配就算通过。它不要求 80 端口可达，也不要求域名解析到你的 IP，代价是你要把 DNS 的写权限交到集群里。

DNS-01 的失败模式和 HTTP-01 几乎没有交集。第一类是凭据问题：子账号权限被回收、API Key 过期、只允许写特定前缀的域名。第二类是 API 限流：DNS 服务商对每秒请求数有限制，一次申请里多个域名并发写 TXT 容易撞上。第三类是传播：签发机构从公共递归解析器查询，如果你的权威服务器只对特定来源返回新记录，或者 TTL 设得很大、缓存还没过期，就会拿到旧值甚至 NXDOMAIN。第四类是 CNAME 委托：把 _acme-challenge 委托给第三方 DNS 时，委托链断了一环，控制器写了但签发机构查不到。

一个实用判断：如果你的入口在多层代理后面，或者你有任何一张通配符证书，HTTP-01 基本不用考虑。

通配符与内网域名：为什么很多团队最终都要上 DNS-01

通配符证书 *.example.com 只能通过 DNS-01 签发。这是 ACME 协议层面的约束，不是某家签发机构的偏好。只要你的域名列表里出现一个通配符条目，整个 Certificate 就会走 DNS-01，哪怕其余十个域名都是普通域名。

内网域名是另一个把人推向 DNS-01 的场景。形如 service.internal、*.svc.cluster.local、或者纯内网解析域名的证书，公网签发机构根本解析不到对应 IP，HTTP-01 无从谈起。这里有个折中做法：权威 DNS 是公网可查的，内网解析只是递归侧做了覆盖，那么 DNS-01 依然能工作，签发机构查得到 TXT 记录。但要注意 split-horizon 带来的排查困难——你在内网用 dig 查到的结果，和签发机构从公网查到的结果，可能不是一回事。排查时必须指定一个公共递归解析器去查。

还有一类场景干脆不走 ACME：内部 CA。用私有 CA、或者 Vault 这类 PKI 后端签发时，链路退化成 CSR 提交与签发两步，没有 Challenge 这个环节。这类部署看起来更简单，但把失败点挪到了别处：CA 根证书的有效期与轮换、CRL 分发点是否可达、OCSP 响应器是否存活、客户端有没有把新的根证书加进信任库。这些失败同样表现为"证书错误"，但排查路径完全不同。

上 DNS-01 的代价是凭据。把 DNS 服务商的写权限放进集群，意味着一个 Pod 沦陷可能波及整个域名的解析。收窄方式包括：只授予 _acme-challenge 前缀的 TXT 写权限而不给全域名写权限，用短期凭据（OIDC WebIdentity、实例角色）而不是长期 AK/SK，以及把凭据 Secret 的读取权限限制在 cert-manager 所在命名空间。

签发机构的速率限制：一个常被忽略的故障源

公开 ACME 签发机构都有限流，而且限流的维度比大多数人想象的多。以业界使用最广的那家公开签发机构为例，其公开文档给出的口径包括：每个注册域名每周 50 张证书；每个注册域名每周 5 张重复证书，续期豁免；每账号每 3 小时 300 个 pending authorization；每账号每 3 小时 300 个新 Order；每个主机名每账号每小时 5 次校验失败；每个 IP 每 3 小时注册 10 个账号。这些数字签发机构会调整，落地时以官网公示为准，但维度本身是稳定的：域名维度、账号维度、IP 维度、失败维度。

最容易踩的是"注册域名"这个计数口径。它指的是 Public Suffix List 里的 eTLD+1，a.example.com 和 b.example.com 都算在 example.com 这一个桶里，而 example.co.uk 按 example.co.uk 算。于是很多团队以为"每个子域名每周 50 张"，结果实际共用同一个配额。

第二个坑是校验失败的限流。失败限流是按主机名、按小时计的，一次 DNS 配置错误配上控制器的自动重试，一个小时内就能把配额耗尽。更要命的是，配额耗尽后即使你立刻修好了 DNS，接下来的一段时间里所有校验请求都会被拒，表现为 Order 返回 invalid、错误类型里带着 rateLimited 字样、响应头里带 Retry-After。日志里看到这个字符串，基本可以确定不是配置错，是撞墙了。

第三个坑来自流水线。很多团队的 CI 每次部署都新建一个临时命名空间、重建一遍全套资源，于是每次部署都触发一轮证书申请。几十条流水线跑上一天，"每周 50 张"就没了。正确做法是把证书申请从部署流水线里摘出来，证书作为长期资源单独管理，命名空间重建时复用已有的 Secret，或者干脆把签发集中到一个集群再做分发。

判断限流的一个实用动作：把签发机构返回的 rateLimited 事件单独做成一条告警，而不是让它淹没在"证书申请失败"里。这条告警的价值在于，它会早于证书到期很多天告诉你"现在修 DNS 还来得及，但你已经没有重试额度了"。

该盯的四个信号：Ready、续期窗口、Challenge、数据面是否已加载

第一个信号是 Certificate 的 Ready 条件。用 jsonpath 取出 status.conditions 里 type 为 Ready 的那一项，看它的 status 是 True 还是 False，以及 reason 字段给出了什么。Ready 为 False 且 reason 指向签发失败，这是最直接的告警源。要留意一种情况：Ready 一直是 True，但底下挂的 Secret 是旧的，这种情况 Ready 帮不了你。

第二个信号是续期窗口有没有被打开。Certificate 上有两个关键字段：spec.duration 与 spec.renewBefore，默认值分别是 2160 小时（90 天）和 720 小时（30 天），也就是在证书有效期走完三分之二时发起续期。控制器会在 status 里写入 renewalTime，表示计划续期的时间点。该盯的是"renewalTime 已经过去、但证书序列号没变"，这说明续期被排上了却没成功。另一种更隐蔽的情况是 renewalTime 压根没被写入，说明这个 Certificate 根本没被控制器正常处理。

第三个信号是 Challenge 的状态。status.state 会经历 pending、processing、valid、invalid、expired 几种取值。真正要告警的不是某一次 invalid，而是"连续失败次数"和"invalid 持续时间"。因为单次失败可能是网络抖动，控制器会重试；连续失败三周，就是凭据层面的问题。把 Challenge 的失败次数按域名打标签做成计数器，告警规则挂在"某个域名连续失败超过 N 次"上。

第四个信号是数据面是否真的加载了新证书。这是四个信号里唯一需要跳出集群去观测的。做法是从集群外部做一次带 SNI 的 TLS 握手，取出返回的证书序列号与 notAfter，再和 Secret 里那张证书的序列号与 notAfter 比对。命令形如用 openssl s_client 连接入口地址并用 -servername 指定域名，管道接 openssl x509 取 -serial 与 -dates。两边对不上，就是加载环节断了。

这四个信号应该串成一条链：Ready 为 False 说明期望没达成，renewalTime 逾期说明流程没推动，Challenge 失败说明卡在哪一环，序列号不一致说明产物没生效。只看其中任何一个都不够，只看剩余天数则等于什么都没看。

剩余天数是结果指标：为什么等它报警已经晚了

剩余天数等于 notAfter 减去当前时间，它是一个结果，也是一个滞后量。它的数值大小只反映"上一次成功续期发生在什么时候"，完全不反映"下一次续期能不能成功"。在一个续期已经断了三周的集群里，剩余天数会从 60 天一路平滑地降到 0，全程没有任何异常信号。

更麻烦的是时间账。假设证书有效期 90 天，续期窗口在到期前 30 天打开。如果续期在第 31 天就失败了，你看起来还有 30 天可以处置。但真实的处置链条是这样的：发现（取决于告警有没有，可能几天）→ 定位（翻日志确认是 DNS 凭据还是限流）→ 修 DNS 权限（走一次内部审批）→ 等限流窗口过去（几小时到一天）→ 重新触发续期并观察 Challenge → 确认网关已加载。这条链顺利也要两三天，不顺利就是一周以上。剩余天数阈值设成 3 天，等于把处置窗口压缩到几乎为零。

合理的阈值应该挂在过程指标上：renewalTime 过去超过 24 小时但证书序列号未变，告警；Challenge 连续失败超过 3 次，告警；出现 rateLimited 错误，告警；外部探测序列号与集群内不一致超过 10 分钟，告警。这四条里没有任何一条依赖剩余天数。

如果一定要保留剩余天数告警，把它当作兜底而不是主防线，阈值也别设 3 天。对 90 天有效期的证书，兜底阈值放在 15 天比较合适：此时你至少还有一次完整的续期窗口可以重试，而且不至于在到期前两天才被动应急。

私钥与新证书不匹配：续期成功但站点仍报错的几种情况

有一类故障特别消耗排查时间：cert-manager 显示一切正常，Secret 也确实被更新了，但访问站点依然报证书错误。这类问题的共同点是证书链路上"部分更新"或"部分加载"。

第一种是私钥与证书不匹配。Secret 里 tls.crt 换了新的，tls.key 还是旧的，或者反过来。验证方法很直接：分别对证书和私钥取 modulus 再做 md5，两个 md5 必须相同。命令形如 openssl x509 -noout -modulus 与 openssl rsa -noout -modulus，各自管道进 openssl md5。不同的话，网关加载时会直接报私钥不匹配，或者干脆拒绝加载、继续用内存里的旧证书。

第二种是中间证书链不完整。tls.crt 里只有叶子证书，缺了中间 CA。桌面浏览器大多能通过 AIA 扩展自行补全，所以你在 Chrome 里看是正常的，但部分 Java 客户端、老版本 Android、以及不少爬虫会直接报链不完整。判断方法是外部握手时看返回的证书链有几层。

第三种是多副本只重载了一部分。Ingress controller 有四个副本，其中两个拿到了新 Secret 事件并重新加载，另外两个因为 watch 断连后没有重新 list，手里还是旧证书。表现是"刷新几次好一次坏一次"，用负载均衡的会话保持还复现不出来。排查时要循环发起足够多次握手，直到命中所有副本，逐个比对序列号。

第四种是 SNI 落空。客户端没有带 SNI，或者带了证书里没有的域名，网关返回默认证书。这种情况下外部探测如果没指定 -servername，拿到的序列号和你预期的不一样，很容易误判成"没加载"。

第五种是客户端侧缓存。OCSP 响应、HSTS 策略、以及某些客户端本地的证书缓存，会让已经修好的站点在个别用户那里继续报错几小时。这类问题不需要动服务端，只需要能识别出来，避免把排查方向引错。

多集群与多入口：证书资源分散时的统一视图怎么做

多集群的第一个问题是重复签发。同一个域名在三个集群各跑一套 cert-manager，就会各签一张证书，而签发机构的配额是按注册域名算的，三个集群共享同一个每周 50 张的桶。更糟的是三个集群都不知道彼此的存在，撞上限流时只能各自重试，把失败配额也一起烧掉。

多入口的问题更隐蔽。集群里可能有 Ingress controller 和 Gateway API 两套数据面，集群外还有一层不在 Kubernetes 里的边缘节点或硬件负载均衡。cert-manager 只管到 Secret 为止，集群外那几层拿的是手工上传或者另一套同步机制推过去的证书，它们不出现在任何 Certificate 资源里，也就不会出现在任何基于 Certificate 的监控视图里。

做统一视图的可行路径有几步。第一步，每个集群部署一个 exporter，把 Certificate 的 Ready 状态、renewalTime、Challenge 状态导出成指标，统一打上 cluster 和环境标签，推到同一个时序库。第二步，用同一套告警规则覆盖所有集群，规则里不要写死集群名。第三步，叠加一层外部探测：从至少两个不同的网络位置、对每个入口做 TLS 握手，取序列号与 notAfter，和集群内声明的值比对。第四步，用 GitOps 管理 Certificate 资源的期望状态，任何手改都会被下一次同步覆盖，避免配置漂移。

还有一个能显著减少限流压力的做法：同一域名只在一个集群签发，签发完成后通过 Secret 同步机制分发到其他集群。这样配额消耗从 N 张降为 1 张。代价是同步链路本身成了新的单点，所以同步任务必须有独立的监控——同步失败三个月没人发现，效果和续期失败是一样的。

标签规范也值得提前定死。每个 Certificate 至少带上 app、owner、env、domain 四个标签，否则告警触发时没人知道该派给谁。owner 标签缺失是多集群环境里告警无人认领最常见的原因，比任何技术问题都常见。

基础设施层面，cert-manager 控制器、Ingress 网关、以及外部探测节点都是常驻进程，需要有稳定的运行环境与足够的网络出口。像一万网络这类深耕 19 年（成立于 2007 年）的服务商所提供的服务器，可以作为承载这类证书管理与网关服务的配置参考对象，具体规格与价格需实时询价。

演练与验收：怎么在不影响线上的情况下验证续期链路

演练的第一原则是不要在生产签发目录上练。公开签发机构都提供 staging 目录，staging 签出来的证书不被浏览器信任，但校验流程、Challenge 行为、以及控制器状态机与生产完全一致。先在 staging 上把 DNS-01 跑通，再考虑动生产。

演练可以拆成五步。第一步，在 staging 上创建一个与生产同结构的 Certificate，确认 Challenge 能走到 valid，这验证的是凭据与 solver 配置。第二步，用一个独立注册域名的测试域名，避免消耗生产域名的每周配额。第三步，手动触发一次续期——删除 CertificateRequest，或者给 Certificate 打上重新签发的注解，然后逐段观察 Order、Challenge、Secret 的变化时间戳，算出每一段耗时。第四步，做外部握手，确认返回的序列号已经变成新的。第五步，故意破坏一次：把测试域名的 DNS 凭据临时改成无效值，看告警是否在预期时间内触发。

第五步是整套演练里最有价值的一步。它的目标只有一个：验证续期失败时监控到底会不会响，至于续期本身能不能成功，那是前三步已经验过的。绝大多数团队从来没验证过这一条，于是才会出现日志刷了三周没人知道的情况。

验收清单建议做成发布门禁，每新增一个域名就跑一遍：Certificate 的 Ready 条件为 True；Secret 里证书与私钥的 modulus 一致；证书链包含叶子与中间证书；外部探测拿到的序列号与 Secret 里一致；外部探测拿到的 notAfter 与 Secret 里一致；循环探测后所有副本返回的序列号都相同。六项全过才算这个域名的续期链路是通的。

演练频率建议不低于每季度一次，并且在 DNS 服务商或签发机构有变更时追加一次。演练用的 staging 证书千万不要推进生产网关，浏览器会报不受信任，那会制造一次和 expired 很像、但排查方向完全不同的事故。

做证书自动化之前，运维和业务通常还会问这些

问：cert-manager 版本升级会不会导致存量证书批量重签？

答：大版本升级时控制器可能对资源做重新协调，若配置的默认 duration 或私钥算法发生变化，会触发重新签发。升级前应在一个非关键集群先升，观察 CertificateRequest 的新增速率，并把升级窗口安排在限流配额充裕的时间点。

问：一个 Certificate 里塞多少个 SAN 域名合适？

答：技术上没有硬上限，但 SAN 越多，任意一个域名的 Challenge 失败都会让整张证书签发失败，遇到校验失败限流时也会连带影响其他域名。实践中建议按业务边界拆分，而不是把所有域名塞进一张证书。

问：DNS 服务商的 API 凭据放进集群，权限怎么收窄？

答：只授予 _acme-challenge 前缀下 TXT 记录的写权限，不给整个域名的解析写权限；优先用短期凭据（OIDC WebIdentity、实例角色）而不是长期 AK/SK；凭据 Secret 所在命名空间限制只有 cert-manager 能读。

问：不在集群里的边缘节点和硬件负载均衡，证书能不能一起管？

答：cert-manager 只覆盖到 Secret，集群外那一层需要单独的同步机制。可以把统一签发集群的 Secret 作为唯一来源，由同步任务推送到集群外的节点，同时给同步任务挂独立监控，并纳入外部探测的覆盖范围。

问：证书私钥能不能进 Git 仓库或配置库？

答：不能。私钥属于密钥材料，应当只存在于集群 Secret 里，并开启静态加密与访问审计。GitOps 管的是 Certificate 这种声明式期望状态，不是签发出来的私钥本身。

问：续期一直失败，cert-manager 会重试多久，会不会彻底放弃？

答：控制器按指数退避重试，间隔会逐渐拉长，日志里表现为失败频率越来越低。它会持续重试而不是彻底放弃，这既是好事也是陷阱：持续重试意味着失败配额被持续消耗，同时因为旧证书仍有效，业务侧毫无感知。

问：内部 CA 场景要不要也上 cert-manager？

答：值得上，因为存储与加载两个环节的管理难度是一样的。但没有 Challenge 环节，监控重点要换成 CSR 签发成功率、CA 根证书有效期、以及 CRL 分发点与 OCSP 响应器的可达性。

问：前面还挂了一层 CDN 或加速服务时，证书该签在哪一层？

答：分层处理。面向用户的那一层用该服务自身的证书托管能力，源站与回程这一段用 cert-manager 签发的证书。两层的到期时间不同步，需要分别纳入监控，不能只盯其中一层就认为整条链路安全。

这篇里的校验超时与窗口数字该怎么按自己的签发机构复算

文中出现的速率限制数字，来自公开 ACME 签发机构的公开文档口径，签发机构会不定期调整，落地时以对方官网公示为准。复算方法分三步。

第一步，确认计数口径。查清对方的限流按什么维度算：注册域名是取 eTLD+1 还是完整主机名，账号维度按 ACME 账号私钥算还是按 API Key 算，失败校验是按账号、按主机名还是按源 IP。这一步决定了你的配额到底是"每个子域名一份"还是"整个主域名共享一份"。

第二步，估算自己的消耗量。把三个数加起来：稳态消耗等于域名数量乘以每月续期次数；异常消耗等于一次故障期间控制器重试次数乘以故障时长，按指数退避估算，一次长故障一天可以产生几十次校验；峰值消耗等于流水线重建命名空间时触发的申请次数。三者之和要明显小于周配额，否则就要做集中签发。

第三步，反推处置窗口。设证书有效期为 D，续期提前量为 R，那么从续期窗口打开到证书到期有 R 天。处置窗口等于 R 减去四段时间：告警从触发到有人响应的时间、定位到具体环节的时间、修复外部依赖（DNS 权限、防火墙）的时间、限流窗口的等待时间。第四段时间直接取自对方返回的 Retry-After。若算出来的处置窗口小于两天，说明 R 设得偏小，应当调大 renewBefore，或者改用有效期更短的证书换取更多的续期次数——续期次数越多，单次失败的后果越小，但配额消耗越大，两者要权衡。

这几个数字一旦算完，就应该写进告警规则而不是写在文档里。因为文档不会在凌晨三点提醒你，而一条"renewalTime 逾期 24 小时且序列号未变"的规则会。