Go crypto/tls按 ServerName 选择证书的实现方式

在一个 Go HTTPS 服务里同时承载 api.example.com 和 console.example.com 时，证书选择的关键入口是 tls.Config.GetCertificate。客户端在 ClientHello 中发送 SNI 后，Go 会把域名放到 ClientHelloInfo.ServerName，回调可以据此返回对应的 tls.Certificate。实际项目里，证书应在启动阶段加载，回调只做规范化、查表和回退，不要在握手期间读取磁盘。

先把 ServerName 和证书查表关系固定下来

ClientHelloInfo.ServerName 表示客户端为虚拟主机发送的名称，只有使用 SNI 时才会设置。它不是服务端本地监听地址，也不是证书的 Common Name 自动匹配结果。最稳妥的结构是把域名到证书对象的映射在启动时准备好，再由回调读取。

用 GetCertificate 实现精确域名选择和默认回退

下面的示例把证书加载和选择分开。Certificates 中放默认证书，回调中对域名做小写和末尾点处理，再查找明确的映射。未知域名仍返回默认证书，是因为这个示例假设服务有一个统一的兜底站点；如果业务不能接受这种回退，可以改成返回错误，让握手失败。

package main

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

func newTLSConfig() (*tls.Config, error) {
    // 启动时加载证书，避免握手期间读文件和解析 PEM。
    defaultCert, err := tls.LoadX509KeyPair("default.crt", "default.key")
    if err != nil {
        return nil, fmt.Errorf("加载默认证书: %w", err)
    }
    apiCert, err := tls.LoadX509KeyPair("api.crt", "api.key")
    if err != nil {
        return nil, fmt.Errorf("加载 API 证书: %w", err)
    }

    // 回调只读这张表；配置投入使用后不要并发修改它。
    certificates := map[string]*tls.Certificate{
        "api.example.com": &apiCert,
    }
    cfg := &tls.Config{
        // 没有 SNI 或未知域名时使用默认证书。
        Certificates: []tls.Certificate{defaultCert},
    }
    cfg.GetCertificate = func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
        // SNI 可能为空；去掉末尾点只用于稳定查表，不改变证书内容。
        name := strings.ToLower(strings.TrimSuffix(hello.ServerName, "."))
        if cert, ok := certificates[name]; ok {
            return cert, nil
        }
        // 返回 nil 让 crypto/tls 使用 Certificates 中的默认兼容证书。
        return nil, nil
    }
    return cfg, nil
}

这个回调返回 nil, nil 时，crypto/tls 会继续按配置中的证书集合处理；因此默认项必须确实存在。生产环境如果域名对应证书可能在运行期轮换，应使用受控的原子快照或读锁替换映射，不能在回调中直接修改正在使用的 tls.Config。

未知域名和无 SNI 是两个不同的边界

未知域名说明客户端发送了 SNI，但这个名称没有注册；空 ServerName 则可能是旧客户端、非 SNI 客户端或测试连接没有发送扩展。两者都能走默认证书，但日志和业务判断不应混为一谈。对于租户隔离严格的服务，回调可以把未知名称和空名称都返回错误，并在握手层记录原因。

还要留意证书选择和证书校验是两件事。服务端选择了某张证书，不代表客户端一定信任它；客户端仍会检查证书链、有效期和主机名。反过来，服务端也不应通过关闭客户端校验来证明 SNI 路由正确。

什么时候需要 GetConfigForClient

GetCertificate 只解决“这一条握手返回哪张证书”。如果不同租户还要使用不同的 ClientAuth、信任池、协议边界或验证回调，就应评估 GetConfigForClient，因为它返回的是本次连接使用的另一份配置。配置切换范围更大，也更容易出现共享对象被修改、证书和认证策略不一致等问题。

迁移时建议保留四组检查：已知域名是否拿到对应证书；未知域名是否按设计回退或拒绝；不带 SNI 的连接是否有明确结果；证书链错误是否仍能被原样记录。不要只用浏览器访问一个域名就宣布配置完成，因为那只能覆盖一条带 SNI 的成功路径。

常见问题

ServerName 为空时能不能遍历所有证书猜一张？

不建议。没有 SNI 就没有可靠的租户选择依据，应使用明确默认项或拒绝握手，不能把任意证书当成正确结果。

NameToCertificate 还能继续用吗？

旧代码可能仍能运行，但官方文档已说明它只能把一个名称关联到一张证书并标记弃用。新代码更适合用 GetCertificate 表达选择规则。

证书轮换时直接替换 map 可以吗？

不要在握手回调并发读写普通 map。准备新快照后用原子指针或读写锁整体替换，并确保返回的证书对象不会再被修改。

Go 官方 crypto/tls 文档和源码都把 SNI、GetCertificate、GetConfigForClient 作为独立边界。先决定是换证书还是换整份 TLS 策略，再选择回调入口，问题会比堆叠证书列表更容易定位。