Go crypto/tls 最小化证书轮换：GetCertificate 回调与并发读取边界

线上 HTTPS 服务最怕的不是“证书文件换不上”，而是换证书时把并发握手也带进了半成品状态。Go 的 crypto/tls 已经给了一个很窄的切入口：让 GetCertificate 每次握手读取当前的完整证书快照，轮换时只发布新的快照，不去修改正在使用的 tls.Config。

把证书解析和发布拆开：先用 LoadX509KeyPair 得到完整的 tls.Certificate，校验成功后再通过 atomic.Pointer[tls.Certificate] 一次性替换；读取失败就继续使用旧快照。

先厘清 GetCertificate 到底什么时候被调用

tls.Config.GetCertificate 的参数是 *tls.ClientHelloInfo。服务端配置中没有固定证书，或者客户端在 ClientHello 里提供了 SNI 时，TLS 会进入这个回调。回调返回一个完整的 *tls.Certificate，随后由握手继续使用。

这里有一个容易忽略的边界：回调返回后，证书对象就进入 TLS 的使用路径，不能再原地改它的切片字段。轮换的关键不是“把旧证书改成新证书”，而是准备一个全新的对象，再替换共享指针。

用不可变快照隔离解析和并发读取

下面的类型把共享状态缩小为一个指针。LoadX509KeyPair 在轮换线程里读取证书与私钥；只有它返回成功，新的 tls.Certificate 才会被 Store。握手回调通过 Load 拿到一个完整快照。

type CertificateStore struct {
    current atomic.Pointer[tls.Certificate]
}

func (s *CertificateStore) Get(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
    cert := s.current.Load()
    if cert == nil {
        return nil, errors.New("no certificate loaded")
    }
    return cert, nil
}

func (s *CertificateStore) Reload(certFile, keyFile string) error {
    next, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        return err
    }
    s.current.Store(&next)
    return nil
}

这个顺序带来两个实际保证。第一，证书文件损坏时，LoadX509KeyPair 直接返回错误，Store 不会发生，当前服务仍然使用旧快照。第二，Store 发布的是一个已经构造完成的值，读取方不会看到“证书链已换但私钥还没换”的中间状态。

把快照接进 HTTP 服务

服务启动时先加载一次初始证书，再把回调交给 tls.Config。示例保留了最小连接关系，轮换逻辑仍然只在 CertificateStore.Reload 中。

store := new(CertificateStore)
if err := store.Reload("server.crt", "server.key"); err != nil {
    log.Fatal(err)
}

tlsConfig := &tls.Config{
    GetCertificate: store.Get,
    MinVersion:     tls.VersionTLS12,
}

server := &http.Server{
    Addr:      ":8443",
    TLSConfig: tlsConfig,
}
log.Fatal(server.ListenAndServeTLS("", ""))

由于配置使用了 GetCertificate，ListenAndServeTLS 的证书参数可以留空。真正部署时，证书路径、轮换触发器和错误日志应由服务自身管理；不要在回调里同步读取磁盘，那会把握手延迟和文件系统故障绑在一起。

四个边界要在上线前验明

加载失败不能清空旧证书

先准备临时文件，再让 LoadX509KeyPair 读取完整内容；失败时只记录错误，不调用 Store。这样证书过期提醒和证书替换失败是两个独立事件。

旧连接不会自动改用新证书

证书选择发生在新的 TLS 握手阶段。已经完成握手的连接继续使用原来的连接状态，轮换影响的是之后建立的连接。若业务需要快速淘汰旧连接，应单独设计连接排空策略，不能把它伪装成证书轮换。

不要修改已发布的证书对象

atomic.Pointer 解决的是指针发布，不会替你保护对象内部的后续修改。把 tls.Certificate 当成只读值使用；需要变化时重新解析、重新构造、重新发布。

用新连接核对证书指纹

验收至少分成两次：轮换前建立客户端连接记录证书指纹，轮换后再建立一条新连接确认新指纹；同时观察一次故意加载错误文件时，服务是否仍能完成新握手。不要只看轮换线程打印了“成功”。

相关问题

为什么不直接替换 tls.Config.Certificates？

配置对象通常在服务启动后被多个连接共享。直接修改它会扩大并发读写边界，而回调加不可变快照只需要同步一个指针，故障面更小。

GetCertificate 能按域名返回不同证书吗？

可以读取 ClientHelloInfo.ServerName 做选择，但每个域名对应的证书仍应先完整解析并以只读快照保存；不要在回调里临时读文件。

小结

最小化的 Go 证书轮换方案只有三段：LoadX509KeyPair 负责生成候选快照，Store 负责在成功后发布，GetCertificate 负责在新握手时用 Load 读取。把失败留在候选阶段，把并发共享状态压缩成一次指针替换，证书轮换就不会和握手过程互相污染。