Go TLS 为什么报 unknown authority

Go TLS 报 x509: certificate signed by unknown authority，核心含义不是“网络不通”，而是 Go 在校验证书链时，没有找到一条能够连接到受信任根证书的路径。最常见的原因是私有 CA 没有加入客户端信任池、容器没有安装系统 CA、服务端漏发中间证书，或者代码把系统根池替换成了一个空的自定义池。

排查时先保留完整错误链，再按“谁在验证谁”定位：普通 HTTPS 是客户端验证服务端证书；mTLS 还会增加服务端验证客户端证书。修复应围绕正确的根 CA 和完整链路展开，不要把 InsecureSkipVerify 当成生产方案。

先看错误发生在哪一侧

unknown authority 表示验证器无法把待验证证书的签发者连接到信任根。普通 HTTPS 中，客户端通常在 TLS 握手阶段验证服务端证书；如果错误被 url.Error 包了一层，最内层仍可能是 x509.UnknownAuthorityError。它和“证书过期”“主机名不匹配”是不同故障。

如果启用了双向 TLS，服务端也会使用自己的 ClientCAs 验证客户端证书。此时服务端日志可能出现 unknown authority，而 Go 客户端只看到握手失败。第一步不是立即改代码，而是确认错误来自客户端日志、服务端日志，还是代理层日志。

package main

import (
    "crypto/x509"
    "errors"
    "fmt"
    "net/http"
)

func classifyTLS(err error) {
    var unknown x509.UnknownAuthorityError
    if errors.As(err, &unknown) {
        // unknown authority 只说明信任链没有连到认可的根，不等于域名一定错误。
        fmt.Println("证书链没有连接到当前信任根")
        return
    }

    // 保留原始错误，便于区分过期、主机名不匹配和握手失败。
    fmt.Printf("TLS 错误: %v\n", err)
}

func request() error {
    // 使用默认客户端时，Transport 会使用默认 TLS 配置和系统信任来源。
    _, err := http.Get("https://service.example.internal")
    return err
}

这里的示例只展示错误分类，不把内部地址当成真实可访问站点。生产日志可以记录错误类型和目标服务名，但不要把客户端私钥、完整证书内容或访问令牌写入日志。

为什么开发机成功、容器却失败

当 tls.Config.RootCAs 为 nil 时，证书验证通常使用系统根证书或平台验证器。x509.SystemCertPool 返回的是系统证书池副本；它不是一个会自动同步磁盘变化的全局句柄。最小化容器镜像如果没有 CA bundle，公共 HTTPS 也可能无法完成验证。

还要注意环境变量。官方文档说明，SSL_CERT_FILE 和 SSL_CERT_DIR 可以改变系统证书文件和目录的来源；在部分平台上，它们还会影响是否使用平台证书验证 API。排查时把运行环境、镜像中的 CA 包和这些变量一起记录，而不是只比较 Go 代码。

package main

import (
    "crypto/x509"
    "fmt"
)

func loadSystemRoots() (*x509.CertPool, error) {
    roots, err := x509.SystemCertPool()
    if err != nil {
        // 系统池不可用时不要静默创建空池，否则公共证书也会全部不受信。
        return nil, fmt.Errorf("读取系统根证书池失败: %w", err)
    }
    if roots == nil {
        // 某些运行环境可能没有可用的系统池，显式返回原因更容易排障。
        return nil, fmt.Errorf("系统根证书池为空")
    }
    return roots, nil
}

如果容器确实没有系统 CA，应该在镜像构建或运行环境管理层安装受信任的 CA bundle，再让应用读取它。不要把一份临时导出的公共根证书硬编码进业务仓库。

私有 CA 要追加到正确的信任池

内部域名常由企业 CA、测试 CA 或自签名根签发。客户端必须信任签发链中的根 CA。推荐先读取系统池，再把业务 CA 追加进去，这样公共站点和内部站点都能访问。AppendCertsFromPEM 返回 false 时，说明输入中没有成功解析出 PEM 证书，通常是路径、格式或传入内容错误。

package main

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

func clientWithPrivateCA(caFile string) (*http.Client, error) {
    roots, err := x509.SystemCertPool()
    if err != nil || roots == nil {
        // 不能用空池悄悄替代系统池，先把环境问题暴露出来。
        return nil, fmt.Errorf("加载系统根证书池失败: %w", err)
    }

    caPEM, err := os.ReadFile(caFile)
    if err != nil {
        return nil, fmt.Errorf("读取私有 CA 失败: %w", err)
    }
    if ok := roots.AppendCertsFromPEM(caPEM); !ok {
        // 解析失败时拒绝启动，避免请求阶段才出现 unknown authority。
        return nil, fmt.Errorf("私有 CA 不是可解析的 PEM 证书")
    }

    transport := &http.Transport{
        TLSClientConfig: &tls.Config{
            RootCAs: roots,
            MinVersion: tls.VersionTLS12, // 只设置明确的协议下限，其余校验仍由 TLS 完成。
        },
    }
    return &http.Client{Transport: transport}, nil
}

