证书轮换时旧长连接会立即失效吗，更新范围怎样判断

不会。Go TLS 服务把新证书发布到热更新回调后，已经完成握手的旧长连接通常不会立即失效。它会继续使用握手时确定的连接状态，直到对端关闭、超时、服务端主动排空，或者底层网络中断。新证书主要作用于后续的新握手。

真正需要判断的是三类连接：旧的已建立连接、新的完整握手、基于会话票据的恢复握手。常规续期通常只要保证新握手拿到新证书；私钥泄露或证书撤销等紧急轮换，还要处理会话恢复和旧连接排空。

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

我为什么会注意到旧长连接没有断

我第一次给一个带 WebSocket 的 Go 服务做证书热更新时，新建连接已经能看到新证书，但已有连接仍持续收发消息。最初我以为回调没有生效，后来把连接按生命周期拆开，才发现这是预期行为：证书参与的是握手认证，不是每一条应用数据记录都重新验证一次。

这也解释了一个常见误判：用浏览器刷新或重新执行客户端请求，看到新证书，只能证明新连接范围已经更新；它不能证明旧连接已经退出。

先把轮换范围分成三类连接

证书来源：先完整校验，再替换旧快照

证书轮换的第一条工程规则不是“文件变了就覆盖”，而是“新材料完整可用后才发布”。tls.LoadX509KeyPair 会读取并解析证书链与私钥；如果文件只写了一半、证书与私钥不匹配或 PEM 损坏，更新应直接失败，旧证书继续服务。

我更倾向于把加载和发布放在同一个函数里：解析成功前不碰当前指针，解析成功后只做一次原子替换。这样文件监听器即使重复触发，也不会把一个半成品暴露给握手路径。

用不可变快照发布新证书

tls.Config 一旦传给 TLS 函数就不应再修改。直接并发改写 Config.Certificates 既违背官方约定，也容易产生数据竞争。只轮换服务端证书时，一个简单做法是让配置保持不变，通过 GetCertificate 从原子指针读取不可变证书快照。

package certstore

import (
    "crypto/tls"
    "errors"
    "fmt"
    "sync/atomic"
)

type Store struct {
    // current 始终指向已经完整解析的证书快照
    current atomic.Pointer[tls.Certificate]
}

func New(certFile, keyFile string) (*Store, error) {
    s := &Store{}
    if err := s.Reload(certFile, keyFile); err != nil {
        return nil, err
    }
    return s, nil
}

func (s *Store) Reload(certFile, keyFile string) error {
    // 先在局部变量中完成证书链与私钥校验
    next, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        // 加载失败时保留旧快照，避免扩大故障
        return fmt.Errorf("load TLS key pair: %w", err)
    }

    // 只有完整加载成功后才原子发布新证书
    s.current.Store(&next)
    return nil
}

func (s *Store) GetCertificate(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
    cert := s.current.Load()
    if cert == nil {
        return nil, errors.New("TLS certificate is not ready")
    }

    // 按当前 ClientHello 检查签名算法等兼容条件
    if err := hello.SupportsCertificate(cert); err != nil {
        return nil, fmt.Errorf("certificate is not supported: %w", err)
    }
    return cert, nil
}

服务端配置可以保持很小。为了确保新握手走回调，这里不再同时填充静态 Certificates：

store, err := certstore.New("server.crt", "server.key")
if err != nil {
    log.Fatal(err)
}

tlsConfig := &tls.Config{
    // 新 ClientHello 到达时读取当前证书快照
    GetCertificate: store.GetCertificate,
    // 明确最低协议版本，避免依赖旧协议
    MinVersion: tls.VersionTLS12,
}

server := &http.Server{
    Addr:      ":8443",
    Handler:   mux,
    TLSConfig: tlsConfig,
}

// 证书由 GetCertificate 提供，因此文件参数保持为空
if err := server.ListenAndServeTLS("", ""); err != nil && err != http.ErrServerClosed {
    log.Fatal(err)
}

官方文档还说明，GetCertificate 在客户端提供 SNI 或 Certificates 为空时调用；回调返回的 Certificate 不应再被修改。因此，原子替换指针比修改同一个证书对象更容易守住并发边界。

什么时候要从 GetCertificate 升级到 GetConfigForClient

如果变化范围只有证书链和私钥，GetCertificate 已经足够。若同时变化的是客户端证书验证、根证书池、ALPN、协议版本、密码套件策略或其他握手配置，就应准备一个新的完整 tls.Config，再通过 GetConfigForClient 为新连接返回它。

这里仍然要遵守不可变原则：可以安全地对正在使用的配置调用 Clone，在克隆副本尚未发布时完成修改；一旦回调返回该配置，就不要再改。不要为了少创建一个对象，直接在共享配置上换切片或证书池。

按连接类型判断轮换范围

