KES 开启 SSL 前，证书、端口和客户端要一起验

SSL 不是把 ssl 参数改成 on 就结束。服务端能启动、客户端能连、证书能验证、认证规则能正确匹配，四件事必须同时成立。任何一环遗漏，都可能出现"管理工具能连，应用全断"或"看似加密，客户端其实没有验证服务端"的情况。

上线前先盘点所有连接方：应用连接池、Ksql、备份工具、监控、数据同步、运维脚本和高可用组件。每一类记录驱动版本、连接参数、证书路径、运行账号和重连方式，不要只拿一个管理员客户端代表全系统。

--- 证书、服务端、认证规则和客户端必须作为一条链路验收。

核对签发机构、有效期、服务端名称、用途和私钥权限。证书文件可以被读取不代表配置正确；私钥权限过宽会增加泄露风险，权限过严又可能让数据库进程无法启动。证书更新脚本还要确认不会在替换过程中留下半套文件。

测试环境使用与生产相同的域名和访问路径。若生产客户端通过 VIP 或域名连接，而证书只覆盖单机名称，严格校验时会失败。不能为了快速恢复就永久降低验证级别，应回到证书名称和连接地址解决根因。

KES 的 sys_hba.conf 按"先匹配先执行"工作，一旦选中一条记录且认证失败，不会继续尝试后面的规则。hostssl 只匹配使用 SSL 的 TCP/IP 连接，若服务端没有正确启用 SSL，对应记录可能被忽略并产生告警。

因此变更前导出当前规则，标记哪些客户端会先命中哪一行。新增规则不要直接放一个过宽的 all 在最前面，也不要误把运维应急入口遮住。修改后按当前版本要求重载或重启，并从每个来源地址实际连接。

text 复制代码

# 结构示例，数据库、用户、网段和认证方式应按现场设计
hostssl  appdb  app_user  198.51.100.0/24  <auth-method>

示例不提供可直接复制的认证方式，是因为口令、证书或强认证方案必须结合安全要求确定。照搬一行配置，最容易忽略规则顺序与客户端能力。

分别验证启用 SSL、要求校验证书、使用错误 CA、使用错误主机名和证书过期等场景。正确配置应允许合法连接，并拒绝错误信任链或不匹配身份。只测试成功路径，无法证明验证没有被关闭。

应用连接池需要观察重连、连接预热和故障切换。证书切换时旧连接可能继续工作，新连接才开始失败，短时间"业务正常"不代表变更成功。主动建立新连接并逐步增加流量更可靠。

--- 每类客户端都要做成功与失败两组验证。

回滚方案要包含旧证书备份、原认证文件、配置恢复命令、重载或重启步骤以及连接验证。证书私钥属于敏感材料，备份和回滚包不能放在公共共享目录，也不要写进文章、工单截图或脚本输出。

上线后监控握手失败、证书到期天数、连接错误和重连次数。至少提前一个维护周期预警到期，完成更新演练，避免在证书失效当天临时处理。

SSL 的验收标准不是参数为 on，而是合法客户端经过正确验证后稳定连接，非法或错误证书连接被拒绝，并且更新与回滚都有可执行路径。

还要检查性能与超时边界。握手会增加新建连接阶段的工作量，长连接通常影响较小，短连接或突发重连更容易放大。通过接近真实的并发建立连接，观察连接耗时、CPU 和失败率，不要只测单次 Ksql 登录。

若前面存在负载均衡或代理，确认 SSL 在哪一层终止、后半段是否仍加密、证书由谁管理。客户端看到代理证书时，数据库节点证书的轮换流程可能完全不同。架构图中应明确每一段信任关系，避免团队都以为另一层已经负责。

上线清单还应包含证书到期告警和轮换演练，避免第一次更换证书就发生在生产到期当天。