Go TLS 怎样让客户端信任自定义证书

Go TLS 客户端要信任自定义证书，关键不是关闭证书校验，而是准备一个 *x509.CertPool：先读取系统根证书池，再追加自定义 CA 的 PEM 内容，最后通过 tls.Config.RootCAs 交给 HTTP Transport。这样既保留系统已经信任的公网 CA，也能连接由内部 CA 签发的服务。

官方文档入口：https://pkg.go.dev/crypto/tls、https://pkg.go.dev/crypto/x509。下面的示例只展示配置关系，不把示例请求当作本文已经执行过的测试结果。

先把自定义 CA 加入证书池

tls.Config.RootCAs 表示客户端验证服务端证书时使用的根证书机构集合。它为空时，TLS 使用主机的根 CA 集合；一旦显式放入一个只包含自定义 CA 的新池，系统默认信任的公网 CA 就不会自动从另一个池“合并”进来。因此更稳妥的默认写法是从 x509.SystemCertPool() 返回的副本开始追加。

package main

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

func loadRootPool(path string) (*x509.CertPool, error) {
	// 证书文件只读入内存，不修改操作系统自己的根证书库。
	pemBytes, err := os.ReadFile(path)
	if err != nil {
		return nil, err
	}

	// 先保留系统 CA；某些环境拿不到系统池时再退回空池。
	pool, err := x509.SystemCertPool()
	if err != nil || pool == nil {
		pool = x509.NewCertPool()
	}

	// 返回 false 说明输入里没有成功解析出 PEM 证书。
	if ok := pool.AppendCertsFromPEM(pemBytes); !ok {
		return nil, errors.New("custom CA PEM contains no readable certificate")
	}
	return pool, nil
}

这里的 SystemCertPool 返回的是可在进程内修改的副本，追加操作不会把证书写回操作系统。AppendCertsFromPEM 可以从一段 PEM 文本中解析并追加证书；因此要把 CA 证书文件作为字节读入，并检查它的布尔返回值。

把证书池接入 HTTP 客户端

证书池准备好后，把它放到 tls.Config.RootCAs，再把这个 TLS 配置交给 http.Transport。调用方继续使用普通的 http.Client，证书校验仍由标准 TLS 握手完成。

package main

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

func newClient(rootPool *x509.CertPool) *http.Client {
	// RootCAs 只改变服务端证书的信任来源，不跳过主机名校验。
	transport := &http.Transport{
		TLSClientConfig: &tls.Config{
			RootCAs:    rootPool,
			MinVersion: tls.VersionTLS12,
		},
	}
	return &http.Client{Transport: transport, Timeout: 15 * time.Second}
}

func request(client *http.Client, url string) error {
	// 响应体由调用方负责关闭，避免连接和资源长期占用。
	resp, err := client.Get(url)
	if err != nil {
		return err
	}
	defer resp.Body.Close()
	if resp.StatusCode = 300 {
		return fmt.Errorf("unexpected HTTP status: %s", resp.Status)
	}
	return nil
}

上面的片段依赖前一个小节的 loadRootPool，完整程序还需要导入 crypto/x509；这里把客户端构造和请求处理拆开，重点是展示 http.Client → http.Transport → tls.Config → RootCAs 的接口边界。长生命周期客户端可以在应用退出或配置替换时调用 CloseIdleConnections，而每次请求仍应关闭 resp.Body。

参数语义和常见误区

如果服务端证书由自定义根 CA 签发，但证书的 SAN 没有当前请求域名或 IP，追加 CA 仍会得到主机名不匹配错误。反过来，主机名正确也不能弥补客户端不信任签发链根证书的问题。

按错误层次排查连接失败

1. 文件层：先看 os.ReadFile 是否读到了目标文件，路径、权限和部署镜像内的文件位置要一致。
2. PEM 层：检查 AppendCertsFromPEM 是否返回 true；空文件、DER 直接输入或混入不完整文本都会在这里暴露。
3. 链层：确认服务端发出的链能从叶子证书连接到客户端信任的根。只放服务器叶子证书，通常不能替代正确的 CA 信任配置。
4. 名称层：检查请求 URL 的域名或 IP 是否出现在证书 SAN 中。不要为了让请求“先通起来”而长期设置 InsecureSkipVerify: true。
5. 客户端层：确认真正发请求的 Client 使用了自定义 Transport；只创建 TLS 配置但仍调用另一个默认 Client，不会改变默认连接的信任池。

代理、连接复用和服务端配置也可能影响最终错误，但它们应在证书文件、证书链、主机名和实际 Client 这几个边界确认后再排查。本文没有运行这些示例，读者应在自己的测试环境中用非敏感证书和明确的预期错误逐项核对。

两个容易混淆的问题

只想信任内部 CA，能不能直接用 NewCertPool？ 可以，但这代表你明确选择一个只包含指定 CA 的信任集合；公网 CA 不会自动保留。若业务既访问内网服务又访问公网服务，优先从系统池开始追加。

自定义 CA 加入后仍提示证书错误怎么办？ 先区分是 PEM 没解析、证书链缺中间 CA，还是 SAN 与请求主机不匹配。RootCAs 只解决信任根集合，不会修改服务端证书，也不会取消主机名校验。

归纳起来，Go TLS 的配置决策可以保持很小：SystemCertPool 保留环境默认信任，AppendCertsFromPEM 增加自定义 CA，RootCAs 把结果交给客户端。把这三个职责分开，排错时就不容易把“证书不受信任”和“证书不匹配当前主机名”混为一谈。