cert-manager中HTTP-01挑战失败问题分析与解决

问题现象

在使用cert-manager进行Let's Encrypt证书签发时，用户遇到了HTTP-01挑战失败的问题。具体表现为：

1. 生产环境证书申请失败，但测试环境(staging)可以正常工作
2. 错误日志显示cert-manager在尝试访问挑战URL时，意外地转向了8443端口
3. 虽然外部curl请求可以正常访问挑战URL，但cert-manager内部的自我检查失败

问题分析

从日志和用户提供的配置信息可以看出几个关键点：

1. 端口重定向问题：cert-manager在尝试访问HTTP挑战URL时，系统自动将请求重定向到了HTTPS的8443端口。这通常是由于Ingress控制器配置了强制HTTPS重定向导致的。

2. 网络策略影响：用户使用了Cilium网络策略，虽然已经开放了必要的端口(80、443、8089、8443)，但HTTPS重定向行为干扰了正常的HTTP挑战流程。

3. 自我检查机制：cert-manager会在内部执行自我检查，验证挑战URL是否可访问。当这个检查失败时，即使外部访问正常，证书申请也会失败。

解决方案

针对这个问题，有以下几种解决方法：

方案一：禁用Ingress的SSL重定向

在Ingress资源中添加注解，明确禁用SSL重定向：

metadata:
  annotations:
    haproxy.org/ssl-redirect: "false"

方案二：调整网络策略

确保网络策略不会阻止cert-manager对挑战URL的访问：

1. 确认所有相关端口(80、8089)都已开放
2. 检查是否有其他网络策略可能干扰流量

方案三：使用Ingress类特定配置

根据使用的Ingress控制器不同，可能需要特定的配置方式：

• 对于Nginx Ingress: nginx.ingress.kubernetes.io/ssl-redirect: "false"
• 对于Traefik: 需要配置相应的中间件

深入理解

HTTP-01挑战的工作原理是：

1. cert-manager创建一个临时的Pod来处理ACME挑战请求
2. 这个Pod监听8089端口，通过Service暴露
3. Ingress控制器将.well-known/acme-challenge路径的流量路由到这个Service
4. Let's Encrypt服务器会从外部访问这个URL进行验证

当系统强制将HTTP流量重定向到HTTPS时，会破坏这个验证流程，因为：

1. Let's Encrypt的验证服务器只使用HTTP协议
2. 重定向会导致验证失败
3. cert-manager的自我检查也会受到影响

最佳实践

为了避免这类问题，建议：

1. 在测试环境充分验证证书申请流程
2. 明确区分生产环境和测试环境的配置差异
3. 监控cert-manager的日志，及时发现潜在问题
4. 了解使用的Ingress控制器的具体行为

通过理解这些底层机制，可以更有效地排查和解决cert-manager证书申请过程中的各种问题。