Go crypto/tls 客户端跳过证书校验有什么风险

Go 的 tls.Config.InsecureSkipVerify 一旦设为 true，客户端就不再默认验证服务端证书链和证书中的主机名。加密通道可能仍然建立，但“对端是谁”失去了默认证明，遭遇中间人攻击时，客户端也可能把伪造证书当成合法服务。它适合局部测试，不适合拿来修复生产证书问题。

官方地址：https://pkg.go.dev/crypto/tls

InsecureSkipVerify 到底跳过了哪些检查

默认情况下，客户端会根据服务端发来的证书链寻找可信根，并用目标主机名检查证书的 SAN。ServerName 既参与主机名验证，也常用于 TLS 握手中的虚拟主机选择。设置 InsecureSkipVerify 后，这两层默认检查都被关闭：证书可以不是受信任 CA 签发的，主机名也可以对不上。

// 仅用于本地临时联调，不能把这个配置带进生产客户端
cfg := &tls.Config{
	InsecureSkipVerify: true, // 关闭证书链与主机名的默认验证
	ServerName:         "api.dev.internal", // 不会再单独证明证书属于该主机
}

client := &http.Client{Transport: &http.Transport{TLSClientConfig: cfg}}
_ = client

这里的风险不是“TLS 完全没有加密”，而是认证边界被撤掉了。攻击者若能影响网络路径、代理或解析结果，可能终止一段 TLS，再用自己的证书与客户端建立另一段连接；客户端不会因为证书链或主机名异常而拒绝。

开发环境怎样保留可控的证书校验

如果目标服务使用自签名证书或企业内部 CA，先把 CA 证书加入专用的 x509.CertPool，再把它交给 RootCAs。这样解决的是“客户端不认识这棵信任树”，而不是把所有证书都视为可信。

// 读取开发环境的私有 CA，并继续验证 api.dev.internal
roots := x509.NewCertPool()
if ok := roots.AppendCertsFromPEM(caPEM); !ok {
	return fmt.Errorf("加载开发 CA 失败") // CA 内容无效时立即失败
}

cfg := &tls.Config{
	RootCAs:    roots,              // 只信任显式加入的内部根证书
	ServerName: "api.dev.internal", // 保留证书 SAN 的主机名检查
}
	client := &http.Client{Transport: &http.Transport{TLSClientConfig: cfg}}
_ = client

不要把服务端叶子证书硬编码成长期信任根，也不要用 IP 地址替代证书中的名称来规避错误。更稳妥的做法是为开发、测试、生产分别管理 CA 来源，并让证书轮换只改变信任材料，不改变校验逻辑。

生产环境怎样替代全局跳过校验

多数生产客户端只需删除 InsecureSkipVerify，补齐系统根证书、私有 CA 或正确的 ServerName。如果确实需要额外约束，例如限定某个内部 CA 或记录证书属性，应把规则写进 VerifyConnection，让不满足条件的连接返回错误。

// 自定义校验必须返回错误，不能只记录日志后放行
cfg := &tls.Config{
	InsecureSkipVerify: true, // 仅关闭默认校验，交给下面的自定义规则接管
	VerifyConnection: func(state tls.ConnectionState) error {
		if len(state.PeerCertificates) == 0 {
			return fmt.Errorf("服务端未提供证书") // 没有证书不能继续
		}
		leaf := state.PeerCertificates[0]
		if leaf.Subject.CommonName != "api.dev.internal" {
			return fmt.Errorf("证书主体不符合预期") // 示例规则，生产应按 SAN/CA 设计
		}
		return nil
	},
}
_ = cfg

示例只说明回调的控制边界，不建议用过时的 CommonName 作为唯一身份依据。更完整的自定义校验应使用 x509.Verify、明确的 DNSName 和 Roots，并覆盖中间证书、有效期与用途。若规则只是“有证书就返回 nil”，风险仍等同于跳过校验。

证书错误的排查清单与边界

代码审查时可以把 InsecureSkipVerify: true 视为高风险信号，要求它靠近测试构建或显式开发配置，并禁止由环境变量在生产随意打开。排查完证书后，还应确认代理、DNS、时间同步和证书轮换流程没有制造同样的症状。

相关问题

设置 InsecureSkipVerify 后还需要 ServerName 吗？

它仍可能影响握手中的虚拟主机选择，但不会替你完成默认的主机名认证；不能把它当作证书身份校验。

自签名证书一定要跳过校验吗？

不需要。把签发它的 CA 放入专用 x509.CertPool，并保留正确的 ServerName，通常更安全。

VerifyPeerCertificate 和 VerifyConnection 怎么选？

先优先考虑能拿到完整连接状态的 VerifyConnection；无论使用哪个回调，都必须明确验证链、名称和用途，并在失败时返回错误。

判断这项配置是否合理，可以只问一句：客户端是否仍能证明“这张证书由我信任的 CA 签发，并且属于我要访问的主机”？如果答案是否定的，修复信任材料和地址比保留跳过开关更可靠。