Cert-manager WebHook TLS证书问题排查与解决方案

问题现象

在使用cert-manager v1.17.2版本时，用户通过Helm模板结合Kustomize部署后，发现WebHook服务持续报TLS证书验证失败错误。具体表现为：

1. 日志中反复出现"tls: bad certificate"错误
2. 测试验证时出现x509证书签名未知的权威机构错误
3. 即使删除并重建CA Secret，问题依然存在

背景知识

cert-manager的WebHook服务需要有效的TLS证书来实现安全的通信。这个证书由内置的CA机构动态生成，并需要满足：

• 包含正确的DNS名称（服务名称和完整域名）
• CA证书需要被API服务器信任
• 证书链必须完整可验证

问题根源

经过分析，问题的根本原因是Kustomize配置中错误地指定了namespace属性。这导致了：

1. 资源被错误地重新命名空间化
2. WebHook服务的CA证书与API服务器期望的证书不匹配
3. 证书中的SAN（主题备用名称）可能被意外修改

解决方案

1. 移除kustomization.yaml中的namespace字段

   # 错误配置
   namespace: cert-manager
   
   # 正确配置
   resources:
     - namespace.yaml
     - rendered.yaml
   

2. 确保namespace通过独立的资源文件定义

   # namespace.yaml内容
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cert-manager
   

深入技术细节

当使用Kustomize时，namespace字段会导致所有资源被重新命名空间化，这会影响：

• WebHook服务的Service资源
• 证书中的SAN条目
• 服务发现机制

cert-manager的WebHook服务严格要求证书中的DNS名称必须精确匹配：

• cert-manager-webhook
• cert-manager-webhook.cert-manager
• cert-manager-webhook.cert-manager.svc

任何对这些名称的意外修改都会导致TLS验证失败。

最佳实践建议

1. 使用Helm直接安装时，避免与Kustomize混用
2. 如需定制，优先使用Helm的--values参数
3. 部署后使用官方测试资源验证安装
4. 检查WebHook服务的证书详情：

   kubectl get secret -n cert-manager cert-manager-webhook-ca -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -text
   

总结

这个案例展示了基础设施工具链中配置叠加可能带来的微妙问题。理解各工具（Helm/Kustomize）的工作机制和相互影响，对于解决这类证书问题至关重要。保持部署方式的简洁性和一致性，可以有效避免此类问题的发生。

对于生产环境，建议通过更系统化的方式管理证书生命周期，并建立完善的部署验证流程。