TLS unknown authority 如何定位根证书来源

Go 客户端遇到 x509: certificate signed by unknown authority 时，先别把它当成“服务端证书一定有问题”。这个错误只说明：当前收到的证书链，无法连接到客户端实际使用的某个受信任根证书。根证书可能来自操作系统，也可能被 SSL_CERT_FILE、SSL_CERT_DIR 或 tls.Config.RootCAs 改写。

先判断：错误发生在信任链，不是普通网络超时

TLS 客户端至少要同时面对三件事：服务端发来了哪些证书、客户端拿哪组根证书做信任锚点、证书中的主机名是否匹配请求目标。unknown authority 主要指向第二件事，但第一件事也会连带影响结果：如果服务端漏发了中间证书，客户端同样可能无法把叶子证书连到可信根。

可以把排查对象先压缩成下面这张表：

用 SystemCertPool 找到“默认根证书”从哪里来

x509.SystemCertPool() 返回的是当前主机系统根证书池的一份副本。它适合做第一轮定位：如果调用直接失败，优先检查运行环境；如果调用成功，再继续确认是否有自定义 RootCAs 或服务端链问题。

下面的诊断函数不打印证书内容，只记录根池调用结果和影响来源的环境变量，适合放在启动日志或临时排障命令中：

package main

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

func inspectRootSource() {
    // SystemCertPool 返回系统根池的副本；失败时先处理运行环境，而不是修改 TLS 校验开关。
    roots, err := x509.SystemCertPool()
    if err != nil {
        fmt.Printf("system cert pool unavailable: %v\n", err)
    } else {
        // 不把证书主体打印到日志，只确认进程拿到了一个可供 TLS 使用的池。
        fmt.Printf("system cert pool loaded: %t\n", roots != nil)
    }

    // 这两个变量可能把默认根证书文件或目录切换到容器内的另一份 CA 集合。
    fmt.Printf("SSL_CERT_FILE=%q\n", os.Getenv("SSL_CERT_FILE"))
    fmt.Printf("SSL_CERT_DIR=%q\n", os.Getenv("SSL_CERT_DIR"))
}

这里有一个容易忽略的点：返回的池是副本，后续对它调用 AppendCertsFromPEM 不会回写操作系统，也不会影响其他请求。这样做正好适合按客户端、按连接组装信任边界。

区分默认 RootCAs、自定义 RootCAs 和服务端链

tls.Config.RootCAs 是定位问题的分界线。它为客户端定义验证服务端证书时使用的根证书集合；保持为 nil 时走主机根池，显式赋值后则只看你传入的 CertPool。因此，下面这种写法会让“本机明明有证书”这件事失去意义：

// 这是一个常见的错误配置：新建空池后直接替换了默认根池。
roots := x509.NewCertPool()
client := &http.Client{
    Transport: &http.Transport{
        TLSClientConfig: &tls.Config{RootCAs: roots},
    },
}

如果业务既要信任系统 CA，又要信任内网 CA，应先复制系统池，再追加内网 CA。AppendCertsFromPEM 返回 false 时，说明输入里没有成功解析出证书，应该把它当成配置文件或挂载内容问题处理。

package main

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

func clientWithPrivateCA(caFile string) (*http.Client, error) {
    // 先沿用系统根池，避免自定义 CA 把公网证书信任关系覆盖掉。
    roots, err := x509.SystemCertPool()
    if err != nil || roots == nil {
        // 容器没有系统池时，退回空池，再明确追加业务 CA。
        roots = x509.NewCertPool()
    }

    pemBytes, err := os.ReadFile(caFile)
    if err != nil {
        return nil, fmt.Errorf("read private CA: %w", err)
    }
    // 只有 PEM 中至少解析出一张证书时，才把它交给 TLS。
    if ok := roots.AppendCertsFromPEM(pemBytes); !ok {
        return nil, fmt.Errorf("no certificate found in %s", caFile)
    }

    // RootCAs 明确绑定这份组合根池，保留正常的主机名和证书链校验。
    transport := &http.Transport{TLSClientConfig: &tls.Config{RootCAs: roots}}
    return &http.Client{Transport: transport}, nil
}

按四层排查 unknown authority

当根池调用成功但请求仍然失败，可以按“链、池、名、环境”四层缩小范围。不要一开始就设置 InsecureSkipVerify=true：这个开关会关闭默认的服务端证书链和主机名校验，成功只能证明网络能连通，不能证明信任关系正确。

1. 看对端链。 通过临时的 TLS 连接状态或服务端配置确认是否发送了叶子证书之外的中间证书。客户端不应该依赖“系统恰好缓存了中间证书”。
2. 看实际根池。 检查 RootCAs 是否被某个 HTTP 客户端工厂、数据库驱动或中间件覆盖；同时记录 SSL_CERT_FILE 和 SSL_CERT_DIR。
3. 看主机名。 ServerName 参与证书主机名校验，也用于 TLS 的 SNI。若错误是名称不匹配，应修正请求目标或证书 SAN，而不是继续追加 CA。
4. 看运行环境。 在容器里检查 CA bundle 是否随镜像安装，挂载路径是否存在，进程用户是否有读取权限，发布配置是否把证书文件挂到了预期位置。

修复时保留证书校验，避免只在本机有效

如果问题来自公有 CA 缺失，优先修复操作系统或镜像的 CA bundle；如果问题来自内网 CA，则把受信 CA 作为部署配置注入，再用上面的组合池加载。服务端链不完整时，应修复服务端证书链配置，让它发送正确的中间证书。

发布前可以把下面几项写入运行手册：

• 镜像基础层包含 CA 证书包，且不是只在开发机安装。
• 自定义 CA 文件由部署系统管理，权限允许业务进程读取但不扩大写权限。
• HTTP 客户端复用统一的 TLS 配置，避免某个驱动单独创建空的 CertPool。
• 不要把 InsecureSkipVerify 当成生产修复；如果确实需要自定义验证，应明确实现验证逻辑并评估会话恢复等边界。

相关问题

为什么同一地址在宿主机正常、容器里失败？

最常见原因是容器没有安装 CA bundle，或者 SSL_CERT_FILE、SSL_CERT_DIR 指向了不存在或不完整的路径。先比较两边的根池来源，再比较客户端是否配置了自定义 RootCAs。

追加 CA 后仍然报 unknown authority，下一步看什么？

先确认 PEM 真的被解析并加入了当前客户端使用的池，再看服务端是否漏发中间证书。若错误已经变成主机名不匹配，就不应继续追加 CA，而要检查证书 SAN 和 ServerName。

可以把 RootCAs 设成 NewCertPool 只放一张内网 CA 吗？

可以，但这会明确放弃系统根池。只有当客户端只应连接到该内网信任域时才这样做；需要同时访问公网服务时，应从系统池复制后再追加内网 CA。