cert-manager证书自动续期排查的第一步，不是删除 Secret，也不是重启控制器，而是确认断点发生在哪里：Certificate 没进入续期、CertificateRequest 没被签发、ACME Challenge 没通过、Secret 已更新但入口仍返回旧证书，还是 TLS 在外部网关或 CDN 终止。
cert-manager 通过 Certificate、CertificateRequest、Issuer/ClusterIssuer 等资源声明和签发证书，并将结果写入 Secret[1]；使用 ACME 时还会创建 Order 和 Challenge 完成域名验证[2]。因此排查应沿着状态链路逐层收敛，而不是把所有异常都归因于 cert-manager。
如果你还在梳理入口 TLS 关系，可先结合 Kubernetes容器专题 理解 Ingress 与 Secret 的绑定；涉及安全基线时，可参考 Kubernetes安全怎么做 统一证书、权限和审计要求。
图1：cert-manager 从 Certificate 到
先做证据分层：外部证书、Secret 和 Certificate 不一定一致
用户看到“证书过期”时，至少要取三份证据。外部入口返回的证书说明用户真实看到什么；Kubernetes Secret 说明集群里保存什么；Certificate 状态说明 cert-manager 认为自己做到了哪一步。
`kubectl describe certificate`、Secret 读取方式和 ACME 资源检查应按 cert-manager 文档核对[1][2]，入口侧 TLS 绑定还要对照 Kubernetes Ingress TLS 规则[3]。
建议先记录：
- 入口证书：用浏览器或 openssl 查看域名实际 Not After。
- Secret 证书：解码 tls.crt 查看 Secret 中的到期时间。
- Certificate 条件：查看 Ready、Issuing、Renewing、Revision 等状态。
- Issuer 条件：确认 Issuer 或 ClusterIssuer 是否 Ready。
kubectl get certificate -A
kubectl describe certificate app-tls -n prod
kubectl describe issuer letsencrypt-prod -n prod
kubectl get secret app-tls -n prod -o yaml这些命令只用于观察，Certificate、Issuer 和 Secret 字段含义应按 cert-manager 与 Kubernetes 文档核对[1][3]。不要在没有确认断点前删除生产 TLS Secret，否则可能导致入口加载默认证书或触发不可控的重新签发。
断点矩阵：从 Certificate 向下定位
cert-manager 的资源状态通常能告诉你续期卡在哪一层。Certificate 负责声明期望证书并指向 secretName；CertificateRequest 承载一次签发请求；ACME Order 和 Challenge 负责域名验证；Secret 保存最终证书材料[1][2]。
| 断点位置 | 典型现象 | 优先排查方向 |
|---|---|---|
| Certificate | Ready=False 或长期 Issuing | dnsNames、issuerRef、renewBefore |
| CertificateRequest | 未 Approved 或未 Ready | approver、Issuer 可用性、错误事件 |
| Order | pending 或 invalid | ACME 账户、域名、CA 返回错误 |
| Challenge | pending、failed | DNS-01/HTTP-01 验证链路 |
| Secret | 未更新或 key/crt 缺失 | secretName、权限、外部覆盖 |
| Ingress/网关 | Secret 新但外部旧 | 控制器缓存、引用错误、外部 TLS 终止 |
Secret 不是唯一事实源
Secret 中证书已经更新，只能说明 cert-manager 写入成功。入口控制器可能没有重新加载，Ingress 可能引用了另一个 Secret，外部负载均衡或 CDN 也可能仍在返回旧证书。
图2：cert-manager 证书续期失败时从状态、事件到入
ACME Challenge：HTTP-01 和 DNS-01 要分开验证
使用 Let’s Encrypt 等 ACME CA 时，续期失败高频发生在 Challenge。cert-manager 官方说明 Order 和 Challenge 用于 ACME 域名所有权验证[2]。不同 solver 的证据完全不同，不能只看一个 controller 日志。
HTTP-01 重点看：
- Ingress class 是否被正确控制器处理。
- `/.well-known/acme-challenge/` 路径是否能从公网访问。
- Gateway、WAF、重定向或 HTTPS 强制跳转是否拦截验证请求。
DNS-01 重点看：
- DNS provider 凭据是否有效且权限足够。
- TXT 记录是否写入正确 zone。
- DNS 传播时间是否超过预期。
- 多 DNS 供应商或 split-horizon 是否造成外部不可见。
下面这些 Order、Challenge 和日志检查应结合 ACME 文档解释[2]：
kubectl get order,challenge -n prod
kubectl describe challenge app-tls-xxxxx -n prod
kubectl logs deploy/cert-manager -n cert-manager --tail=200失败重试前先保护现场
上述 Order、Challenge 和日志命令应结合 ACME Orders and Challenges 文档解释[2]。频繁删除 Certificate、Order 或 Secret 可能造成重复签发和速率限制风险。更稳妥的做法是保留事件、错误原因和当前 solver 配置，修复 DNS、Ingress 或 Issuer 后再触发验证。
入口仍返回旧证书：沿 TLS 终止点回证
当 Secret 已经更新但用户仍看到旧证书，排查重点要从 cert-manager 转向入口链路。Kubernetes Ingress TLS 通过 tls.secretName 关联证书 Secret[3]，但实际 TLS 终止可能发生在 Ingress Controller、Gateway、负载均衡或 CDN。
回证顺序建议如下：
- 确认 Ingress 的 `tls.secretName` 与目标 Secret 名称一致。
- 确认 Ingress 和 Secret 位于同一命名空间。
- 查看 Ingress Controller 是否报证书加载错误。
- 分别从集群内、入口 IP、公网域名验证证书。
- 检查外部网关、CDN 或负载均衡是否单独托管证书。
图3：从 Secret、Ingress Controller
预防：把续期风险变成提前告警
证书续期不应等到用户报错后才处理。平台团队应同时监控 Certificate 到期时间、Ready 条件、Challenge 失败、Secret 更新时间和入口证书剩余有效期。
建议建立四类告警：
- Certificate 距离过期低于阈值但未成功续期。
- CertificateRequest、Order 或 Challenge 长时间 pending。
- Secret 中证书已过期或即将过期。
- 外部入口返回证书与 Secret 证书指纹不一致。
小结
cert-manager证书自动续期排查要按证据链推进：外部入口返回什么、Secret 中保存什么、Certificate 与 ACME 资源状态是什么。只有三类证据对齐，才能判断续期是否真正成功。
生产环境不要把删除 Secret 当作默认修复。更可靠的路径是定位断点，修复 Issuer、DNS、Ingress 或入口加载问题，再验证用户真实访问到的新证书。
参考资料
- [1] cert-manager Certificate Resource
- [2] cert-manager ACME Orders and Challenges
- [3] Kubernetes Ingress TLS
常见问题
1. cert-manager证书自动续期一般提前多久触发？
续期时间取决于 Certificate 配置、证书有效期和当前 cert-manager 版本行为，应以官方文档和资源状态为准[1]。排查时重点看 Certificate 条件和事件，而不是只看证书到期日。
2. Certificate Ready=True 为什么浏览器仍显示旧证书？
这通常说明 cert-manager 已经写入 Secret，但入口链路没有加载该 Secret，或 TLS 在外部负载均衡、CDN、网关处终止。需要沿 TLS 终止点继续回证。
3. 删除 TLS Secret 能强制重新签发吗？
可能触发重新签发，但不建议作为首选动作。删除 Secret 会影响入口证书加载；如果 Issuer、DNS 或 Challenge 根因没有修复，新签发仍可能失败。
4. ACME Challenge pending 时先看日志还是资源事件？
优先看 Challenge describe 事件，因为它通常包含 solver 类型和失败原因。随后再看 cert-manager 控制器日志、DNS 记录或 HTTP-01 路径访问结果。
5. 如何避免续期问题到期当天才发现？
同时监控 Certificate 过期时间、Ready 条件、Challenge 状态、Secret 证书有效期和外部入口证书。只监控 cert-manager Pod 存活无法发现续期失败。
