TLS 配置

Go 里的“TLS 配置”不能只看连接是否成功。InsecureSkipVerify: true 仍然会建立加密连接，但客户端不再验证服务端证书链和证书中的主机名；中间人拿着任意证书也可能完成握手。生产代码更稳妥的做法，是先保留默认校验，再用 ServerName 和 RootCAs 解决真实的域名或内部 CA 问题。

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

先分清 TLS 配置的三层职责

TLS 连接成功至少包含三件事：协商出加密套件、验证服务端证书链、确认证书确实属于目标主机。InsecureSkipVerify 影响的是后两项客户端验证，不是“关闭 TLS”。所以抓包时看见内容仍然是密文，并不能证明连接是可信的。

官方实现中，正常路径会把 ServerName 作为主机名验证条件；它还会参与客户端握手中的服务器名称指示。把它留空并不能解决证书问题，反而可能让配置缺少明确的目标身份。

公网服务保留默认校验

访问证书由公共 CA 签发的 HTTPS 服务时，通常不需要手工关闭任何开关。给出明确的 ServerName，让连接目标、SNI 和证书主机名保持一致：

package main

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

func request(ctx context.Context) error {
    transport := &http.Transport{
        TLSClientConfig: &tls.Config{
            // 指定证书要匹配的服务名；不打开 InsecureSkipVerify。
            ServerName: "api.example.com",
            MinVersion: tls.VersionTLS12,
        },
    }
    client := &http.Client{Transport: transport, Timeout: 8 * time.Second}
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.example.com/health", nil)
    if err != nil {
        return fmt.Errorf("创建请求失败: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("TLS 请求失败: %w", err)
    }
    defer resp.Body.Close() // 及时释放响应体，避免连接池资源滞留。
    return nil
}

如果服务使用别名、代理或 IP 直连，先确认业务真正需要校验的主机名，再调整 URL、ServerName 和证书 SAN，而不是直接把校验跳过。

内部 CA 用 RootCAs 解决信任来源

自签名证书或企业内部 CA 不被操作系统默认信任时，正确方向是构建一个只包含受信 CA 的证书池。加载失败要立即返回，避免程序悄悄退回到不安全配置。

func internalTLS(pemBytes []byte) (*tls.Config, error) {
    roots := x509.NewCertPool()
    // 只把部署方提供的 CA 加入信任池，不接受任意服务端证书。
    if ok := roots.AppendCertsFromPEM(pemBytes); !ok {
        return nil, errors.New("内部 CA 证书解析失败")
    }
    return &tls.Config{
        // 该名称必须出现在服务端证书的 SAN 中。
        ServerName: "registry.corp.example",
        RootCAs:    roots,
        MinVersion: tls.VersionTLS12,
    }, nil
}

上面示例需要同时导入 crypto/x509 和 errors。RootCAs 只改变信任根，不会替你修正主机名；两者必须和服务端证书的实际 SAN 一起核对。

自定义校验只在认证规则明确时使用

VerifyConnection 可以补充证书指纹、租户名或专用策略，但回调不是“忽略错误”的同义词。若开启 InsecureSkipVerify 后只返回 nil，实际上仍没有完成服务端身份认证。除非你能在回调中完整实现证书链、有效期、用途和目标身份判断，否则应保持默认校验。

常见问题

设置 ServerName 后仍然证书错误怎么办？

检查证书 SAN 是否包含该名称、RootCAs 是否包含签发链，以及请求是否真的连到了对应服务；不要先改成跳过校验。

InsecureSkipVerify 会关闭加密吗？

不会。它主要跳过客户端对服务端证书链和主机名的验证，但会削弱身份认证，不能当作安全连接的证明。

只配置 RootCAs 就够了吗？

不够。RootCAs 解决“信任谁”，ServerName 解决“证书是不是给这个主机的”，两项职责不同。