如果这个客户端只访问一个内部服务，也可以使用 x509.NewCertPool 创建专用池并只加入业务根 CA。关键是要明确取舍：追加系统池适合混合访问；专用池适合严格隔离的内部连接。无论哪种方式，都要确认加入的是 CA 证书，而不是只有服务端叶子证书的导出文件。

服务端漏发中间证书时，根 CA 可能已经正确

证书链通常由叶子证书、中间 CA 和根 CA 组成。客户端一般持有信任根，服务端在握手时发送叶子证书及必要的中间证书。若服务端只发送叶子证书，客户端即使信任根 CA，也可能无法构造完整链而报 unknown authority。

这类问题不应通过给客户端塞入所有中间证书来掩盖。优先修复服务端的证书链配置，让不同语言和不同客户端都能得到一致的握手材料。客户端侧可以用证书检查工具或服务端配置清单确认发送了哪些证书；不要把线上证书内容复制进文章或日志。

用 VerifyOptions 做最小化定位

如果需要脱离 HTTP 客户端单独确认证书链，可以解析叶子证书，把中间证书放入 Intermediates，把信任根放入 Roots，再用 Certificate.Verify。DNSName 会额外检查主机名；验证链成功并不代表所有网络层配置都正确，但能把“链不受信”和“域名不匹配”分开。

package main

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

func explainVerify(err error) string {
    var unknown x509.UnknownAuthorityError
    if errors.As(err, &unknown) {
        // 这个分支对应信任锚点或中间证书链路缺失。
        return "没有找到可用的受信任签发者"
    }

    var invalid x509.CertificateInvalidError
    if errors.As(err, &invalid) {
        // InvalidReason 可以继续区分过期、用途限制等证书状态。
        return fmt.Sprintf("证书无效: %v", invalid.Reason)
    }
    return fmt.Sprintf("其他验证错误: %v", err)
}

排障顺序可以固定成一张清单：

1. 确认错误来自客户端还是 mTLS 服务端，并保留完整错误链。
2. 确认运行环境能提供系统根证书，检查容器 CA bundle 以及 SSL_CERT_FILE、SSL_CERT_DIR。
3. 检查代码是否用空的 x509.NewCertPool() 覆盖了系统池，或是否忘记检查 PEM 追加结果。
4. 确认私有 CA 是正确的信任根，服务端发送了必要的中间证书。
5. 最后再排查域名、有效期、用途和代理终止 TLS 等其他问题。

不要用 InsecureSkipVerify 结束排查

InsecureSkipVerify: true 会关闭客户端对服务端证书链和主机名的常规验证。它可以出现在受控的诊断实验中，用来证明“网络和协议握手本身能否继续”，但不应作为生产修复，也不应与“只关闭域名检查”的想法混为一谈。

正确的修复是补齐信任关系：公共服务使用正确的系统根池，内部服务向明确的池加入私有 CA，服务端发送完整中间链，容器安装并管理 CA bundle。这样错误消失的原因是证书链可验证，而不是客户端放弃了验证。

结语：先找信任根，再改 TLS 配置

Go TLS 的 unknown authority 本质上是信任链问题。先分清验证方向，再检查系统池是否存在、RootCAs 是否被替换、私有 CA 是否成功加入，以及服务端是否发送中间证书。把这些边界逐项排除后，通常不需要改动 TLS 协议版本，更不需要关闭证书校验。

相关问题

• 为什么换成 x509.NewCertPool 后所有 HTTPS 都失败？ 因为新建的是空池；如果还要访问公共站点，应先加载系统池或明确加入所需公共根 CA。
• 客户端已经加入根 CA，为什么仍然 unknown authority？ 继续检查服务端是否漏发中间 CA，以及加入的文件是否真的是签发链上的 CA。
• unknown authority 和 hostname mismatch 有什么区别？ 前者是信任链无法连接到根，后者是证书身份与请求主机名不匹配，修复位置不同。
• 容器里如何避免证书问题反复出现？ 把 CA bundle 和私有 CA 的安装纳入镜像或部署配置，并在应用启动时检查加载结果。