Go TLS 客户端 自定义 CA 为何没有使用

先说结论：Go TLS 客户端的自定义 CA 没有生效，通常不是“Go 忽略了证书”，而是信任链没有完整接上。最常见的断点有四个：PEM 没有成功追加到 x509.CertPool，证书池没有赋给 tls.Config.RootCAs，tls.Config 没有挂到真正发请求的 http.Transport，或者请求仍然复用了另一套客户端。

下面按“证书输入、TLS 配置、HTTP 传输”三层拆开。示例只讨论客户端验证服务端证书的场景，不用 InsecureSkipVerify 绕过校验。

先确认自定义 CA 到底进入了哪一层

自定义 CA 不是直接塞进请求的字符串，而是先进入 x509.CertPool。AppendCertsFromPEM 返回 false 时，说明输入里没有成功解析出证书；如果忽略这个返回值，后面看到的 TLS 错误会把真正原因藏起来。

package main

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

func loadRoots(caFile string) (*x509.CertPool, error) {
    // 读取 PEM 文件；文件不存在时直接返回，避免把问题误判成 TLS 握手失败。
    pemBytes, err := os.ReadFile(caFile)
    if err != nil {
        return nil, fmt.Errorf("读取 CA 文件失败: %w", err)
    }

    // 使用系统根证书作为基线；企业私有 CA 会在同一个池中追加。
    roots, err := x509.SystemCertPool()
    if err != nil || roots == nil {
        // 某些精简系统没有可读的系统池，显式创建空池仍可继续追加私有 CA。
        roots = x509.NewCertPool()
    }

    // 返回值必须检查，否则格式错误的 PEM 会悄悄变成“自定义 CA 不生效”。
    if ok := roots.AppendCertsFromPEM(pemBytes); !ok {
        return nil, fmt.Errorf("CA 文件中没有可追加的 PEM 证书")
    }
    return roots, nil
}

这里的选择有明确边界：从系统池开始是“系统 CA + 私有 CA”，从 x509.NewCertPool() 开始则是“只信任私有 CA”。后者适合隔离测试或专用内网，但会让公共 HTTPS 证书不再被系统根信任。

把 CertPool 明确绑定到 tls.Config.RootCAs

RootCAs 是客户端验证服务端证书时使用的根证书池。只创建 CertPool 或只读取 CA 文件都不会改变 TLS 行为，必须把它放入实际使用的 tls.Config。

func newTLSConfig(caFile string) (*tls.Config, error) {
    roots, err := loadRoots(caFile)
    if err != nil {
        return nil, err
    }

    return &tls.Config{
        // RootCAs 决定客户端验证服务端证书时信任哪些根。
        RootCAs: roots,
        // ServerName 通常由请求地址推导；显式设置时必须与证书 SAN 匹配。
        ServerName: "api.internal.example",
        // 保持证书链和主机名校验，不用 InsecureSkipVerify 绕过问题。
        MinVersion: tls.VersionTLS12,
    }, nil
}

如果 CA 文件只包含中间证书而不包含可构建链的根，仍可能失败；客户端要信任的是能够把服务端证书链连到受信根的证书集合。另一个常见误会是把服务端证书本身当成 CA：除非它是自签名根并且确实作为信任锚使用，否则这不是可靠的配置方式。

为什么写了 tls.Config，实际请求还是没有使用

tls.Config 只有被 http.Transport.TLSClientConfig 持有，才会影响基于该 Transport 的 HTTPS 请求。下面把三层对象显式连起来，避免配置写在一个变量里、请求却走了另一个客户端。

func newHTTPClient(caFile string) (*http.Client, error) {
    tlsConfig, err := newTLSConfig(caFile)
    if err != nil {
        return nil, err
    }

    transport := &http.Transport{
        // 只有挂到真正使用的 Transport，RootCAs 才会进入 HTTPS 握手。
        TLSClientConfig: tlsConfig,
    }
    return &http.Client{
        // Client 持有这个 Transport；不要随后改用 http.DefaultClient。
        Transport: transport,
        Timeout:   10 * time.Second,
    }, nil
}

func fetch(ctx context.Context, client *http.Client, endpoint string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return err
    }
    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("HTTPS 请求失败: %w", err)
    }
    // 响应体必须关闭，避免连接资源泄漏；这里不把响应当作证书验证结果。
    defer resp.Body.Close()
    if resp.StatusCode >= http.StatusBadRequest {
        return fmt.Errorf("服务端返回状态码 %d", resp.StatusCode)
    }
    return nil
}

完整示例还需要导入 context、crypto/tls、fmt、net/http 和 time。这里的关键不是把字段写得更多，而是保证调用方拿到的就是这份 http.Client。

按症状定位自定义 CA 的断点

排查顺序建议固定为：先确认 CA 文件可解析，再确认 RootCAs 的归属，最后确认请求使用的 Transport。不要先把 InsecureSkipVerify 设为 true，那只能隐藏证书链或主机名问题，还会把客户端置于不安全状态。

常见问题

RootCAs 为空是不是代表没有使用任何证书？

不一定。客户端配置中的 RootCAs == nil 表示使用系统根证书池；需要加入私有 CA 时才应显式设置包含该证书的 *x509.CertPool。

为什么换了 CA 文件仍然像没有变化？

先确认请求对象没有换回默认客户端，再确认服务端实际发送的证书链确实由新 CA 签发。CA 只影响信任判断，不会改变服务端证书或请求地址。