Go语言证书签名校验核心是正确提取证书公钥并调用对应签名验证方法：RSA需类型断言后用rsa.Verify，ECDSA需解析r/s并用ecdsa.Verify；x509.VerifyOptions必须显式设置RootCAs、DNSName、CurrentTime和KeyUsages等字段，否则默认跳过时间、域名、用途等关键校验。
Go 语言做证书签名校验，核心不是“学加密”，而是搞清 x509.Certificate 和 crypto.Signer 怎么配合验证签名——多数人卡在证书链构建和公钥提取这一步，不是算法没看懂，是没意识到 Go 的 VerifyOptions 默认不校验时间、不加载中间 CA。
怎么用 crypto/x509 验证一个签名是否由证书私钥生成
这不是验“证书本身是否合法”，而是验“某段数据的签名是否能被证书里的公钥解开”。关键路径是：读证书 → 提取公钥 → 调用 pubKey.Verify()（注意：不是所有公钥类型都支持直接 Verify，RSA 可以，ECDSA 得用 ecdsa.Verify 手动解包）。
-
cert, err := x509.ParseCertificate(pemBytes)后，cert.PublicKey是interface{}，需类型断言：if rsaPub, ok := cert.PublicKey.(*rsa.PublicKey) - RSA 签名验证必须指定哈希算法（如
crypto.SHA256），且原始签名必须是该哈希值的 PKCS#1 v1.5 或 PSS 填充结果 - ECDSA 签名不能直接传给
pubKey.Verify()，得先用ecdsa.Verify(cert.PublicKey.(*ecdsa.PublicKey), hash[:], r, s)，其中r、s是 DER 编码签名里解析出的两个大数
x509.VerifyOptions 里哪些字段不设就等于没验
调用 cert.Verify(opts) 时，默认只检查证书签名和基本结构，时间、域名、CA 属性全靠手动开开关。漏配就可能让过期或域名错的证书“验成功”。
-
RootCAs必须显式提供，Go 不自动读系统根证书（system.RootCAs()可获取，但 Windows/macOS 行为不一致，建议自己 bundle） -
DNSName必须填，否则不校验SubjectAlternativeNames，仅比对CommonName（已弃用） -
CurrentTime不设则用time.Now()，但测试时若想验证历史证书，得手动设 -
KeyUsages和ExtKeyUsages不设，就跳过密钥用途检查（比如服务器证书拿去签名，也能过）
为什么 tls.Conn 的 VerifyPeerCertificate 和手写验证行为不一致
因为 tls.Config.VerifyPeerCertificate 是绕过默认验证的钩子，它不自动触发 cert.Verify()，你得自己调——而且 TLS 握手时拿到的是原始证书链字节，不是已解析的 *x509.Certificate。
立即学习“go语言免费学习笔记（深入）”；
- 传入的
rawCerts是 [][]byte，第一个是 leaf，后面是 intermediates；必须用x509.ParseCertificate()逐个解析，再按顺序构造opts.Intermediates - 如果中间证书缺失，
cert.Verify()会失败，但 TLS 默认配置下可能仍建立连接（取决于ClientAuth模式） - 别在钩子里 panic 或 log.Fatal，会导致连接直接断开；错误应通过返回 error 传递，TLS 库会据此拒绝连接
真正麻烦的从来不是 RSA 还是 ECDSA，而是证书链是否完整、时间是否在有效期内、用途是否匹配——这些信息都在 x509.Certificate 字段里，但 Go 不替你做业务判断。写完验证逻辑后，务必用真实过期证书、错误域名证书、缺少中间 CA 的证书各跑一遍，不然上线就翻车。
