MongoDB 5.0支持服务端不重启轮换证书，但客户端必须主动重建连接池；执行rotateCertificates前需确认新证书文件就位且路径权限正确、用户具clusterAdmin权限、日志显示成功重载TLS配置。
MongoDB 5.0 原生支持不重启服务的证书轮换，但仅限服务端（mongod/mongos），客户端仍需主动重建连接，否则新证书对应用无效。
执行 rotateCertificates 命令前必须确认的三件事
这个命令只更新服务端 TLS 上下文，不触碰任何已有连接，也不影响客户端行为：
- 确保新证书文件已就位，且路径、文件名与配置文件中
ssl.CAFile、ssl.PEMKeyFile指向的完全一致——改名或权限不对都会静默失败 - 用
mongosh连到目标实例（不是 mongos 路由器，而是具体要轮换的mongod或mongos进程），且该用户有clusterAdmin权限 - 检查日志是否含
"rotateCertificates: successfully reloaded TLS configuration"；若只有"command rotateCertificates started"却无成功记录，大概率是证书文件读取失败（比如 SELinux 拦截或 umask 导致不可读）
为什么 rotateCertificates 后应用仍报 TLS 错误
因为客户端（如 Node.js 的 MongoClient、Python 的 PyMongo）不会感知服务端证书变更。旧连接继续用原证书通信，新连接可能因服务端已加载新证书而握手失败——这不是命令没生效，而是客户端没配合：
- Node.js 驱动必须调用
client.close()并 await 完成，再用相同 URI + 显式tlsCAFile/tlsCertificateKeyFile创建新实例 - PyMongo 中
client.close()不阻塞运行中操作，建议搭配maxIdleTimeMS: 1000和minPoolSize: 0加速旧连接释放 - 若用了连接池代理（如 HAProxy、mongos），需单独对其执行证书轮换或重启，否则它可能缓存旧 TLS 握手结果
验证轮换是否真正生效的两个硬指标
别信日志里的 “connected”，要看实际 socket 层是否用了新证书：
- 在客户端机器执行：
openssl s_client -connect your-mongo-host:27017 -tls1_2 -showcerts -cert /path/to/your/client.pem -key /path/to/your/client-key.pem 2>/dev/null | openssl x509 -noout -dates，确认输出的notAfter是新有效期 - 抓包验证：用
tshark -i any -Y 'tls.handshake.certificate && ip.addr==your-mongo-ip' -T fields -e tls.handshake.certificate提取证书指纹，和新证书openssl x509 -in new.pem -fingerprint -noout对比
最容易被忽略的是：Atlas 用户根本不需要手动跑 rotateCertificates，它由平台自动完成；而自托管集群里，哪怕服务端轮换成功，只要有一个客户端进程没重建连接池，就存在混合使用新旧证书的风险——这问题不会立刻暴露，往往在旧证书彻底过期后才集中爆发。
