Go crypto/tls 怎样用 VerifyConnection 补充证书判断

如果默认的 CA、主机名校验已经够用，就不需要为了“看一眼证书”而接管 TLS 验证。真正需要补充业务条件时，可以给 tls.Config.VerifyConnection 设置回调：它在正常证书校验之后执行，拿到完整的 tls.ConnectionState，返回非 nil 错误就会终止握手。

官方文档：https://pkg.go.dev/crypto/tls

推荐的默认路线是“让 crypto/tls 先完成标准校验，再用 VerifyConnection 检查额外条件”。例如只允许某个证书指纹、检查特定的颁发者，或记录协商出的 TLS 状态。只有在明确知道如何重建完整验证链时，才把 InsecureSkipVerify 与自定义验证放在一起。

先看清三个校验位置

这几个字段看起来都和证书有关，但职责不同。默认校验负责根证书、链和主机名等标准规则；VerifyPeerCertificate 处理原始证书字节，并且不会在恢复连接上调用；VerifyConnection 则接收连接级状态，在默认校验和 VerifyPeerCertificate 之后调用，而且包括恢复连接。

客户端怎样补充一条证书条件

客户端通常应保留 InsecureSkipVerify: false 的默认行为，只在回调里读取状态并追加条件。下面的例子把“证书链已经通过标准校验”作为前提，再限制叶子证书的组织名；生产代码中更稳妥的做法是使用明确的扩展字段、指纹或业务约定，而不是依赖容易变化的展示字段。

package main

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

func configForService(expectedIssuer string) *tls.Config {
    return &tls.Config{
        // 保留系统 CA 与 ServerName 的标准证书校验。
        ServerName: "api.example.com",
        MinVersion: tls.VersionTLS12,
        VerifyConnection: func(cs tls.ConnectionState) error {
            // 默认校验失败时握手不会走到这里；这里仍防御空切片，避免误用。
            if len(cs.PeerCertificates) == 0 {
                return errors.New("对端没有提供可读取的证书")
            }

            leaf := cs.PeerCertificates[0]
            // 业务条件只做补充，不把展示字段当成完整的链验证。
            if leaf.Issuer.CommonName != expectedIssuer {
                return fmt.Errorf("证书颁发者不符合要求: %s", leaf.Issuer.CommonName)
            }
            return nil
        },
    }
}

func main() {
    _ = configForService("Example Issuing CA")
}

回调返回 nil 表示这一层没有提出额外异议；返回错误则让握手失败。不要在回调中修改 PeerCertificates 或 VerifiedChains，它们是供读取的连接状态。

什么时候需要自己承担完整验证

如果设置 InsecureSkipVerify: true，客户端会跳过默认的服务器证书与主机名验证，但不会因此关闭 VerifyConnection。这不是“只关闭一个报错”的开关；此时回调必须自己完成根证书、链、主机名以及业务附加条件的验证。Go 官方示例使用 x509.VerifyOptions 重新验证叶子证书和中间证书，缺一项都可能留下中间人风险。

因此，除非你有自建 CA、特殊信任根或明确的证书验证实现，否则不要用 InsecureSkipVerify 配合一个只比较字符串的回调。只想追加判断时，让默认验证继续工作更安全。

恢复连接和服务端的两个边界

VerifyConnection 会在恢复连接上运行，这是它相对 VerifyPeerCertificate 的重要差异。使用连接池或会话票据时，如果额外策略必须覆盖每次建立或恢复的连接，应把它放在这里；若策略只针对首次证书材料处理，则需要重新评估是否会被恢复路径绕过。

服务端则要先看 ClientAuth。当服务端不要求客户端证书时，PeerCertificates 可能为空；不能无条件读取 PeerCertificates[0]。如果业务要求检查客户端证书，应选择会请求或要求证书的客户端认证模式，并在回调中继续做长度判断。

最后用这张表做选择

常见问题

VerifyConnection 能替代默认校验吗？可以通过关闭默认校验后自行调用 x509.Verify 实现，但这会把完整责任交给应用；只做额外条件时不建议这样做。

为什么 VerifyPeerCertificate 没有覆盖恢复连接？这是标准库明确的调用边界。需要对恢复连接也执行的连接级判断，应放到 VerifyConnection。