Go TLS 客户端只在生产环境报证书错误怎么办

我遇到过一种很容易误判的故障：同一段 Go HTTPS 客户端代码在开发机上正常，部署到生产容器后却报 x509: certificate signed by unknown authority。通常不是“生产环境的 TLS 变了”，而是进程看到的信任根、服务端返回的证书链，或证书校验使用的主机名发生了变化。先不要把 InsecureSkipVerify 打开，按下面四步能较快定位。

先按错误文本区分信任链和主机名问题

先看错误的最后一段，不要只盯着“证书错误”四个字。certificate signed by unknown authority 多半表示客户端找不到能验证签发链的根；certificate is not valid for 或 hostname mismatch 则更像 SAN 与校验主机名不一致。如果同时出现连接超时或 no such host，还要先排 DNS 和网络，不能把它们归到 CA 问题。

在生产进程内确认 SystemCertPool 和 RootCAs

我通常先在应用进程里打印“能否加载系统池”，而不是在宿主机上运行一个看似相似的命令。x509.SystemCertPool() 返回系统证书池的副本；tls.Config.RootCAs 为 nil 时，TLS 才会使用主机的根 CA 集。若程序显式传入了一个空的 x509.NewCertPool()，生产请求就会立刻失去默认信任根。

package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
)

func tlsConfig() (*tls.Config, error) {
    // 读取运行环境的系统根证书；错误要保留给启动检查处理。
    roots, err := x509.SystemCertPool()
    if err != nil {
        return nil, fmt.Errorf("load system cert pool: %w", err)
    }
    // RootCAs 显式复用该池，避免无意中传入一个空池。
    return &tls.Config{
        RootCAs:    roots,
        ServerName: "api.example.com",
        MinVersion: tls.VersionTLS12,
    }, nil
}

如果生产服务使用企业自签 CA，不能用 x509.NewCertPool() 后只追加企业证书而丢掉公共根。应先加载系统池，再用 AppendCertsFromPEM 追加受控的 PEM 文件；加载失败就让启动失败，避免请求到了线上才变成模糊的 TLS 报错。

func configWithPrivateCA(caFile string) (*tls.Config, error) {
    // 系统根用于公共服务，企业 PEM 用于内部服务，两者合并到一个池。
    roots, err := x509.SystemCertPool()
    if err != nil {
        roots = x509.NewCertPool()
    }
    pemBytes, err := os.ReadFile(caFile)
    if err != nil {
        return nil, fmt.Errorf("read CA file: %w", err)
    }
    // 返回 false 说明文件不是可解析的 PEM 证书，不能静默继续。
    if ok := roots.AppendCertsFromPEM(pemBytes); !ok {
        return nil, fmt.Errorf("append CA file: no certificate found")
    }
    return &tls.Config{RootCAs: roots, ServerName: "api.internal.example"}, nil
}

上面的示例还需要补上 os import 才能编译；文章重点是池的合并关系。Unix 环境还可以检查 SSL_CERT_FILE 和 SSL_CERT_DIR 是否被生产启动脚本指向了空文件或错误目录。

检查容器镜像的 CA 包与证书链

“宿主机能访问，容器不能访问”时，优先比较容器内部，而不是只看宿主机的 /etc/ssl。极简镜像常常没有 CA bundle；即便有，也可能只包含公共根，而服务端使用的是企业中间 CA。可以在目标容器内查看常见路径和环境变量：

# 在目标容器内确认 CA 文件、目录和覆盖变量，不修改生产状态。
printf 'SSL_CERT_FILE=%s\n' "${SSL_CERT_FILE:-}"
printf 'SSL_CERT_DIR=%s\n' "${SSL_CERT_DIR:-}"
for f in /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt; do
  # 找到非空 bundle 才能说明镜像至少带有可读取的证书集合。
  if [ -s "$f" ]; then printf 'CA bundle: %s\n' "$f"; fi
done

如果没有可用 bundle，应在镜像构建阶段安装发行版对应的 CA 证书包，或把经过审核的企业 CA 以只读方式挂载，再通过应用配置传入。证书链也要一起看：服务端应返回叶子证书和必要的中间证书，客户端通常不应该把每一张服务器叶子证书硬编码成根。

对齐 ServerName 并做安全复查

根证书齐全后仍失败，最常见的下一层是名字不对。ServerName 用于验证返回证书的主机名，并会在非 IP 地址场景参与客户端握手的 SNI。比如请求地址是 https://10.0.0.8，证书却只签发给 api.internal.example，即使 CA 完全可信，也不能把 IP 当成这个域名。

生产配置建议把“连接地址”和“证书身份”分开表达：连接可以走内网解析或代理，但 ServerName 填证书 SAN 中的域名，并确认服务端会为这个 SNI 返回对应证书。修复后做一次真实的请求回归，同时保留正常证书链和主机名校验。

transport := &http.Transport{
    TLSClientConfig: &tls.Config{
        // 该名字必须出现在服务端证书的 SAN 中，并用于 SNI。
        ServerName: "api.internal.example",
        RootCAs:    roots,
        MinVersion: tls.VersionTLS12,
    },
}
client := &http.Client{Transport: transport, Timeout: 10 * time.Second}
resp, err := client.Get("https://10.0.0.8/health")
if err != nil {
    // 记录错误类型和目标，不记录证书私密材料。
    return err
}
defer resp.Body.Close() // 复查成功也要释放响应体，避免连接池泄漏。

不要用 InsecureSkipVerify: true 作为生产修复。它会跳过服务端证书链和主机名验证，适合短期测试，或只能与明确的自定义验证回调一起使用。最后把这次修复固化为启动检查：打印 CA 文件是否存在、校验目标域名是否配置、用健康请求确认返回码，后续换基础镜像时也能尽早暴露问题。

相关问题

RootCAs 设置成空的 CertPool 会怎样？

它不会自动回退到系统根证书。要么保持 RootCAs: nil 使用主机根，要么从 SystemCertPool 开始再追加企业 CA。

为什么本地用域名正常，生产用 IP 失败？

证书 SAN 常包含域名而不包含该 IP。保留可解析的证书域名作为 ServerName，不要靠关闭校验绕过。

只安装公共 CA 包还不够吗？

如果服务端证书由企业 CA 签发，还需要把受信任的企业根或中间 CA 以 PEM 形式加入池，并确保服务端链完整。