Go crypto/tls 怎样加载多证书配置

Go crypto/tls 加载多证书，可以在启动时分别调用 LoadX509KeyPair，把明确域名映射到证书对象，再通过 tls.Config.GetCertificate 按 ClientHelloInfo.ServerName 选择。若业务不允许未知域名落到默认证书，未匹配和缺少 SNI 时应返回错误，而不是返回 nil, nil。本文示例让 Certificates 保持为空，确保无 SNI 的新握手也进入回调处理。

官方地址：https://pkg.go.dev/crypto/tls。本文只讨论证书选择与握手失败，不处理证书申请、自动续签或完整 TLS 安全加固；示例域名和文件名都是占位，不能直接当成部署材料。

我会先把多证书当作显式选择策略

面对两个域名共用一个 TLS 服务的配置，我更在意“没配的域名怎么办”，而不是先把几个证书放进列表。我的取舍是：域名数量少且固定时，用只读映射写清允许集合；没有匹配就拒绝。这里是方案判断，不是虚构一次线上故障经历。

SNI 来自 TLS ClientHello，HTTP Host 则属于后续 HTTP 消息，两者不能混为一谈。选中了某个证书，不代表应用请求就获得相应租户权限。业务仍需独立检查 Host、路由与身份；不要把客户端提供的 SNI 当成认证凭据。

单纯设置 Certificates 并非错误：如果只想让标准库从多条证书链中选择兼容候选，它更省代码。需要明确控制未知域名的处理方式，才值得引入 GetCertificate。本文采用的是精确域名选择，不是自动通配符路由器。

证书在启动时加载，回调只读选择

我倾向于把磁盘读取放在启动阶段。证书文件不可读、PEM 格式错误或证书与私钥不匹配，尽早返回错误，而不是让每次握手都尝试读取并反复失败。证书链文件应按叶证书在前、后续中间证书在后的形式准备，私钥文件应按服务运行账号的实际需要限制访问。

回调可能被并发握手调用，所以创建完成后不再写入 byName，也不修改已经返回的 Certificate。静态只读映射使这个例子不需要额外锁；它不意味着 map 支持无锁热更新。未来需要轮换时，应另行设计不可变快照与安全切换，不要一边握手一边修改现有对象。

用 GetCertificate 拒绝未知域名

下面是可集成的独立 Go 包。Host 配置约定为明确的 ASCII DNS 主机名；示例检查不是完整 DNS 名称校验器，不包含 IDNA 转换或证书签发资格检查。证书文件必须由部署方提供。代码未在本轮执行，不能视为已完成握手测试。

package snicerts

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

// CertFiles 仅接受明确的 ASCII DNS 主机名，不接受通配匹配规则。
type CertFiles struct {
    Host string
    CertFile string
    KeyFile string
}

// NewConfig 在启动阶段加载证书，返回后不再修改映射或证书对象。
func NewConfig(files []CertFiles) (*tls.Config, error) {
    if len(files) == 0 {
        return nil, fmt.Errorf("至少配置一个证书")
    }
    byName := make(map[string]*tls.Certificate, len(files))
    for _, entry := range files {
        name := strings.ToLower(entry.Host)
        if name == "" || strings.ContainsAny(name, "*/: ") {
            return nil, fmt.Errorf("配置需要明确的 DNS 主机名")
        }
        if _, exists := byName[name]; exists {
            return nil, fmt.Errorf("存在重复主机名")
        }
        pair, err := tls.LoadX509KeyPair(entry.CertFile, entry.KeyFile)
        if err != nil {
            return nil, fmt.Errorf("加载证书对失败: %w", err)
        }
        // 显式设置 Leaf，避免依赖不同版本的加载默认行为。
        pair.Leaf, err = x509.ParseCertificate(pair.Certificate[0])
        if err != nil {
            return nil, fmt.Errorf("解析叶证书失败: %w", err)
        }
        byName[name] = &pair
    }

    cfg := &tls.Config{
        MinVersion: tls.VersionTLS12,
        // Certificates 故意留空，无 SNI 时也进入选择回调。
        GetCertificate: func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
            if hello == nil || hello.ServerName == "" {
                return nil, fmt.Errorf("需要 SNI 主机名")
            }
            cert, ok := byName[strings.ToLower(hello.ServerName)]
            if !ok {
                return nil, fmt.Errorf("未配置该 SNI 主机名")
            }
            // 仅检查候选与 ClientHello 的兼容性，不代表客户端信任。
            if err := hello.SupportsCertificate(cert); err != nil {
                return nil, fmt.Errorf("证书不适用于此次握手: %w", err)
            }
            return cert, nil
        },
    }
    return cfg, nil
}

