Go tls.Config.VerifyConnection 与 VerifyPeerCertificate 怎么选

Go 的 tls.Config 同时提供 VerifyPeerCertificate 和 VerifyConnection，选择标准可以压缩成一句话：需要读取原始证书或接管证书链策略时用前者，需要检查每条连接的最终状态（包括恢复连接）时用后者。两者可以组合，但不能把 InsecureSkipVerify 当成“安全地关闭校验”。

官方资料：https://pkg.go.dev/crypto/tls。下面按回调收到的数据、调用边界和连接生命周期拆开判断。

默认主机名、根证书和证书链校验仍然适用时，优先保留默认验证，再用 VerifyConnection 追加连接级约束；只有确实要处理原始证书字节或自定义链验证时，才把策略放到 VerifyPeerCertificate。

先看两个回调到底检查什么

VerifyPeerCertificate 的参数是原始 ASN.1 证书切片 rawCerts 和默认验证得到的 verifiedChains。它适合做证书指纹、扩展字段、私有 CA 链或自定义证书解析。正常验证失败时，握手会先失败；客户端设置 InsecureSkipVerify 或服务端关闭默认客户端证书验证后，verifiedChains 可能为空，回调必须自己承担足够的验证责任。

VerifyConnection 收到的是完整的 tls.ConnectionState，可以读取 TLS 版本、协商协议、对端证书、验证链和 DidResume 等连接级信息。它在默认证书验证以及 VerifyPeerCertificate 之后执行，并且会覆盖恢复连接场景，所以更适合表达“每条连接都不能违反”的策略。

先保留默认证书验证，再叠加自定义规则

普通客户端应设置 ServerName，并通过 RootCAs 指定额外信任根；不设置时，客户端通常使用系统根证书。只想限制 TLS 版本、ALPN 或证书上的业务属性，不要为了进入回调就无条件打开 InsecureSkipVerify。

当确实需要自建验证流程时，必须在 VerifyPeerCertificate 中解析证书、构造 x509.VerifyOptions 并检查主机名、用途和信任根。仅检查证书主题名称、指纹或公钥是否存在，不能替代有效期、签名链和主机名验证。

package main

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

func newTLSConfig() *tls.Config {
	return &tls.Config{
		ServerName: "api.example.com", // 保留默认的主机名校验输入。
		VerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
			// 这里适合检查原始证书材料；没有默认链时不能误当成已验证。
			if len(rawCerts) == 0 {
				return errors.New("peer certificate is missing")
			}
			if len(verifiedChains) == 0 {
				return errors.New("certificate chain is not verified")
			}
			return nil
		},
		VerifyConnection: func(cs tls.ConnectionState) error {
			// 连接级规则放在这里，恢复连接也会经过这个回调。
			if cs.Version 

这个示例假定默认验证仍然开启，因此 verifiedChains 为空就拒绝连接。如果业务真的采用自定义链验证，应把完整的 x509.Verify 过程写出来，而不是只删除这条判断。

按场景选择：默认验证、恢复连接与自定义策略

可以用三个问题做决定。第一，是否需要原始证书字节、证书扩展或自定义链验证？需要时选择 VerifyPeerCertificate。第二，是否要求每条连接都检查，包括 TLS 会话恢复？需要时选择 VerifyConnection。第三，规则是否属于完整连接状态，例如 TLS 版本、ALPN、是否恢复、对端证书数量？这些都更适合后者。

一个常见误区是只写 VerifyPeerCertificate 做审计或指纹校验，却忽略恢复连接不会再次调用它。官方文档明确提示：该回调不会在 resumed connection 上执行；如果这个遗漏会带来策略绕过，就把最终判断放到 VerifyConnection，或禁用会话票据并评估性能代价。

组合两个回调时记住顺序和失败边界

两个回调同时存在时，先是默认验证，再是 VerifyPeerCertificate，最后是 VerifyConnection。任一回调返回非 nil，握手都会中止。不要在后一个回调里假设前一个回调一定执行过：恢复连接可能跳过 VerifyPeerCertificate，而服务端的客户端证书配置也可能让证书集合为空。

服务端尤其要检查 cs.PeerCertificates 的长度。配置为可选客户端证书时，对端可能没有证书；直接读取下标零会触发越界。客户端则通常能拿到服务端证书，但也应把错误返回写成可诊断的信息，不要在回调中修改 verifiedChains 或其内容。

一张表固化选择

常见误区与最后检查

• 把 InsecureSkipVerify: true 当成生产配置。它会关闭客户端默认服务端证书和主机名验证，只能与完整自定义验证组合使用。
• 用 VerifyPeerCertificate 记录每次连接审计，却没有考虑 session resumption。连接级审计或硬性策略应放到 VerifyConnection。
• 只比较证书主题或公钥就认为安全。至少明确链、有效期、主机名、用途和信任根分别由谁验证。
• 服务端默认假定一定有客户端证书。根据 ClientAuth 选择检查 PeerCertificates 是否为空。

最终判断是：证书原材料和自定义链属于 VerifyPeerCertificate，完整连接约束和恢复连接覆盖属于 VerifyConnection。如果两类需求同时存在，就保留默认验证并把两个回调各自限制在对应层次，后续再用恢复连接、缺失客户端证书和错误证书链作为回归用例。

相关问题

VerifyConnection 会替代默认证书验证吗？不会。默认验证仍按配置执行；回调用于追加检查，只有在你明确关闭默认验证时才需要在回调中重建完整验证逻辑。

为什么 VerifyPeerCertificate 有时没有执行？最常见原因是连接通过 TLS 会话恢复建立。需要覆盖这类连接时，使用 VerifyConnection。

两个回调都返回错误时看哪个？先执行到的错误会让握手失败，因此应让证书材料层返回清楚的证书错误，让连接状态层只负责自己的策略错误。