Go tls.Config ServerName 不设置时证书校验为何失败

用 Go 写 TLS 客户端时，tls.Config{} 看起来像“使用默认安全配置”，但它没有告诉客户端要校验哪个主机名。保持 InsecureSkipVerify: false 时，ServerName 为空会让握手在证书链和主机名真正比对之前就失败。

修复方法通常不是关闭证书校验，而是把 ServerName 设置为证书 SAN 中的服务名。即使 TCP 实际拨到内网 IP，TLS 仍然要用这个服务名完成主机名校验，并在需要时发送 SNI。

为什么 ServerName 为空时还没到证书校验

Go 的客户端握手会先检查配置：当 ServerName 为空且 InsecureSkipVerify 为假时，直接返回 tls: either ServerName or InsecureSkipVerify must be specified in the tls.Config。所以日志里没有“unknown authority”并不奇怪，这次失败发生在发送完整 ClientHello 之前。

这个前置条件解决的是“校验对象是谁”，不是“证书是否被系统或自定义 CA 信任”。因此，补上名称后如果错误变成 x509: certificate signed by unknown authority，说明已经进入证书链检查，下一步应查 RootCAs 或系统证书池。

先分清拨号地址、校验名称和 SNI

排查内网服务时最容易把三个值混成一个。TCP 只负责找到对端；TLS 需要一个可验证的身份；服务端还可能依据 SNI 选择证书。把它们拆开，配置就不容易绕错：

如果证书只有 DNSNames 里的 api.example.com，却把 ServerName 写成 10.0.0.8，就会得到主机名不匹配。反过来，如果证书确实包含对应的 IP SAN，才可以使用 IP 作为校验名；普通 DNS SAN 不会自动覆盖 IP。

正确配置自定义拨号与证书校验

下面的写法适合“连接走固定 IP，证书仍属于域名”的场景。Dialer 只改变网络连接目标，ServerName 仍保持证书里的名称；示例还保留了上下文取消和关闭连接。

package main

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

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel() // 超时后释放本次拨号的上下文资源

    cfg := &tls.Config{
        ServerName: "api.example.com", // 用证书 SAN 中的名称做校验，也用于 SNI
        MinVersion: tls.VersionTLS12,  // 只表达最低版本要求，不关闭证书验证
    }
    dialer := &net.Dialer{Timeout: 3 * time.Second} // TCP 连接目标单独由 Dialer 控制
    tlsDialer := &tls.Dialer{NetDialer: dialer, Config: cfg}

    conn, err := tlsDialer.DialContext(ctx, "tcp", "10.0.0.8:443")
    if err != nil {
        fmt.Println("TLS 握手失败：", err) // 再根据 unknown authority 或 hostname mismatch 分支排查
        return
    }
    defer conn.Close() // 无论后续请求是否成功，都关闭 TLS 连接
    fmt.Println("TLS 已建立：", conn.(*tls.Conn).ConnectionState().ServerName)
}

这里的 ServerName 不是“给日志看的备注”，而是验证身份的输入。若使用 http.Transport，也要注意自定义 DialContext 只负责把连接拨到哪里，不要在自定义 DialTLSContext 中丢掉原有的 TLS 配置。

用错误关键词判断下一步查哪里

补齐 ServerName 后，可以按下面的顺序缩小范围：

1. 仍是配置错误：检查传给 tls.Client、tls.Dialer 或 HTTP Transport 的是否真是这份配置，尤其留意自定义拨号函数是否重新创建了空配置。
2. unknown authority：名称已经进入校验流程，但根证书不在系统池或 RootCAs 中。追加正确的 CA，不要用跳过校验代替信任配置。
3. certificate is valid for ..., not ...：查叶子证书的 SAN。域名匹配 DNSNames，IP 匹配 IPAddresses，不要只看旧的 CN 字段。
4. 服务端返回了错误证书：检查 SNI 是否应为域名，以及中间代理、网关是否依据 SNI 选择虚拟主机证书。

最后记住一个边界：InsecureSkipVerify: true 会关闭默认的证书链和主机名校验，不能当作 ServerName 的常规替代品。只有在测试或确实实现了等价自定义校验时，才有理由使用它。

相关问题

ServerName 要不要带端口？

不要。它应是主机名或 IP，端口留在拨号地址中，例如 api.example.com 配合 api.example.com:443。

证书只有 CN 没有 SAN 能匹配吗？

不要依赖 CN。Go 的 x509.VerifyHostname 按 DNS 名称或 IP SAN 检查，旧式 Common Name 不应作为新证书配置方案。

设置 ServerName 后仍然握手失败怎么办？

先看错误类型：未知 CA 查信任链，主机名错误查 SAN，服务端证书不对查 SNI 和网关路由；三者不是同一个问题。