READY False：cert-manager 证书一直不 Ready 怎么排查

Certificate 卡在 READY False 的意思是：cert-manager 还没拿到签好的证书，原因藏在它创建的下层资源里。 对 Let's Encrypt 这类 ACME 签发者，链条是 Certificate → CertificateRequest → Order → Challenge，沿着链条往下找，第一个报错的资源就是要修的地方。

快速修复

沿 Certificate → CertificateRequest → Order → Challenge 逐级 describe，第一个报错的资源就是故障点。在 Certificate 所在的命名空间里执行：

kubectl describe certificate example-com -n web
kubectl get certificaterequest,order,challenge -n web
kubectl describe challenge -n web
kubectl describe clusterissuer letsencrypt-prod

Challenge 的 Status 和 Events 里通常有 CA 返回的原文（比如 404、超时、DNS problem）。把它修好，然后等 cert-manager 重试，或者删掉失败的 CertificateRequest 重新开始。

原因

Certificate 不 Ready 有 5 类原因，ACME 签发时最常见的是 HTTP-01 验证请求进不了集群。

1. HTTP-01 验证请求到不了

CA 要通过你的 Ingress 访问 http://<域名>/.well-known/acme-challenge/<令牌>，cert-manager 会为此临时创建求解器 Pod、Service 和 Ingress。

• 确认： Challenge 显示 Waiting for HTTP-01 challenge propagation，或者 wrong status code '404' 之类的错误；从外部 curl http://example.com/.well-known/acme-challenge/test 到不了集群。
• 修复： 求解器的 ingressClassName（或 class 注解）要和你的 Ingress 控制器一致；控制器的 LoadBalancer 要对外开放 80 端口（阿里云 SLB、腾讯云 CLB 的监听和安全组都要放行）；强制 HTTPS 跳转、鉴权中间件要对验证路径豁免；域名解析要指向 Ingress 的负载均衡地址。

2. DNS-01 凭据、区域或生效时间

• 确认： Challenge 报 API 错误（403、invalid credentials）、NXDOMAIN，或者一直在等待生效。
• 修复： 检查求解器引用的 Secret 和 DNS 服务商的权限（阿里云 RAM 子账号要有云解析权限）；确认求解器操作的是实际生效的区域。集群用了内外网分离解析时，给控制器设置 --dns01-recursive-nameservers 指向公网 DNS。参见 NXDOMAIN。

3. Issuer 不是 Ready 或引用错了

• 确认： kubectl get issuer,clusterissuer -A 显示 READY False，或者 CertificateRequest 提示找不到 issuer。
• 修复： Issuer 是命名空间级的，只服务同一命名空间的 Certificate；全集群共用要在 issuerRef 里写 kind: ClusterIssuer。同时检查 ACME server 地址、邮箱和账户私钥 Secret。

4. CA 拒绝了订单

• 确认： Order 或 CertificateRequest 的信息里有 rateLimited、caa 或 rejectedIdentifier。
• 修复： 见 Let's Encrypt 速率限制 和 CAA record prevents issuance。不是合法公网域名的名字，公网 CA 无法签发。

5. Secret 冲突或 webhook 异常

• 确认： 事件里提到和已有 Secret 冲突，或者 cert-manager webhook 无法访问（failed calling webhook）。
• 修复： 一个 secretName 只能由一个 Certificate 管理；确认 cert-manager、cainjector、webhook 三个 Pod 都在运行，网络策略允许 API Server 访问 webhook。

各环境修法

各环境的共同要求是让 CA 能访问到验证路径或查到 DNS 记录；公网访问不到 80 端口的集群改用 DNS-01。

在 Ingress 上加注解（cert-manager.io/cluster-issuer）： cert-manager 会自动创建 Certificate，名字就是 tls.secretName，按这个名字 describe。

Gateway API： 通过 Gateway API 做 HTTP-01，需要在求解器里配置 gatewayHTTPRoute，并且 Gateway 有 80 端口的监听。

私有集群或 NAT 后面的集群： HTTP-01 需要公网能访问 80 端口，做不到就用 DNS-01。

云负载均衡： 负载均衡上的健康检查、WAF 规则可能拦截或重定向验证请求，对验证路径豁免。

先用测试环境： 用 staging 的 ClusterIssuer 排错，不消耗正式环境的额度。

证书签下来之后： 用 kubectl get secret <名称> -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates -issuer 确认 Secret 里的证书确实是新签发的、签发者正确；再用 SSL 检测工具从外部确认 Ingress 实际对外出示的是这张证书，而不是控制器自带的默认假证书。

不要这样做

这 3 种做法会耗光签发额度、扩大明文 HTTP 的暴露面，或者让证书到期后无人续期。

• 反复删了重建 Certificate。 每个新 Order 都计入 CA 的限制，先修好失败的环节。
• 为了让验证通过全局关闭 HTTPS 跳转。 只豁免 /.well-known/acme-challenge/。
• 手动把证书塞进 Secret，Certificate 放着不管。 它不会续期，到期时悄无声息地失效。