TLS 名称校验

在 Go 的裸 crypto/tls 客户端里，ServerName 为空时不会自动从 host:port 中猜一个证书名称。默认校验开启时，客户端会在握手准备阶段直接返回错误；即使把 TCP 目标写成域名，拨号地址也不等于证书校验名称。

正确做法是把“连到哪个地址”和“证书应该匹配哪个名称”分开配置：连域名时通常显式设置同一个域名，连 IP 时让证书包含对应的 IP SAN；不要用 InsecureSkipVerify 去掩盖名称不匹配。

ServerName 到底校验什么

tls.Config.ServerName 同时承担两个职责：客户端用它校验证书中的主机名，并在目标不是 IP 地址时把它作为 SNI 名称放进 ClientHello。证书校验关注的是证书的 SAN，而不是 TCP 连接字符串本身。

因此下面三项不能混为一谈：

• TCP 目标：例如 10.0.0.8:8443，解决网络连接到哪台机器。
• ServerName：例如 api.example.com，解决证书应该匹配哪个名称，也可能影响服务端的虚拟主机证书选择。
• SAN：证书中声明的 DNS 名称或 IP 地址，必须能匹配校验名称。

为什么 ServerName 为空会直接失败

Go 当前 crypto/tls 的客户端握手逻辑要求：当 InsecureSkipVerify 为 false 时，ServerName 不能为空。这个检查发生在客户端生成握手消息之前，所以问题不是“服务端返回了错误证书”，而是客户端还没有足够信息开始安全校验。

这也解释了一个常见误区：tls.Dial("tcp", "api.example.com:443", config) 中的域名只是拨号参数，Go 不会因此把它回填到 config.ServerName。如果配置对象没有名称，连接目标本身不能替代证书校验名称。

名称不匹配时也不要先改成跳过校验。InsecureSkipVerify=true 会同时关闭服务端证书链和主机名的默认验证，官方文档明确提示这会让连接容易受到中间人攻击；只有测试或你已经完整接管验证回调时才应考虑它。

按域名、IP 地址配置客户端

生产连接最稳妥的方式是先确定证书的 SAN，再决定 ServerName。如果证书包含 api.example.com，就使用这个 DNS 名称；如果服务只能通过 IP 访问，证书应包含对应的 IP SAN，不能拿 DNS SAN 冒充 IP。

package main

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

// dialTLS 把网络地址与证书校验名称分开，避免依赖隐式推导。
func dialTLS(ctx context.Context, address, serverName string) (*tls.Conn, error) {
    if serverName == "" {
        return nil, errors.New("ServerName 不能为空")
    }

    // ServerName 用于主机名校验；非 IP 名称还会用于 SNI。
    cfg := &tls.Config{ServerName: serverName, MinVersion: tls.VersionTLS12}
    dialer := &tls.Dialer{
        NetDialer: &net.Dialer{Timeout: 5 * time.Second},
        Config:    cfg,
    }

    // DialContext 会完成 TCP 连接和 TLS 握手，失败时没有可复用的连接。
    conn, err := dialer.DialContext(ctx, "tcp", address)
    if err != nil {
        return nil, fmt.Errorf("TLS 连接失败: %w", err)
    }
    return conn.(*tls.Conn), nil
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
    defer cancel()

    // TCP 可以连 IP，但证书名称仍按虚拟主机域名校验。
    conn, err := dialTLS(ctx, "10.0.0.8:8443", "api.example.com")
    if err != nil {
        panic(err)
    }
    defer conn.Close() // 连接不再使用时释放底层资源
}

这个例子故意把 10.0.0.8:8443 与 api.example.com 分开：网络路径可以指向内网 IP，但证书必须能匹配 api.example.com，服务端也可能依据这个 SNI 选择对应证书。如果把 serverName 改成 IP，则证书需要包含该 IP 的 SAN。

上层 HTTP 客户端要注意谁负责填充

如果使用 net/http，连接流程由 http.Transport 管理，Transport 通常会根据请求 URL 的主机名处理 TLS 名称。但一旦你自定义了 TLSClientConfig、复用了连接，或直接使用 crypto/tls，就应明确检查最终的 ServerName 是否符合目标证书。

排查名称错误时按这个顺序对照即可：

1. 先看 TCP 目标：它只回答“连接到哪里”，不能直接证明证书名称正确。
2. 再看 ServerName：域名场景填写证书中的 DNS SAN；IP 场景填写证书中的 IP SAN。
3. 最后看证书 SAN：不要只看证书的旧式 Common Name，也不要把端口号写进名称。
4. 若仍失败，保留原始握手错误；它通常能区分名称不匹配、证书链不受信和超时。

几个容易混淆的问题

ServerName 能不能写成带端口的地址？不能。它是主机名或 IP 地址，不是 host:port。端口属于网络地址，证书 SAN 不会按端口匹配。

连 IP 时一定要发送 SNI 吗？不需要。Go 文档说明 IP 地址不会作为客户端 SNI 名称；但证书校验仍然需要对应的 IP SAN。

测试自签名证书怎么办？优先把测试 CA 加入 RootCAs，并继续设置正确的 ServerName。只有在自定义验证逻辑已经覆盖证书链和名称检查时，才使用跳过默认校验的配置。

总结

• ServerName 不是拨号地址的别名，而是证书名称校验和 SNI 的输入。
• 默认校验开启时它为空会直接失败；Go 不会从 TCP 目标自动猜名称。
• 域名对应 DNS SAN，IP 对应 IP SAN；不要用 InsecureSkipVerify 代替正确配置。