必须用net.tls.clusterFile指定节点证书，因certificateKeyFile仅用于对外客户端连接，不参与副本集内部身份校验；clusterFile专供成员间X.509认证，要求O/OU/DC属性严格一致且不能复用同一文件。
必须用 net.tls.clusterFile 指定节点证书，且所有副本集成员的证书中 O/OU/DC 属性必须完全一致，否则集群无法完成初始化或选举。
为什么 net.tls.certificateKeyFile 不够用？
该参数只用于对外 TLS 握手（比如客户端连接），不参与集群内部成员身份校验。X.509 内部认证依赖的是独立的 net.tls.clusterFile —— 它必须是专为集群成员身份签发的证书（含私钥）PEM 文件，且不能与 certificateKeyFile 复用同一文件。
- 若复用，启动时会报错：
cluster certificate must not be the same as the server certificate - 证书 subject 中至少一个属性（
O、OU或DC）必须非空，且所有节点值严格相等（大小写敏感） - 如需自定义匹配字段，可用
net.tls.clusterAuthX509.attributes显式声明，例如：O=MongoDB,OU=ReplicaSet
如何配置 clusterAuthMode 并滚动启用？
不能直接设为 x509 启动，否则旧节点拒绝加入。必须分两步滚动升级：
- 第一步：所有节点先设
security.clusterAuthMode: sendKeyFile，并添加net.tls.clusterFile路径，重启；此时节点仍用密钥文件互相认证，但已准备好接收 X.509 - 第二步：逐个连接到每个
mongod，执行：db.adminCommand({ setParameter: 1, clusterAuthMode: "sendX509" }) - 注意：该命令仅运行一次即生效，无需重启；但必须确保所有节点都执行完，否则部分节点会因认证失败被踢出集群
常见连接失败原因和验证点
即使配置正确，也会因以下细节卡住：
- CA 文件不匹配：
net.tls.CAFile必须能验证clusterFile证书链，否则日志出现unable to verify certificate chain - 证书过期：MongoDB 不检查有效期，但 OpenSSL 层会拒绝，表现为
SSL handshake failed - 主机名不匹配：虽然内部认证不校验 CN/SAN，但 TLS 握手阶段仍会校验；确保
net.tls.clusterFile的 SAN 包含节点实际通信 IP 或 DNS 名 - 权限问题：
mongod进程用户必须有读取clusterFile的权限，否则启动日志里只有模糊的failed to load cluster certificate
最易被忽略的是属性值的空格和大小写 —— O=MyOrg 和 O=myorg 被视为不同组织，会导致节点间握手成功但认证失败，错误日志里不会直接提示，只能靠 rs.status() 查看成员状态是否为 HEALTHY，以及 db.setLogLevel(1, "network") 开启网络调试日志定位。
