Navicat 16 不支持 SSL 双向认证（mTLS），无论是否填写 Client Certificate 和 Private Key 字段，均不会在 TLS 握手阶段发送客户端证书；其仅加载证书但不参与 ClientHello 响应，导致服务端启用 require_client_auth 时握手失败，必须升级至 Navicat 17.0.5+ 或改用支持 mTLS 的工具。
navicat 16 不支持 ssl 双向认证（mtls），无论你填不填 client certificate 和 private key 字段，它都不会在 tls 握手阶段发送客户端证书。这不是配置问题，是客户端能力缺失。
为什么 Navicat 16 的「Client Certificate」字段看起来能填
这个字段在 PostgreSQL / MySQL / MongoDB 等连接类型的 SSL 页签里确实存在，但 Navicat 16 仅把它当作“可选附加材料”处理：它会把该证书加载进内存，但不会主动参与 TLS ClientHello 阶段的证书请求响应流程。服务端若配置了 require_client_auth = on（如 PostgreSQL 的 ssl_client_auth = 1 或 MongoDB 的 net.ssl.clientCertificateTLS: true），握手直接失败，报错通常是 SSL handshake failed 或 connection reset by peer。
验证方式很简单：用 openssl s_client -connect host:port -cert client.crt -key client.key 能连通，而 Navicat 16 同样配置却失败——那基本就是客户端不发证。
哪些数据库场景下你以为需要双向认证，其实单向就够了
- PostgreSQL：只要
pg_hba.conf里某条规则第 4 列写的是scram-sha-256或cert，身份认证就由数据库层完成，SSL 层只需加密传输，verify-full+ CA 文件已足够 - MySQL：用户创建时加了
REQUIRE X509才真需要客户端证书；否则REQUIRE SSL只强制通道加密，Navicat 16 完全满足 - MongoDB Atlas：默认不要求客户端证书，填
CA File+ 勾选Use SSL即可；Client Certificate字段留空不影响连接 - OceanBase：社区版 OBProxy 默认不启用客户端证书校验，
force_ssl = true只要求服务端证书有效，Navicat 16 提供ca.pem就行
真要双向认证，必须换工具或升级
如果你的环境硬性要求 mTLS（例如金融级审计、K8s Ingress 强制双向 TLS、自建 Vault 后端），Navicat 16 无法满足：
替代方案有且仅有两个：
— 升级到 Navicat 17.0.5+：官方文档明确标注其支持 TLS 1.2+ 和 ECDSA，并在 OceanBase / Redis 连接中验证过客户端证书提交行为（注意：仍需确认具体数据库类型是否启用该路径）
— 改用命令行或 IDE：比如 psql 加 -c "sslmode=verify-full sslcert=client.crt sslkey=client.key"，或 DataGrip 配置 TLS 选项时勾选 “Two-way SSL authentication”
最常被忽略的一点：即使你凑齐了 CA、client.crt、client.key 三个文件，只要服务端没在 TLS 层明确要求客户端证书（即未触发 CertificateRequest 消息），填了也是白填。先用 openssl s_client -connect ... -debug 抓握手日志看服务端有没有发 CertificateRequest，再决定要不要折腾客户端。
