Go InsecureSkipVerify 开启后怎么保留自定义证书校验

InsecureSkipVerify=true 并不等于“只忽略自签名证书”，而是让 Go TLS 客户端跳过默认的证书链验证和主机名验证。如果业务确实需要接管这两步，应把完整校验写进 VerifyConnection；只检查证书指纹但不验证链与主机名，仍然可能接受错误服务器。

优先方案始终是保持 InsecureSkipVerify=false，通过 RootCAs 信任私有 CA，并正确设置 ServerName。只有需要替换默认验证流程时，才开启它并在回调中完整补回校验。

这个开关究竟改变了什么

客户端默认会验证服务器证书是否能链到受信根，以及证书中的 DNS 名称是否匹配目标主机。开启 InsecureSkipVerify 后，任意证书和任意主机名都可能被接受；如果没有自定义验证，连接容易遭受中间人攻击。

图1：默认验证被跳过后，在 VerifyConnection 中重建证书链与主机名校验。

如果只是连接使用企业私有 CA 的服务，不需要开启该开关。把私有根证书放入 RootCAs 即可保留标准验证：

func secureConfig(roots *x509.CertPool, serverName string) *tls.Config {
    return &tls.Config{
        // 使用私有 CA 池验证服务器证书链。
        RootCAs: roots,
        // 明确验证目标主机名，并用于 SNI。
        ServerName: serverName,
        // 保留标准证书链和主机名验证。
        InsecureSkipVerify: false,
    }
}

用 VerifyConnection 完整恢复自定义校验

当业务需要自定义根池、动态信任策略或在标准校验后追加约束时，可以在 VerifyConnection 中调用叶子证书的 Verify。关键点有三个：传入可信根、把服务端提供的中间证书加入池、设置正确的 DNSName。

func customTLSConfig(
    roots *x509.CertPool,
    serverName string,
) *tls.Config {
    return &tls.Config{
        // 关闭默认验证，但不能把它当成最终安全策略。
        InsecureSkipVerify: true,
        // ServerName 仍用于 SNI，也作为自定义验证目标。
        ServerName: serverName,
        VerifyConnection: func(cs tls.ConnectionState) error {
            if len(cs.PeerCertificates) == 0 {
                // 没有服务器证书时必须拒绝握手。
                return errors.New("tls: peer did not provide a certificate")
            }

            intermediates := x509.NewCertPool()
            for _, cert := range cs.PeerCertificates[1:] {
                // 服务端证书链中除叶子外的证书作为中间证书。
                intermediates.AddCert(cert)
            }

            opts := x509.VerifyOptions{
                // 只信任业务明确提供的根证书池。
                Roots: roots,
                // 恢复完整的中间证书链构建。
                Intermediates: intermediates,
                // 恢复主机名校验，不能留空。
                DNSName: serverName,
                // 客户端校验服务器证书用途。
                KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
            }

            // Verify 同时检查有效期、链、用途和 DNS 名称。
            _, err := cs.PeerCertificates[0].Verify(opts)
            return err
        },
    }
}

这里不要依赖 cs.VerifiedChains：开启 InsecureSkipVerify 时，默认验证没有运行，因此该字段通常为空。自定义回调必须基于 PeerCertificates 重建并验证证书链。

为什么更推荐 VerifyConnection

VerifyPeerCertificate 也能读取原始证书并返回错误，但官方文档明确指出：它不会在 TLS 会话恢复连接上调用。VerifyConnection 则会对所有连接执行，包括恢复连接，并且不受 InsecureSkipVerify 设置影响。

图2：两个证书回调的触发差异，以及链、主机名和公钥指纹三道检查。

追加 SPKI 公钥指纹约束

证书固定不能替代链和主机名验证；更稳妥的顺序是先运行 x509.Verify，再检查叶子证书公钥的 SPKI 哈希。固定公钥通常比固定整张证书更能容忍同一密钥下的证书续期，但仍需要可靠的轮换策略。

func verifySPKI(cert *x509.Certificate, allowed [32]byte) error {
    // RawSubjectPublicKeyInfo 是证书公钥的标准编码。
    got := sha256.Sum256(cert.RawSubjectPublicKeyInfo)

    // ConstantTimeCompare 避免普通字节比较造成时序差异。
    if subtle.ConstantTimeCompare(got[:], allowed[:]) != 1 {
        return errors.New("tls: unexpected server public key")
    }
    return nil
}

把这段检查放在 x509.Verify 成功之后。生产环境通常同时保留“当前公钥”和“下一轮公钥”两个指纹，证书轮换完成后再移除旧值，避免单一固定值导致服务不可用。

常见错误写法

只判断证书是否存在

证书存在不代表可信。攻击者同样可以提供结构完整的自签名证书。

只校验证书哈希，不校验主机名

如果同一张证书或同一密钥被多个服务使用，缺少主机名边界会扩大误信范围。仍应设置 DNSName。

把回调返回 nil 当成“继续默认验证”

开启 InsecureSkipVerify 后默认链和主机名验证已经关闭；回调返回 nil 的含义是接受当前连接，不会自动补做标准校验。

复用 http.DefaultTransport 后原地修改

共享 Transport 可能被多个请求并发使用。应克隆 Transport，并为每个目标构建不可变的 TLS 配置。

func newHTTPClient(cfg *tls.Config) *http.Client {
    // 克隆默认 Transport，避免修改全局共享对象。
    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.TLSClientConfig = cfg.Clone()

    return &http.Client{
        Transport: transport,
        // 设置请求总超时，避免网络异常长期占用资源。
        Timeout: 15 * time.Second,
    }
}

测试清单

1. 受信根签发且主机名匹配时，握手成功。
2. 证书链正确但主机名错误时，握手失败。
3. 主机名正确但根证书不受信时，握手失败。
4. 证书过期或用途不是 ServerAuth 时，握手失败。
5. 链与主机名正确但 SPKI 不在允许列表时，握手失败。
6. 启用会话缓存后重复连接，VerifyConnection 仍执行。
7. 轮换窗口内新旧两个合法指纹都能通过，窗口结束后旧指纹被拒绝。

相关问题

自签名证书一定要开启 InsecureSkipVerify 吗？

不需要。把自签名证书或其私有 CA 加入专用 CertPool，再配置 RootCAs 与 ServerName，可以继续使用标准验证流程。

可以只设置 ServerName，不调用 x509.Verify 吗？

不可以。开启该开关后，ServerName 不会自动触发默认主机名验证；必须在自定义验证中通过 DNSName 交给 x509.Verify，或显式调用等价的验证逻辑。

VerifyConnection 返回错误会怎样？

TLS 握手会立即中止，该错误会返回给拨号或 HTTP 请求调用方。错误中应包含可定位的阶段，但不要记录证书私钥、令牌或其他敏感材料。

最终原则很简单：能用 RootCAs 解决就不要跳过默认验证；必须接管时，用 VerifyConnection 恢复链和主机名验证，再追加最小必要的自定义约束。

参考：Go crypto/tls 官方文档、Go crypto/x509 官方文档。