证书链校验必须显式调用x509.Certificate.Verify()，不能依赖tls.Config中RootCAs或ClientCAs的自动行为；一旦设置VerifyPeerCertificate回调，Go即跳过默认校验，需手动解析证书、构造VerifyOptions并调用Verify，且opts.RootCAs、DNSName、CurrentTime、KeyUsages均须显式配置，否则关键校验被跳过。
证书链校验不是自动完成的，必须显式调用 x509.Certificate.Verify()
很多人以为只要把根证书塞进 tls.Config.RootCAs 或 ClientCAs，TLS 握手时就会“自动”完成完整链验证——其实不是。Go 的 crypto/tls 在默认流程中确实会尝试构建证书链并调用 Verify()，但这个行为**只在未设置 VerifyPeerCertificate 时才发生**；一旦你自定义了该回调，Go 就完全跳过默认校验，rawCerts 不会自动解析，verifiedChains 也不会被填充（或即使有也未经可信根验证）。
所以真正起作用的是你手动写的逻辑：先用 x509.ParseCertificate(rawCerts[0]) 解析叶子证书，再构造 x509.VerifyOptions，最后显式调用 cert.Verify(opts)。漏掉这一步，等于没校验。
-
opts.RootCAs必须是加载了 PEM 根证书的*x509.CertPool，不能是空池或 nil -
opts.DNSName必须设（哪怕只是占位符），否则不检查SubjectAlternativeNames，只比对已弃用的CommonName -
opts.CurrentTime不设就用time.Now()，测试过期证书时得手动填历史时间 -
opts.KeyUsages不设就跳过密钥用途校验（比如服务器证书被拿来签名也能过）
x509.Verify() 内部到底做了什么？
它不是简单地“用公钥解签名”，而是执行一套完整的 PKI 链式信任推导：
- 从叶子证书开始，逐级向上找签发者：用上一级证书的公钥验证当前证书的签名
- 检查每张证书的
NotBefore/NotAfter时间范围是否覆盖opts.CurrentTime - 确认每张证书的
BasicConstraints.ValidForCA是否允许其签发下级（尤其防中间 CA 被滥用于终端实体） - 验证
ExtKeyUsages是否匹配opts.KeyUsages（如x509.ExtKeyUsageServerAuth） - 若设置了
DNSName，则要求叶子证书的SubjectAlternativeNames中至少有一个匹配
注意：Verify() 返回的 verifiedChains 是成功构建出的路径集合（可能多条），但 Go 不会自动选“最优”链——它只返回所有可行路径，由你决定是否接受。
立即学习“go语言免费学习笔记（深入）”；
加密货币跨交易所套利监控器，实时监控BTC/ETH/SOL等主流币在各交易所价差，发现套利机会后通过飞书/Telegram预警，自动计算扣除手续费后的净利润。
为什么 verifiedChains 不能直接信任？
因为 verifiedChains 是 VerifyPeerCertificate 回调的第二个参数，它的内容取决于你是否在回调里调用了 roots.Verify()。如果没调，它可能是空、nil，或者只是 TLS 库内部草率拼出来的链（比如没校验时间、没检查用途）。
典型安全写法是：先调 roots.Verify() 得到基础可信链，再对 parsedCert 做业务层过滤（如 OU 匹配、序列号黑名单）。跳过 roots.Verify() 直接查 parsedCert.Subject.OU，等于把校验责任全扔给业务代码，风险极高。
- 不要假设
verifiedChains非空就代表证书合法——它可能来自一个未设RootCAs的空池 - 不要在回调里
panic或log.Fatal，错误必须通过return error传递，否则连接静默中断 - 若需拒绝某张证书，
return errors.New("OU mismatch")即可，TLS 层会据此终止握手
客户端和服务端的链校验差异在哪？
服务端校验客户端证书时，用的是 tls.Config.ClientCAs + ClientAuth: tls.RequireAndVerifyClientCert；客户端校验服务端证书时，靠的是 tls.Config.RootCAs（或默认系统根池）。两者机制一致，但触发时机和配置位置不同。
- 服务端不设
ClientAuth，哪怕传了ClientCAs，也会静默降级为单向——这是最常踩的坑 - 客户端若没设
RootCAs，默认用系统根池（Linux 读/etc/ssl/certs，macOS/Windows 行为不一致），正式环境建议自己 bundle - gRPC 和 HTTP 的
tls.Config不可复用：gRPC 用credentials.TransportCredentials，HTTP 用http.Transport.TLSClientConfig
链校验真正复杂的地方不在算法，而在配置粒度和默认行为的隐蔽性——比如 ClientAuth 默认是 tls.NoClientCert，VerifyOptions 默认不校验时间、域名、用途。这些“不做事”的默认值，恰恰是最容易被忽略的安全盲点。
