不能。InsecureSkipVerify设为true后,Go会跳过全部证书验证,VerifyPeerCertificate和VerifyConnection均不会被调用;自定义校验必须设为false,并配合VerifyPeerCertificate(兼容旧版)或VerifyConnection(Go 1.19+推荐)实现。

tls.Config.InsecureSkipVerify 设为 true 之后还能自定义校验吗?
不能。一旦设为 true,Go 就会跳过全部证书验证(包括签名、域名、有效期),VerifyPeerCertificate 和 VerifyConnection 都不会被调用。想自定义,必须设为 false,并提供非空的 VerifyPeerCertificate 或启用 VerifyConnection(Go 1.19+)。
用 VerifyPeerCertificate 实现域名和证书链双重校验
这是最常用的方式,适用于 Go 1.18 及更早版本,也兼容新版本。它接收原始 DER 证书字节切片和已构建的证书链(可能不完整),你需要手动解析、校验签名和域名匹配。
-
VerifyPeerCertificate的参数rawCerts是对端发来的原始证书字节,按链顺序排列(第一个是 leaf) - 需用
x509.ParseCertificate解析每个rawCerts[i],再调用cert.Verify构建并验证整条链(注意传入roots和intermediates) - 域名检查不能只看
cert.DNSNames,还得处理cert.Subject.CommonName(仅当无 DNSNames 且启用了 CN 匹配时才考虑,但现代服务应避免依赖 CN) - 务必检查
err != nil后立即返回错误,否则 TLS 握手会继续并可能失败在更晚阶段
cfg := &tls.Config{
VerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
if len(rawCerts) == 0 {
return errors.New("no certificate received")
}
cert, err := x509.ParseCertificate(rawCerts[0])
if err != nil {
return err
}
// 自定义域名检查(例如只允许 *.example.com)
if !strings.HasSuffix(cert.DNSNames[0], ".example.com") {
return errors.New("invalid domain in certificate")
}
// 注意:此处未做链验证;如需链验证,应基于 rawCerts + roots 构造 verifiedChains 并检查
return nil
},
}
Go 1.19+ 推荐用 VerifyConnection 替代 VerifyPeerCertificate
VerifyConnection 在握手完成、证书链已由 Go 内部验证通过后才调用,参数是 *tls.ConnectionState,里面包含已验证的 VerifiedChains 和 PeerCertificates,更安全、更少出错。
-
VerifiedChains是 Go 已确认有效的证书路径列表,可直接取chains[0][0]拿 leaf 证书 - 无需重复做签名/有效期/基础约束校验,专注业务逻辑(如 OCSP 状态、自定义扩展字段、白名单 Subject)
- 如果仍需拒绝连接,直接返回 error 即可;返回 nil 表示接受
- 注意:若你同时设置了
VerifyPeerCertificate和VerifyConnection,前者会先执行,且它的错误会直接中断握手 —— 所以建议二者只选其一
cfg := &tls.Config{
VerifyConnection: func(cs tls.ConnectionState) error {
if len(cs.VerifiedChains) == 0 {
return errors.New("no verified certificate chain")
}
leaf := cs.VerifiedChains[0][0]
// 检查证书是否在你的可信 CA 列表中(比如比对 SubjectKeyId)
expectedKeyID := []byte{0x12, 0x34, ...}
if !bytes.Equal(leaf.SubjectKeyId, expectedKeyID) {
return errors.New("untrusted issuer")
}
return nil
},
}
常见坑:自定义校验里忘了设置 RootCAs 或 Intermediates
即使你写了 VerifyPeerCertificate,Go 默认仍会尝试用系统根证书做链验证;如果你没显式设置 RootCAs 或 ClientCAs,它可能用错信任锚,导致 verifiedChains 为空或不可靠。而 VerifyConnection 虽然内部已验证,但它的 VerifiedChains 依赖你配置的 RootCAs —— 如果没设,Go 会 fallback 到系统默认,行为不稳定。
- 始终显式初始化
RootCAs:用x509.NewCertPool()+AppendCertsFromPEM - 若服务端要求双向认证,还需设置
ClientCAs和ClientAuth: tls.RequireAndVerifyClientCert - 测试时别只用 localhost 或自签名证书 —— 它们常绕过常规校验路径,掩盖逻辑缺陷
实际中最容易被忽略的是:自定义校验函数里没做空值判断(比如 rawCerts 为空或 VerifiedChains 为 nil),或者把域名检查写成字符串前缀匹配却没处理通配符规则(*.a.b 不等价于 endswith(".a.b"))。这些在真实中间设备或代理环境下会立刻暴露。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!











