Go tls.Config Renegotiation 怎样判断旧客户端是否被拒绝

如果一个旧客户端在 Go 服务端前完成第一次 TLS 握手，却在后续请求中收到握手失败，先不要把问题归结为根证书。tls.Config.Renegotiation 控制的是 TLS 1.2 及更早版本是否接受后续重协商请求；默认值 tls.RenegotiateNever 通常就是正确选择。TLS 1.3 不定义重协商，因此打开这个配置也不会让 TLS 1.3 获得同样的行为。

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

排查时要把“第一次握手失败”和“握手已经完成后，旧客户端请求重协商被拒绝”分开记录。只有确认对端确实依赖 TLS 1.2 重协商时，才考虑服务端的 RenegotiateOnceAsClient 或 RenegotiateFreelyAsClient 兼容策略。

Renegotiation 到底控制什么

Go 的 RenegotiationSupport 有三个公开取值：

这里有两个容易误解的点。第一，Go 不支持主动发起重协商，配置项描述的是客户端允许接受远端请求的程度。第二，服务端不能靠这个字段让自己主动要求客户端重新握手；服务端侧的默认拒绝仍然是安全边界的一部分。

先把第一次握手和后续重协商分开诊断

我排查这类兼容问题时，会先把错误发生点固定下来：第一次 Handshake 就失败，通常应继续看证书、协议版本、密码套件或 SNI；第一次握手成功，随后才出现握手相关错误，才值得检查 Renegotiation。下面的示例只展示诊断结构，不需要为了理解文章在本机连接真实服务。

package main

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

func inspectTLS(conn net.Conn) error {
    tlsConn, ok := conn.(*tls.Conn)
    if !ok {
        return fmt.Errorf("连接不是 *tls.Conn") // 先确认调用方没有把普通 TCP 连接当成 TLS 连接
    }

    if err := tlsConn.Handshake(); err != nil {
        return fmt.Errorf("首次 TLS 握手失败: %w", err) // 首次失败先排查证书、SNI 和版本，不归因于重协商
    }

    state := tlsConn.ConnectionState()
    fmt.Printf("version=%s renegotiation=%t peerCertificates=%d\\n",
        tls.VersionName(state.Version), state.HandshakeComplete, len(state.PeerCertificates)) // 只记录已完成握手的静态状态
    return nil
}

ConnectionState 只有在握手完成后才有诊断意义。它能告诉你当前协商的 TLS 版本和握手是否完成，但不会把“未来是否会收到重协商请求”提前写进状态。若错误发生在后续读写阶段，应把原始错误、连接角色和已协商版本一起记录，再判断是否是旧协议行为。

兼容旧客户端时怎样选择配置

如果确认对端是 TLS 1.2 客户端，而且协议确实会在同一连接上请求一次重协商，客户端配置可以明确写出策略：

config := &tls.Config{
    MinVersion:   tls.VersionTLS12, // 把兼容范围限定在仍需要重协商的旧协议
    Renegotiation: tls.RenegotiateOnceAsClient, // 只允许远端请求一次，降低暴露面
}

conn := tls.Client(rawConn, config)
if err := conn.Handshake(); err != nil {
    return fmt.Errorf("TLS 兼容握手失败: %w", err) // 保留原始错误，便于区分版本和重协商问题
}
defer conn.Close() // 连接由当前函数创建时，结束后释放底层 TLS 资源

不要为了“让旧客户端先连上”直接使用 RenegotiateFreelyAsClient，也不要把 InsecureSkipVerify 当成重协商修复。前者扩大了接受范围，后者改变的是客户端证书链和主机名校验，两者解决的不是同一个问题。

如果对端是 TLS 1.3，应该回到协议设计：TLS 1.3 没有重协商，应用层需要重新认证或更新密钥时，应使用对应的应用协议机制，而不是继续调高 Renegotiation。

最后用一张表做回归判断

相关问题：

• 为什么把 Renegotiation 写成服务端配置仍然没有触发重协商？
• RenegotiateOnceAsClient 和 RenegotiateFreelyAsClient 应该怎样做兼容回归？
• 如何确认错误发生在第一次握手还是后续重协商阶段？

结论很简单：先记录握手阶段和 TLS 版本，再确认对端的协议行为；只有 TLS 1.2 兼容需求被证实后，才选择最小范围的 Renegotiation 设置。