解读

面试官想确认两点：

1. 你是否理解 Cloud SQL 的 TLS 证书生命周期（默认 90 天，可提前 7 天轮换）；
2. 当 Google 在后台完成 服务器证书轮换 时，正在运行的业务连接会不会断、会不会报错、要不要改代码。
   国内金融、政企客户对“零中断”极度敏感，答不出细节会直接扣分。

知识点

1. 证书轮换是“服务端单向更新”：私钥、公钥、证书链全部在 Google 侧完成，用户侧无需提交 CSR。
2. 已有 SSL 连接使用“会话密钥”，与证书解耦；只要客户端未强制校验服务器证书指纹，连接不会瞬间断开。
3. 客户端校验策略决定影响面：
   • 用 Cloud SQL Auth Proxy（默认校验 CA 根证书，不校验叶子证书指纹）→ 无感知。
   • 用 mysql/psql 自带 SSL 模式 且 未配置 sslmode=verify-full → 无感知。
   • 在代码或 Terraform 里 硬编码 server-ca.pem 指纹（极少见）→ 下次建连会报 certificate verify failed，必须 重新下载 server-ca.pem 并滚动重启应用。
4. 连接池行为：长连接在证书轮换后仍可用，但 池子刷新、故障转移、节点重启 时会重新握手；若客户端缓存了旧 CA，会触发 握手失败。
5. 国内合规场景：部分等保三级要求 双因子+证书白名单，此时必须在轮换窗口内 同步更新堡垒机或 API 网关的证书指纹，否则合规扫描会报警。

答案

服务器证书轮换对已有连接的影响取决于客户端的校验方式：

• 若应用通过 Cloud SQL Auth Proxy 或仅启用 sslmode=require 级别，连接保持不断，业务零中断；
• 若应用显式启用 verify-full 并把 server-ca.pem 写死到容器镜像或配置中心，则新建连接会报证书校验失败，需要在 7 天轮换窗口内 下载新 CA 证书并 滚动发布应用；
• 长连接本身不会瞬间断开，但连接池在故障转移或重启节点时会重新握手，此时若仍使用旧 CA 就会触发报错。
  总结：只要不把叶子证书指纹硬编码，国内业务可以做到用户无感知的平滑轮换。

拓展思考

1. 如何在国内 混合云 场景下，把 Cloud SQL 证书轮换 与 自建 KMS 的私有 CA 打通？
   答：可启用 Private Service Connect + 自建 CA 签发客户端证书，但服务器证书仍由 Google 轮换，需通过 CSR 自动下载+Ansible 推送到边缘节点 实现同步。
2. 如果业务要求 0 丢包，能否在证书轮换窗口内 强制复用旧证书？
   答：不能。Google 侧无 API 可推迟轮换，但可提前 7 天手动轮换（gcloud sql ssl server-ca-certs rotate），自选低峰时刻，把影响降到最低。
3. 国内监管要求 证书有效期≤90 天，Cloud SQL 默认已满足，但如何向审计部门证明？
   答：在 Cloud Asset Inventory 中导出 sqladmin.googleapis.com/Instance 资源，用 serverCaCert.validDurationTime 字段做 周期性合规扫描，结果直接对接 国密测评报告。