MongoDB 不提供强制 TLS 1.3 的配置项，因其 TLS 版本协商由底层系统库（如 OpenSSL）控制，服务器仅响应客户端提议的最高兼容版本；真正限制需在操作系统或 OpenSSL 配置中设置 MinProtocol = TLSv1.3。
MongoDB 本身不提供直接强制客户端仅使用 TLS 1.3 的配置项。它只支持“启用 TLS”和“禁用旧版本”，而 TLS 版本协商由底层系统 TLS 库（如 OpenSSL、Schannel、Security Framework）控制，MongoDB 不参与或干预协议版本选择过程。
为什么 MongoDB 没有 tlsVersion: "1.3" 这类配置
MongoDB 的 net.tls 配置块（如 net.tls.mode、net.tls.certificateKeyFile）只负责启用加密和加载证书，不暴露 TLS 协议版本控制接口。TLS 版本协商发生在 TCP 连接建立后的握手阶段，由驱动程序和操作系统 TLS 栈完成 —— MongoDB Server 只响应客户端提议的最高兼容版本。
- 如果你的服务器运行在 OpenSSL 1.1.1+ 或更新系统上，且客户端也支持 TLS 1.3，它们大概率会协商出 TLS 1.3
- 但只要客户端主动降级（比如显式指定
--tlsDisabledProtocols TLS1_1,TLS1_2以外的选项），或服务端 OpenSSL 配置允许更低版本，协商仍可能回落到 TLS 1.2 - MongoDB 从不主动拒绝 TLS 1.2 握手，即使你已升级到 MongoDB 8.0+
真正能限制 TLS 1.3 的地方：操作系统与 OpenSSL 配置
要实际达成“仅 TLS 1.3”，必须在 MongoDB 进程所依赖的 TLS 库层面设限，而非 MongoDB 配置文件中：
- Linux 上：修改 OpenSSL 配置（如
/etc/ssl/openssl.cnf），在[system_default_sect]中设置MinProtocol = TLSv1.3 - 确保 MongoDB 启动时加载的是这个 OpenSSL 配置（可通过
LD_LIBRARY_PATH和OPENSSL_CONF环境变量确认） - 验证生效：启动 mongod 后用
openssl s_client -connect localhost:27017 -tls1_2测试 —— 若返回handshake failed，说明 TLS 1.2 已被系统层拦截
注意：MinProtocol = TLSv1.3 对 OpenSSL 3.0+ 有效；OpenSSL 1.1.1 要求补丁或使用 SSL_CTX_set_min_proto_version() 编译定制版 mongod。
客户端侧无法绕过服务端限制的常见误操作
有些用户试图在连接字符串里加 &tlsDisabledProtocols=TLS1_1,TLS1_2 或类似参数，这无效：
-
tlsDisabledProtocols是 MongoDB Server 的配置项，**只影响 Server 发起的出站连接**（如副本集心跳、shard config server 通信），不影响入站客户端连接 - 客户端驱动（如 Node.js 的
mongodb包、Python 的pymongo）也没有公开 API 强制指定“只用 TLS 1.3” —— 它们依赖各自运行时的 TLS 栈（如 Node.js 的 OpenSSL 绑定） - mongosh 的
--tlsDisabledProtocols也仅控制 mongosh 自身行为，不能倒逼服务器拒绝低版本
真正起效的路径只有一条：让操作系统 TLS 栈拒绝低于 TLS 1.3 的握手。MongoDB 配置文件里写再多 tls: true 或 tlsMode: requireTLS，都只是打开加密大门，不负责检查进门的人穿哪代盔甲。
