Go tls.Config 怎么轮换服务端会话票据密钥

线上 TLS 服务刚做完扩容，最容易被忽略的一类问题是：证书没有变，客户端却突然无法复用会话。排查到最后，通常不是证书链，而是不同实例手里的 session ticket key 不一致。Go 的做法很直接：把新 key 放在列表第一位，把仍需兼容的旧 key 放在后面，再调用 SetSessionTicketKeys；新票据用第一把 key 生成，所有列出的 key 都参与解密。

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

一、先判断当前服务由谁负责轮换

如果 Config.SessionTicketKey 保持零值，Go 会在第一次服务端握手前填充随机值，并自动按日轮换、七天后丢弃旧值。这条默认路径适合不需要跨进程控制的单体服务。问题在于，一旦业务需要自定义轮换周期、在多台实例之间同步，或者因为密钥暴露而立即撤销旧票据，就必须改用 SetSessionTicketKeys。

这里有一个容易踩的边界：自定义接口不是“额外覆盖一层自动策略”，而是接管策略。手动 ring 为空会触发 panic，所以不能把空列表当成“暂时禁用”。如果确实不希望恢复会话，应显式设置 SessionTicketsDisabled，并把它当作协议策略变更处理。

二、用新旧 key ring 做平滑切换

轮换的核心不是生成一把新 key，而是维护一个短期兼容窗口。第一项用于创建新 ticket，后续项只负责解密旧 ticket。下面的函数假定 key 已由安全配置源生成和分发；示例中的随机生成仅用于展示 32 字节格式，不应让每个副本各自生成。

package main

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

// newTicketKey 生成一把 32 字节 ticket key；生产环境应由安全配置源统一分发。
func newTicketKey() ([32]byte, error) {
    var key [32]byte
    if _, err := rand.Read(key[:]); err != nil {
        return key, fmt.Errorf("生成 session ticket key: %w", err)
    }
    return key, nil
}

// rotateTicketKeys 让新票据使用 next，同时保留 previous 解密旧票据。
func rotateTicketKeys(cfg *tls.Config, next, previous [32]byte) {
    // 第一项负责加密新票据，第二项只保留兼容读取能力。
    cfg.SetSessionTicketKeys([][32]byte{next, previous})
}

真实轮换时，把 next 写入密钥服务并得到配置版本，再让实例加载 {next, previous}。等超过你定义的票据兼容窗口后，下一轮只保留新的 key。不要把 key 写进日志，也不要为了“立即生效”重建所有连接；该接口可以在服务运行期间调用。

三、多副本最关键：同一 host 使用同一组 key

同一个域名后面有 Gateway A、Gateway B 时，客户端下一次请求可能落到任意实例。如果 A 用 key-A 生成票据，B 没有 key-A，就会把本来可以恢复的会话当成普通新握手。结果通常表现为恢复率下降、握手耗时升高，而不是一个足够直观的“密钥不同步”错误。

因此发布配置时应先写入共享密钥源，再按同一版本推送全部终止 TLS 的实例。监控上同时看配置版本、TLS 握手错误和 ConnectionState().DidResume；只看总请求成功率很容易漏掉恢复率悄悄下降的问题。

四、旧 key 什么时候可以移除

移除条件应来自票据有效窗口，而不是发布完成时间。至少要覆盖客户端可能持有旧票据的最长时间，再考虑缓存、连接重试和灰度实例的延迟。保守做法是保留两项 ring，确认旧票据恢复量持续降到预期后，再切成单项。若发生泄露，则不要等待窗口自然结束：生成全新的 key、同步所有副本，并接受已有票据失效带来的完整握手峰值。

回滚也要有版本意识。回滚到上一版本配置前，先确认旧 key 仍在安全存储和兼容窗口内；如果已经从 ring 删除，回滚代码也无法恢复旧票据。密钥本身不需要被业务日志打印，记录配置版本、轮换时间、实例确认数和恢复率就足够。

相关问题

调用 SetSessionTicketKeys 后还会自动轮换吗？

不会。官方文档明确说明该调用会关闭自动 session ticket key rotation，之后要由应用重新生成、分发和替换 key ring。

只保留一把 key 可以吗？

可以，但切换瞬间旧票据无法解密，会让客户端重新完成握手。除非这是紧急撤销场景，否则保留短暂的旧 key 通常更平滑。