代码为每个循环体创建局部 pair，再把它交给映射，返回的配置闭包持有这些对象。证书加载成功并不证明链受客户端信任；SupportsCertificate 处理候选与该次 ClientHello 的兼容性，也不能代替客户端对有效期、信任链与目标名称的完整校验。

调用方式可以在现有服务初始化逻辑中使用下面片段。两个名称必须由各自证书的 SAN 覆盖，文件名需替换为实际受控路径；不要把私钥内容放进源码或日志。

// 在现有服务启动函数中加载两份证书；配置错误则停止启动。
cfg, err := snicerts.NewConfig([]snicerts.CertFiles{
    {Host: "api.example.com", CertFile: "certs/api-chain.pem", KeyFile: "certs/api-key.pem"},
    {Host: "files.example.com", CertFile: "certs/files-chain.pem", KeyFile: "certs/files-key.pem"},
})
if err != nil {
    return err
}
// 将 cfg 交给现有 TLS 服务端初始化逻辑，不再修改其字段。
_ = cfg

这段调用假定已按项目实际模块路径导入 snicerts，且位于返回 error 的初始化函数内。它不是完整 main；监听、连接超时和服务退出仍由现有服务负责。

默认回退和热修改为什么容易踩坑

GetCertificate 并非在任意配置下无条件执行：客户端提供 SNI，或者 Certificates 为空时，才符合文档的回调条件。因此，如果额外填了默认证书列表，再期待无 SNI 一定被本回调拒绝，就会改变示例的策略。未知名称返回 nil, nil 也不是明确拒绝，它允许标准库继续走配置里的候选回退。

我会把这种拒绝策略的代价提前说明：不发送 SNI 的客户端无法按本例完成新的证书协商，按 IP 直连也不能假定会发送预期域名。兼容无 SNI 客户端确有需要时，应明确指定一个受控默认站点，并说明它的限制，而不是顺手返回第一份证书。

还有一个容易忽略的边界：证书选择回调不是覆盖每个请求的访问控制钩子，也不能把它当作所有会话恢复路径的强制鉴权点。本文只约定发生证书选择时的行为；需要连接级或请求级策略，应选择相应机制另行设计。

上线判断与常见问答

下面是读者在隔离环境可安排的预期检查，不是本文已经执行的结果。不要用跳过客户端证书验证来掩盖选择配置错误。

一张通配符证书需要展开成很多文件吗？

不需要因为域名多就重复生成文件；证书身份覆盖与选择映射是两件事。但本文映射只做精确名称查询，不会自动把 *.example.com 配置展开成子域名匹配。

选到了证书，为什么浏览器仍报错？

还可能存在名称不覆盖、过期或链信任问题，也可能是客户端能力不兼容。先区分服务端选择失败和客户端验证失败，不能只看“文件加载成功”就认定 TLS 已经配置正确。

配置返回后能直接往映射加证书吗？

本例不支持。需要热更新就重新设计快照发布与轮换生命周期；当前只读方案适合域名有限、重启加载可接受的服务。

对我而言，采用这份方案的前提是愿意承担显式映射与拒绝策略的维护责任。若没有自定义选择要求，让标准库处理证书候选通常更简单；一旦选择回调，就应同时交代未命中、兼容性与不可变对象的边界。