我现在会把轮换检查拆成三个域，而不是只问“证书更新成功了吗”。已建立连接域关注排空；新建连接域关注当前证书快照；恢复连接域关注会话票据和验证回调。

既有长连接

连接完成握手后，证书与协商结果已经进入该连接的状态。替换磁盘文件或回调指针不会让 Go 自动重跑握手，也不会因为旧证书随后到期就立即关闭连接。要让这批连接看到新证书，必须让它们结束并重新连接。

新的完整握手

这部分最直接：新 ClientHello 到达后，回调读取当前快照并返回新证书。发布完成时间应以“新快照已经存入原子指针”为界，而不是以“证书文件已经覆盖”为界。

恢复握手

恢复连接不能简单等同于完整握手。Go 文档明确指出，VerifyPeerCertificate 不会在恢复连接上调用，而 VerifyConnection 会在包括恢复连接在内的所有连接上调用。ConnectionState.DidResume 可以帮助观测实际是否发生了恢复。

如果轮换只是正常续期，保留会话恢复通常没有问题。若旧证书对应的私钥疑似泄露，目标就不只是让新完整握手看到新证书，而是尽快停止旧会话语义。此时可在替换配置中暂时设置 SessionTicketsDisabled: true，并结合票据轮换、旧连接排空和客户端重连策略。是否这样做取决于事件严重性，因为禁用恢复会增加完整握手开销。

异常处理：热更新成功不等于轮换完成

我会分别记录“证书快照发布成功”和“旧连接退出完成”，而不是合并成一个成功状态。建议至少观察这些信号：

• 证书加载成功时间、叶子证书序列号和有效期；
• 加载失败次数，以及失败期间旧证书是否继续可用；
• 新握手数量、握手错误和 SNI 兼容错误；
• DidResume 为真的连接比例；
• 轮换前建立且仍存活的连接数量；
• 排空超时后仍未退出的 WebSocket 或其他劫持连接数量。

记录证书标识时使用序列号、指纹或内部版本号，不要把私钥内容、完整 PEM 或敏感路径写进日志。

清理策略：普通续期和紧急轮换不是一套动作

对普通 HTTP 服务，http.Server.Shutdown 会先关闭监听器和空闲连接，再等待活动连接回到空闲状态。它不会中断正在处理的活动连接。对于 WebSocket 等已经被劫持的连接，官方文档明确说明 Shutdown 不会替你关闭或等待它们，需要通过 RegisterOnShutdown 或协议自己的连接注册表发出关闭通知并等待退出。

ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

// 先通知 WebSocket、升级协议等自管长连接停止接收新任务
server.RegisterOnShutdown(func() {
    hub.BeginDrain()
})

// 关闭监听器并等待普通 HTTP 活动连接自然结束
if err := server.Shutdown(ctx); err != nil {
    // 超时后由运维策略决定是否强制关闭剩余连接
    log.Printf("TLS drain did not finish: %v", err)
}

对我来说，最重要的取舍是排空速度和业务中断之间的平衡。常规续期没有必要为了“所有连接立刻看到新证书”而强断；安全事件则不能只换回调指针后就宣布结束。

轮换完成前的范围判断清单

• 本次只换证书与私钥，还是连根证书、客户端认证、ALPN 和协议策略一起换？
• 新证书是否先完整解析成功，再原子替换旧快照？
• 共享的 tls.Config 和已返回的 Certificate 是否保持不可变？
• 新完整握手是否已经读取新证书，而不是只确认磁盘文件变化？
• 是否区分了完整握手与 DidResume 为真的恢复握手？
• 自定义验证是否错误依赖不会在恢复连接调用的 VerifyPeerCertificate？
• 紧急轮换是否包含会话票据策略与旧连接排空？
• WebSocket 或劫持连接是否有独立的注册、通知和等待机制？

几个常见追问

旧证书到期后，已经建立的连接会自动断吗？

通常不会仅因证书到期而自动断开。证书有效性是在握手阶段检查的；连接是否继续存活由协议、超时、应用逻辑和网络状态决定。

直接覆盖 server.crt 和 server.key 就够了吗？

不够。Go 进程不会因为文件被覆盖就自动替换内存中的证书对象，需要文件监听或控制面触发重新加载，并通过回调或新配置发布。

轮换时一定要关闭会话恢复吗？

不一定。常规续期通常不需要；涉及私钥泄露、撤销或验证策略发生实质变化时，才需要把会话恢复纳入风险范围，并评估暂时禁用或轮换票据的代价。

总结

证书轮换不是一个“替换文件后所有连接同时切换”的事件，而是一组连接生命周期。最小正确实现是：新证书先校验、成功后原子发布、旧快照失败不动、新完整握手读取新快照。若风险高到必须让旧身份尽快退出，再追加会话恢复控制和旧长连接排空。

把已建立连接、完整握手和恢复握手分开观察，轮换范围就会从模糊的“好像生效了”变成可判断、可监控、可收尾的工程过程。