为内部 HTTPS 客户端加载自建 CA 而不是跳过证书校验

我在给内部服务接 Go HTTPS 客户端时，最不愿意留下的临时修复就是 InsecureSkipVerify: true。它确实能让自签名证书“先跑起来”，但同时跳过了服务端证书链和主机名校验。更稳妥的做法是把内部 CA 的 PEM 内容加入 x509.CertPool，再放进 tls.Config.RootCAs，让客户端继续验证证书。

内部 CA 不被系统信任时，扩充客户端的信任根；不要用关闭校验来掩盖信任链或证书 SAN 配置问题。

本文示例保留系统根证书，因此既能访问公网 HTTPS，也能访问由内部 CA 签发的服务。Go 官方文档：

crypto/tls：https://pkg.go.dev/crypto/tls

crypto/x509：https://pkg.go.dev/crypto/x509

先分清是 CA 不信任还是主机名不匹配

客户端访问 https://api.intra.example/health 时，至少要同时满足两个条件：服务器证书链能追溯到 RootCAs 中的根，并且访问主机名能匹配证书的 SAN。只追加 CA 不能修复“证书签给了另一个名字”的问题；反过来，主机名写对了，也不能代替内部 CA。

把内部 CA 加进 CertPool，而不是关闭校验

SystemCertPool 返回系统根证书池的副本。拿到它后调用 AppendCertsFromPEM 追加内部 CA，最后将同一个池交给 RootCAs。这样不会因为“信任内部 CA”而丢掉操作系统原本的公网根证书。

package main

import (
    "crypto/tls"
    "crypto/x509"
    "errors"
    "fmt"
    "net/http"
    "os"
    "time"
)

func newInternalHTTPClient(caFile string) (*http.Client, error) {
    // 中文说明：优先保留操作系统根证书，避免客户端失去公网 HTTPS 能力。
    roots, err := x509.SystemCertPool()
    if err != nil || roots == nil {
        // 中文说明：少数环境没有可读取的系统池时，退回空池并只信任内部 CA。
        roots = x509.NewCertPool()
    }

    caPEM, err := os.ReadFile(caFile)
    if err != nil {
        return nil, fmt.Errorf("读取内部 CA: %w", err)
    }
    if ok := roots.AppendCertsFromPEM(caPEM); !ok {
        return nil, errors.New("内部 CA 不是可解析的 PEM 证书")
    }

    transport := &http.Transport{
        TLSClientConfig: &tls.Config{
            // 中文说明：RootCAs 扩大信任根，但不关闭证书链和主机名校验。
            RootCAs:    roots,
            MinVersion: tls.VersionTLS12,
        },
    }
    return &http.Client{
        // 中文说明：超时防止内部网络异常时请求长期占用连接。
        Transport: transport,
        Timeout:   10 * time.Second,
    }, nil
}

这里没有设置 ServerName，正常情况下由请求 URL 的主机名参与校验。若代码使用了自定义拨号器，仍应让 ServerName 表示证书要匹配的服务名，而不是把它改成 IP 后再关闭校验。

主机名校验仍然要保留

RootCAs 解决的是“谁签发的证书可以信任”，ServerName 解决的是“这张证书是不是签给当前服务”。两者是不同边界。内部 DNS 名称、证书 SAN 和客户端 URL 应该在证书签发流程中统一；不要把 InsecureSkipVerify 当成生产环境的兼容开关。

请求结束后做一次可定位的复查

客户端创建好后，调用方仍要正确关闭响应体。首次接入内部服务时，我会把错误保留为“请求地址 + 原始错误”，这样能区分网络超时、CA 不受信任和 SAN 不匹配；不会用空错误或统一的“请求失败”覆盖原因。

func fetchHealth(client *http.Client, endpoint string) error {
    // 中文说明：endpoint 的主机名必须与服务证书 SAN 中的名称一致。
    resp, err := client.Get(endpoint)
    if err != nil {
        return fmt.Errorf("访问 %s: %w", endpoint, err)
    }
    // 中文说明：无论状态码如何都关闭响应体，避免连接资源泄漏。
    defer resp.Body.Close()

    if resp.StatusCode/100 != 2 {
        return fmt.Errorf("访问 %s 返回 HTTP %s", endpoint, resp.Status)
    }
    return nil
}

上线前的四项边界检查

• 部署包中只放内部 CA 公钥证书，不把 CA 私钥或服务私钥打进客户端。
• 确认 PEM 文件读取路径在容器、systemd 和本地开发环境中都明确，避免依赖当前工作目录。
• 检查证书 SAN 是否包含客户端实际访问的 DNS 名；仅看 Common Name 不够。
• 只有在测试或自定义完整验证回调时才考虑 InsecureSkipVerify，生产默认应保持 false。

如果内部服务和公网服务共用一个客户端，使用系统池再追加内部 CA 是更容易维护的方案；如果客户端只应访问一个受控内部域，也可以从空池开始，但要把 CA 轮换、证书过期和部署回滚纳入发布清单。

常见问题

追加 CA 后仍然报主机名错误怎么办？先看请求 URL 的主机名，再对照证书 SAN。CA 只负责建立信任链，不会改变证书允许的主机名。

能不能直接把系统 CA 文件读进 NewCertPool？不建议把平台路径写死。优先使用 SystemCertPool，再追加应用自己的 CA；如果平台没有系统池，再明确记录空池策略和运维责任。

这套方案的核心只有一句话：把信任配置补完整，而不是把校验删除。这样证书轮换、主机名变更和异常审计都能留下可解释的边界。