Go TLS InsecureSkipVerify 为什么只影响客户端校验

排查 Go 的 TLS 握手时，最容易误判的一点是：看到 InsecureSkipVerify，就以为服务端也会因此放弃校验客户端证书。实际上它只影响客户端这一侧——客户端是否验证服务端证书链和证书中的主机名。服务端要不要验证客户端证书，看的是 ClientAuth、ClientCAs 等配置。

先把两条 TLS 校验链拆开

我第一次遇到这个问题，是在一个同时支持普通 TLS 和双向 TLS 的服务里。客户端为了连接测试环境，把 InsecureSkipVerify 设成了 true；随后有人担心服务端会“顺便”接受任意客户端证书。这个推断把两个方向混在了一起。

一次 TLS 连接有两条可能独立的身份判断：客户端接收服务端证书，并判断证书链和主机名；服务端接收客户端证书，并按 ClientAuth 决定是否请求、要求或验证它。InsecureSkipVerify 只属于前一条链，所以它不会替换服务端的客户端认证策略。

用配置字段定位真正的校验开关

排障时先问“谁在验证谁”，比直接改布尔值有效。下面这张表可以把常见字段放回正确的一侧：

因此，客户端报“unknown authority”或主机名不匹配，先看 RootCAs 和 ServerName；服务端报客户端证书不受信任，先看 ClientAuth 是否达到预期，再看 ClientCAs 是否包含正确的根证书。把服务端的 InsecureSkipVerify 改成 true，通常不能解决后一类错误。

为客户端和服务端分别写出安全配置

如果只是测试自签名服务端证书，临时跳过客户端默认校验确实能让握手继续，但生产配置更适合把测试 CA 放进 RootCAs，或者使用自定义校验回调。服务端则明确写出客户端证书策略，不依赖一个与它无关的字段：

package main

import (
    "crypto/tls"
    "crypto/x509"
)

func serverConfig(clientCAs *x509.CertPool) *tls.Config {
    return &tls.Config{
        // 服务端是否验证客户端证书由 ClientAuth 决定。
        ClientAuth: tls.RequireAndVerifyClientCert,
        // ClientCAs 提供服务端信任的客户端证书根 CA。
        ClientCAs: clientCAs,
    }
}

func clientConfig(roots *x509.CertPool) *tls.Config {
    return &tls.Config{
        // RootCAs 用于验证服务端证书；不关闭默认验证。
        RootCAs: roots,
        // ServerName 用于主机名校验和 SNI，按证书 SAN 填写。
        ServerName: "api.example.test",
        InsecureSkipVerify: false,
    }
}

示例中的 x509.CertPool 省略了构造过程，重点是两个方向的字段不要混用。若确实需要自定义规则，Go 的 VerifyConnection 会在连接验证边界运行；此时要自己检查证书链、主机名和用途，不能只因为回调被调用就认为身份可信。

看到握手成功后还要检查什么

把 InsecureSkipVerify 设为 true 后握手成功，只能说明客户端不再阻止任意服务端证书和主机名。它不代表服务端证书可信，也不代表服务端已经验证了客户端身份。Go 官方文档明确提醒，这种配置可能遭遇中间人攻击，除非仅用于测试或配合自定义验证。

复查时按下面的顺序记录两端配置即可：

• 客户端：InsecureSkipVerify、RootCAs、ServerName，以及是否设置了 VerifyConnection。
• 服务端：ClientAuth、ClientCAs、客户端证书用途，以及是否设置了服务端校验回调。
• 双向 TLS：分别保存服务端证书链和客户端证书链的诊断结果，不用“握手成功”代替身份结论。

相关问题

服务端设置 InsecureSkipVerify 会关闭客户端证书校验吗？

不会。服务端的客户端证书策略由 ClientAuth 及相关 CA 配置控制，InsecureSkipVerify 不是服务端的替代开关。

客户端证书主机名不匹配也由 InsecureSkipVerify 控制吗？

它控制的是客户端验证服务端证书中的主机名；客户端证书由服务端验证，排查方向应转到 ClientAuth、ClientCAs 和证书用途。

VerifyPeerCertificate 和 VerifyConnection 怎么选？

VerifyPeerCertificate 更靠近原始证书链，VerifyConnection 能拿到连接状态并覆盖包括会话恢复在内的连接检查；自定义时仍要明确写出完整验证条件。