Podman/Docker下Caddy反向代理用主机PKI证书遇tls错误求助

核心问题分析 #

错误本质是TLS握手过程中证书验证失败，可能发生在两个环节：

1. 客户端与Caddy的TLS握手
2. Caddy与上游服务（greeting-service）的TLS握手

结合企业PKI、禁用Auto-HTTPS的场景，以下是具体排查方向：

1. 证书链完整性检查 #

企业PKI环境下，证书必须包含完整链式结构（叶证书 + 中间CA证书），缺失中间CA会直接导致验证失败：

• 检查Caddy服务端证书：
  执行命令查看证书内容：

  openssl x509 -in /certs/test.crt -text -noout
  

  确认X509v3 Subject Alternative Name包含服务域名，且证书文件末尾是否追加了中间CA的PEM内容。如果只有叶证书，将中间CA的PEM文本直接追加到test.crt末尾。
• 检查客户端认证证书：
  用于上游服务客户端认证的test.crt同样需要完整链，否则上游服务无法通过信任链验证你的客户端身份。

2. SNI与证书域名匹配验证 #

TLS握手时的SNI（Server Name Indication）必须与上游服务证书的Subject Alternative Name (SAN) 或Common Name (CN) 完全一致：

• 确认OUTER_HOST环境变量的值与上游证书的SAN/CN完全匹配（包括大小写、域名格式，例如greeting-service.example.com而非greeting-service）。
• 可通过以下命令获取上游证书信息：

  openssl s_client -connect greeting-service:8443 -servername $OUTER_HOST < /dev/null | openssl x509 -text -noout
  

3. TLS客户端认证配置细节 #

Caddy的tls_client_auth指令要求证书文件包含完整链，同时需确认：

• 客户端证书与密钥的算法（RSA/ECDSA）与上游服务的要求兼容。
• 上游服务是否启用了客户端证书强制验证，且信任根包含你的客户端证书的CA。

4. 信任根配置有效性 #

tls_trusted_ca_certs /certs/trust.pem需包含上游服务证书的完整信任链（根CA + 中间CA）：

• 验证信任根是否能正确验证上游证书：

  # 先导出上游证书
  openssl s_client -connect greeting-service:8443 -servername $OUTER_HOST < /dev/null | openssl x509 -out upstream.crt
  # 验证信任关系
  openssl verify -CAfile /certs/trust.pem upstream.crt
  

  如果验证失败，说明trust.pem缺失必要的CA证书。

5. 容器内证书文件权限 #

Podman容器中，Caddy默认以非root用户（caddy）运行，需确保证书文件权限正确：

• 调整权限命令：

  chown -R caddy:caddy /certs
  chmod 755 /certs
  chmod 644 /certs/*.crt /certs/*.key /certs/*.pem
  

  可在容器启动脚本或Dockerfile中添加上述命令，避免权限不足导致Caddy无法加载证书。

6. 利用Debug日志定位具体环节 #

你的配置已开启debug模式，重点查看日志中的TLS握手细节：

• 如果日志显示remote error: tls: bad certificate，说明上游服务拒绝了Caddy的客户端证书，需检查客户端证书链或上游信任根。
• 如果日志显示Caddy验证上游证书失败，说明trust.pem配置有问题，或SNI不匹配。

对比NGINX配置的关键差异 #

NGINX的ssl_certificate默认要求完整链证书，反向代理时proxy_ssl_certificate同样需要完整链。确保Caddy的tls指令和tls_client_auth使用的证书文件与NGINX配置中的对应文件完全一致（包括链内容）。

内容的提问来源于stack exchange，提问作者Steve Storck