cert-manager ACME授权挑战陷入死循环问题分析

问题背景

在使用cert-manager配合ACME协议签发SSL证书的过程中，部分DNS-01类型的挑战会陷入"Pending"状态无法完成。具体表现为Challenge资源的状态持续停留在processing: true状态，而日志中则反复输出"waiting for authorization for domain"信息。

根本原因

经过深入分析，发现问题源于两个关键因素：

1. 上下文管理不当：cert-manager在调用ACME客户端的WaitAuthorization函数时，错误地传递了控制器上下文而非带超时的上下文。这意味着该操作只有在控制器关闭时才会终止，缺乏合理的超时控制机制。

2. ACME客户端容错缺陷：当ACME服务器返回200状态码但响应体包含非JSON格式内容时（如某些ACME服务商在限流时返回HTML格式的429错误），golang.org/x/crypto/acme库会静默吞掉解码错误，继续下一次重试，形成无限循环。

技术细节

在cert-manager的同步逻辑中，WaitAuthorization调用位于acmechallenges控制器的sync.go文件。该函数会持续轮询ACME服务器以检查授权状态，但由于使用了控制器的长期存活上下文，导致无法自动超时。

与此同时，底层的ACME客户端实现存在缺陷。当服务器返回200状态码但响应体无法被解析为有效JSON时（例如某些ACME服务商在达到速率限制时返回HTML格式的错误页面），客户端代码没有正确处理这种异常情况，而是简单地忽略错误继续重试。

影响范围

该问题影响所有使用cert-manager配合ACME协议签发证书的环境，特别是：

• 使用ZeroSSL等在某些情况下会返回非标准响应的ACME服务商
• cert-manager 1.15.0及更早版本
• Kubernetes 1.25及以上版本

解决方案

临时解决方案包括：

1. 更换更可靠的ACME服务商
2. 手动清理卡住的Challenge资源

长期解决方案需要修改cert-manager代码：

1. 为WaitAuthorization调用添加合理的超时上下文
2. 增强ACME客户端对非标准响应的错误处理能力

最佳实践建议

对于生产环境，建议：

1. 监控Challenge资源的处理时间，设置告警阈值
2. 定期检查是否有长期处于Pending状态的Challenge
3. 考虑使用更稳定的ACME服务提供商
4. 关注cert-manager的版本更新，及时应用相关修复

该问题的根本修复需要cert-manager项目团队对代码进行修改，建议用户关注官方更新并及时升级到包含修复的版本。