ssl握手失败根源在服务端未启用ssl，而非navicat配置错误；须先验证服务端have_ssl（mysql）、openssl配置（clickhouse）或ssl=on（postgresql）是否启用，再确保证书路径为本地绝对路径、无空格中文、权限正确，并按ssl mode要求匹配ca证书与主机名。
ssl握手失败是服务端没开ssl，不是navicat配错了
绝大多数“ssl handshake failed”错误，根源在服务端——navicat只是个被动接收方，它无法凭空建立加密通道。先别动客户端配置，直接登录数据库服务器查两件事：have_ssl（mysql）或openssl配置块（clickhouse）是否启用，以及对应证书文件路径是否存在、权限是否正确（如/etc/clickhouse-server/server.crt需clickhouse用户可读）。
快速验证服务端状态：
- MySQL：运行
mysql -u root -p -e"show variables like 'have_ssl';"，返回DISABLED或NO就得先配服务端 - ClickHouse：执行
clickhouse-client --ssl-mode=strict --host=127.0.0.1 --port=9440，能连通说明服务端 SSL 已就绪 - PostgreSQL/SQL Server：检查
postgresql.conf中ssl = on及证书路径，或 SQL Server 的“加密连接”设置是否启用
Navicat填了证书路径却仍失败，大概率是路径不合法
Navicat所有版本（Windows/macOS/iOS）只认本地绝对路径，且对路径字符极其敏感。网络路径（\servercertsca.pem）、iCloud/OneDrive同步目录、含空格或中文的路径（C:My Certsca.pem）、符号链接、波浪号（~/certs/ca.pem）全部无效——它会静默忽略，然后降级为明文连接或报错。
必须满足以下全部条件：
- 证书文件（如
ca.pem）已复制到本地固定目录，例如C:/navicat-certs/mysql-prod-ca.pem（Windows）或/Users/you/navicat-certs/pg-staging.crt（macOS） - 路径中不含空格、括号、中文、特殊符号
- Navicat 连接设置里填的是完整绝对路径，不是相对路径或 UNC 路径
- 多人共用机器时，每人用独立子目录（如
C:/navicat-certs/user1-mysql），避免混用 CA 导致certificate verify failed
SSL Mode选错会导致握手直接中断，不是连不上而是验不过
Navicat 的 SSL Mode 下拉选项决定校验强度，选错会立刻失败，而非超时或密码错：
-
Require：只要求加密，不校验证书——适合内网自签名环境，但无防中间人能力 -
Verify-CA：必须填SSL CA File（即服务端的根证书ca.pem），只校验签名链是否可信 -
Verify-Full：除Verify-CA外，还强制要求 Navicat 连接设置里的Host字段与证书中Subject CN或Subject Alternative Name完全一致（比如填db01.prod.example.com，证书里就得有这个域名）
常见陷阱：Verify-Full 模式下 Host 填 IP 地址（如 10.0.1.5）但证书没包含该 IP 的 SAN，就会卡在握手；此时要么改 Host 为域名，要么重签证书加 SAN。
连接显示“Connected”但实际没走SSL，得靠命令或抓包确认
Navicat 界面显示成功不代表数据真加密。MySQL 可能因服务端配置不全（如只配了 ssl_cert 没配 ssl_key）而静默回退到明文；ClickHouse 若 config.xml 中 verificationMode 设为 none，也会跳过校验。
验证真实加密状态：
- MySQL：连接后执行
SELECT Ssl_cipher FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_USER = 'your_user';，结果为空说明未走 SSL - 通用方法：用
tcpdump -i lo port 3306（本地）或tshark -f "host your-db-ip and port 9440"抓包，若能看到明文 SQL（如SELECT * FROM users），说明加密未生效 - ClickHouse：查
system.settings中use_secure_protocol是否为 1，或看system.processes的is_secure列
真正麻烦的点不在填哪几个字段，而在于服务端证书链是否完整、CN/SAN 是否匹配、Navicat 是否真的读到了那个文件——三者缺一不可。路径写错一个斜杠，或者证书更新后没手动替换本地文件，都会让整个链路失效。
