Go TLS 客户端如何避免把 InsecureSkipVerify 当成修复方案

Go TLS 客户端遇到证书错误时，最容易出现的“修复”是把 InsecureSkipVerify 改成 true。连接确实可能因此成功，但代价是客户端不再验证服务端证书链和主机名。更稳妥的做法，是先判断错误属于 ServerName、信任根还是证书 SAN，再修正对应配置；只有明确接管验证逻辑时，才考虑自定义校验。

生产连接保持 InsecureSkipVerify: false，先补对 ServerName，再用 RootCAs 或系统证书池解决信任链问题。不要用一个布尔开关掩盖三个不同故障。

先把 TLS 的四个输入分开

TCP 地址、TLS 身份和信任链不是同一个值。服务部署在内网时，常见情况是实际连接到 10.0.0.8:443，但证书的 DNS SAN 写的是 api.example.com。这时应该让拨号器连接 IP，让 ServerName 保持证书中的域名。

证书错误不同，修复入口也不同

如果报错是 either ServerName or InsecureSkipVerify must be specified，说明配置连校验对象都没有给出；补上证书 SAN 对应的 ServerName。如果报错变成 x509: certificate signed by unknown authority，说明已经进入证书链校验，应检查系统根证书或自定义 RootCAs。如果是 certificate is valid for ... not ...，则应检查 DNS SAN 或 IP SAN，不要继续改 CA。

配置里的 ServerName 不是日志备注。它会参与主机名验证，在域名场景下还会作为 SNI 帮助服务端选择证书。证书只有 api.example.com 时，把它换成内网 IP 仍然会失败；只有证书的 IP SAN 包含该地址时，IP 才是合法校验名。

内部 CA 用 RootCAs 补信任，不要关闭验证

对企业内部 CA 或测试环境私有根证书，可以把 PEM 加入证书池，再交给 tls.Config.RootCAs。下面的示例故意把 TCP 目标和证书身份分开；代码中的地址、证书内容和域名都是示意值，不代表已经执行过的连接。

package main

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

func dialPrivateService(ctx context.Context, caPEM []byte) (net.Conn, error) {
    roots, err := x509.SystemCertPool()
    if err != nil {
        return nil, fmt.Errorf("读取系统根证书失败: %w", err) // 不要用跳过校验掩盖证书池异常
    }
    if roots == nil {
        roots = x509.NewCertPool() // 某些精简容器没有系统证书包，显式创建证书池
    }
    if ok := roots.AppendCertsFromPEM(caPEM); !ok {
        return nil, fmt.Errorf("内部 CA PEM 无法加入证书池") // 证书内容无效时直接返回
    }

    cfg := &tls.Config{
        ServerName: "api.internal.example", // 用证书 SAN 中的服务名做身份校验
        RootCAs:    roots,                   // 只扩大受信任根，不关闭链和主机名验证
        MinVersion: tls.VersionTLS12,        // 只表达最低协议版本要求
    }
    dialer := &net.Dialer{Timeout: 3 * time.Second} // TCP 目标和证书身份保持分离
    conn, err := (&tls.Dialer{NetDialer: dialer, Config: cfg}).DialContext(ctx, "tcp", "10.0.0.8:443")
    if err != nil {
        return nil, fmt.Errorf("TLS 握手失败: %w", err) // 保留原错误，便于判断是哪类校验失败
    }
    return conn, nil // 调用方负责关闭已经建立的连接
}

这里的关键不是“换成了另一个证书池”，而是仍然保留了证书链与主机名检查。若只需要系统根证书，RootCAs 可以保持 nil；只有在信任模型确实包含私有 CA 时才追加证书。

只有接管验证逻辑时才使用 VerifyConnection

某些场景需要把证书验证结果与应用策略合并，例如限定某个公钥指纹或补充租户身份。此时可以使用 VerifyConnection，但回调必须真正检查 ConnectionState，并在不满足条件时返回错误。仅仅判断“收到了证书”并不能证明对端可信。

Go 文档还特别说明，VerifyConnection 会覆盖包括会话恢复在内的连接；如果把 InsecureSkipVerify 设为 true 来替换默认验证，就必须在回调中补齐证书链、主机名和应用自己的规则。复杂度一旦超过必要范围，优先回到标准验证路径。

排查时记住这张小清单

1. 先看错误文本：配置前置、证书链和主机名错误不能混为一谈。
2. 确认自定义 DialContext 没有重新创建一份空的 tls.Config。
3. 检查叶子证书的 DNS SAN、IP SAN 和实际 ServerName 是否一致。
4. 内部 CA 放入 x509.CertPool；不要为了让握手通过而永久打开 InsecureSkipVerify。

相关问题

ServerName 可以直接写拨号 IP 吗？

只有证书的 IP SAN 包含该地址时才可以。证书写的是 DNS SAN，就应使用对应域名，即使 TCP 实际连接的是内网 IP。

RootCAs 为空是不是不校验证书？

不是。RootCAs 为 nil 时，Go 会使用主机系统根证书集合；空值不等于关闭验证。

测试环境能不能临时使用 InsecureSkipVerify？

可以把它限制在明确的测试代码和短生命周期配置中，但不要复制到生产客户端。生产问题应记录真实证书错误并修复对应的身份或信任配置。