TLS握手失败但证书看起来正确怎么办

Go 客户端出现 TLS 握手失败时，证书页面“看起来正确”并不能证明实际连接条件一致。先保留完整错误链，再核对拨号地址、ServerName、服务端实际发送的证书链、客户端根证书和系统时间；如果尚未进入证书校验，还要检查端口、协议协商及双向认证要求。不要通过关闭证书校验来代替定位。

官方地址：https://pkg.go.dev/crypto/tls

定义诊断输入与调用目标

设想应用直接拨某个后端 IP，而浏览器访问的是域名入口。两次访问可能经过不同负载均衡节点、使用不同 SNI，也可能读取不同的根证书集合。因此排障接口应显式记录三个输入：网络地址、期望服务身份、实际使用的 TLS 配置。错误日志记录阶段和类型即可，不需要带上客户端私钥或业务凭据。

这里采用的设计是把网络地址与服务身份拆成两个参数，函数返回标准错误链。这样可以测试某个被授权的后端节点是否能为指定服务身份完成校验，而不是随意改变身份来迁就不匹配的证书。

拨号地址和 ServerName 为什么要分开？

address 是网络连接目标，形式为主机加端口。ServerName 用于核对证书中的服务名称；当它是域名时，也用于握手的 SNI，帮助服务器选择虚拟主机证书。ServerName 不是包含 scheme、端口或路径的完整 URL。

例如网络目标可以是一个已知后端 IP 加 443，期望身份仍是证书所覆盖的业务域名。这个域名必须来自真实服务配置，不能从报错提示里任选一个名称。若服务身份本来就是 IP，证书需要相应 IP SAN；DNS SAN 中看起来像 IP 的文本不能简单等同于 IP SAN。现代名称校验也不依赖旧式 Common Name 字段。

怎样核对客户端信任和完整证书链？

RootCAs 为 nil 时，客户端使用主机的根 CA 集合。容器、开发机和浏览器的信任环境可能不同，尤其是私有 CA、企业代理或者精简容器镜像。应在发生故障的运行环境核对，而不是仅在个人浏览器里查看。

未知颁发机构错误既可能与客户端缺少可信根有关，也可能与服务端未提供所需中间证书有关。服务端应发送正确的叶证书和必要中间链，客户端则信任经过批准的根。不要把服务器临时拿到的任意证书直接追加为可信根，也不要把所有信任故障都解释成证书过期。

有效期还依赖客户端实际时钟。检查 NotBefore、NotAfter 与系统时间是否一致，并确认用途和链约束满足服务端认证要求。浏览器能形成链，不代表 Go 进程在相同网络、根集合和缓存条件下也能形成同一条链。

保留错误类型并使用最小探针

下面的独立程序只进行 TCP 与 TLS 连接，不发送 HTTP 业务请求。读者应将参数替换为自己管理或获授权诊断的服务。它保留默认证书校验，设定最低 TLS 1.2，使用系统信任根，并通过上下文限制整个拨号及握手时间。没有配置客户端证书或特定 ALPN，因此只是基础探针。

package main

import (
    "context"
    "crypto/tls"
    "crypto/x509"
    "errors"
    "flag"
    "fmt"
    "log"
    "net"
    "time"
)

// Probe 的两个参数分别表示网络目标与经过配置确认的服务身份。
func Probe(ctx context.Context, address, serverName string) (err error) {
    if address == "" || serverName == "" {
        return errors.New("address 和 server-name 必须提供")
    }
    dialer := tls.Dialer{
        NetDialer: &net.Dialer{Timeout: 5 * time.Second},
        Config: &tls.Config{
            ServerName: serverName,
            MinVersion: tls.VersionTLS12,
        },
    }
    conn, err := dialer.DialContext(ctx, "tcp", address)
    if err != nil {
        // 包装时保留原因，调用方才能用 errors.As 分类。
        return fmt.Errorf("连接或 TLS 握手失败: %w", err)
    }
    defer func() { err = errors.Join(err, conn.Close()) }()
    log.Print("基础 TLS 握手完成")
    return nil
}

func main() {
    address := flag.String("address", "", "授权服务的主机:端口")
    name := flag.String("server-name", "", "证书应覆盖的服务名称")
    flag.Parse()

    ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
    defer cancel()
    if err := Probe(ctx, *address, *name); err != nil {
        var hostErr x509.HostnameError
        var trustErr x509.UnknownAuthorityError
        var certErr x509.CertificateInvalidError
        switch {
        case errors.As(err, &hostErr):
            log.Print("分类：服务名称与证书不匹配")
        case errors.As(err, &trustErr):
            log.Print("分类：无法建立可信证书链")
        case errors.As(err, &certErr):
            log.Print("分类：证书有效性或链约束失败")
        default:
            log.Print("分类：需继续检查网络、协议或服务端告警")
        }
        // 真实环境对详细错误按日志权限管理，不输出私钥。
        log.Printf("诊断错误: %v", err)
    }
}

代码使用 errors.Join，工具链需要 Go 1.20 或更高版本。证书分类只是便于确定下一步，不是穷举所有 TLS 错误。错误可能被多层包装，因此使用 errors.As 而不是仅比较最外层类型或依赖某一句英文文本。探针没有在本文环境执行，也没有提供假定成功的日志。

如果同样的地址与身份在探针中成功，而完整应用仍失败，应比较应用额外设置的 RootCAs、客户端证书、代理、ALPN、回调和连接目标。普通 TLS 握手成功也不保证 HTTP、业务鉴权或者应用协议一定成功。

协议兼容和双向认证有哪些边界？

错误发生在证书校验之前时，反复更换叶证书通常无效。例如拨到了普通 HTTP 端口，或者服务要求先进行 STARTTLS 升级，直接发送 TLS 握手就不符合协议。代理路径也要与实际应用一致；上面的直接拨号探针不会自动复现 HTTP CONNECT 代理。

遇到旧服务兼容问题，先核对双方版本与协议配置，优先升级服务端，不应一上来降低安全要求。TLS 1.3 的密码套件不能通过 Config.CipherSuites 调整；手工拷贝旧套件列表也可能限制现代协商。若服务要求 mTLS，则还需要可信来源的客户端证书与对应私钥，并让服务端信任该客户端链。

证书没过期，为什么仍失败？

有效期只是条件之一，名称、链、信任根、用途和服务端实际发送的证书都可能不同。

改 HTTP Host 能修复 SNI 吗？

HTTP Host 属于握手后的应用请求。它不能代替 TLS 握手中的 ServerName 配置。

可以直接把 InsecureSkipVerify 打开吗？

这会跳过通常的证书链与名称校验，不能作为故障修复。本例保留校验，按错误类型修正真实配置。

官方参考：https://pkg.go.dev/crypto/tls#Config；证书校验：https://pkg.go.dev/crypto/x509#Certificate.Verify。