cert-manager证书签发失败问题排查：HTTP-01挑战传播检查404错误分析

问题背景

在使用cert-manager进行TLS证书自动化管理时，用户遇到了证书请求持续处于pending状态的问题。错误日志显示"propagation check failed"并伴随"wrong status code '404', expected '200'"的错误信息。虽然从外部网络可以正常访问ACME挑战URL，但cert-manager内部的传播检查仍然失败。

技术现象分析

从日志中可以观察到几个关键现象：

1. Nginx访问日志确认：外部请求确实到达了Nginx Ingress Controller，并返回了200状态码
2. cert-manager日志：控制器持续报告传播检查失败，预期200但实际收到404
3. ACME solver日志：挑战请求被正确处理，token验证通过

根本原因

经过深入排查，发现问题根源在于负载均衡器配置不当。用户环境中同时存在：

1. 传统的Nginx Ingress Controller（192.168.0.59）
2. 新部署的Cilium Gateway API（192.168.0.61）

前端HAProxy负载均衡器将流量随机分发到这两个后端服务，导致：

• 部分ACME挑战请求被发送到Cilium Gateway API而非Nginx Ingress
• 虽然从外部看请求成功（因为部分请求到达正确后端），但cert-manager的自我检查可能从集群内部发起，遭遇404

解决方案

1. 临时解决方案：在HAProxy中禁用对Cilium Gateway API的流量转发，确保所有ACME挑战请求都路由到Nginx Ingress Controller
2. 长期建议：
   • 为不同入口控制器配置不同的主机名或路径规则
   • 使用明确的IngressClass选择器确保流量正确路由
   • 考虑为cert-manager挑战使用独立的负载均衡配置

技术要点总结

1. cert-manager传播检查机制：不仅验证外部可访问性，还会从集群内部进行验证
2. 多入口控制器环境：需要特别注意流量路由规则，避免请求被错误分发
3. HTTP-01挑战原理：依赖特定路径（/.well-known/acme-challenge/）的可访问性
4. 调试技巧：
   • 同时检查外部访问和集群内部访问的行为差异
   • 验证所有可能的流量路径
   • 检查中间代理（如HAProxy）的配置和日志

最佳实践建议

1. 在生产环境部署多入口控制器时，应进行充分的测试验证
2. 为cert-manager挑战配置专用的IngressClass或特定路由规则
3. 定期验证证书续订流程，确保自动化过程可靠
4. 在复杂网络环境中，考虑使用DNS-01挑战方式可能更为可靠

通过这次问题排查，我们认识到在Kubernetes网络架构中，流量路由的每个环节都可能影响证书管理流程的正常运作。合理的网络规划和持续的验证是确保TLS自动化管理可靠性的关键。