MySQL未启用SSL导致Navicat连接失败；需先检查have_ssl是否为DISABLED/NO，再配置my.cnf中ssl_ca、ssl_cert、ssl_key路径及权限，重启后验证Ssl_version非空；Navicat仅需填SSL CA File（ca.pem），其余按需填写；连接后须查Ssl_cipher或抓包确认是否真加密；自签名证书需确保CN与连接主机名一致，且开启require_secure_transport防止降级。
MySQL服务端没开SSL，Navicat连不上加密通道
navicat里勾选了“使用ssl”却报 ssl connection error 或 unknown ssl error，大概率不是navicat配错了，而是mysql压根没启用ssl支持。先确认服务端状态：
mysql -u root -p -e "show variables like 'have_ssl';"返回
disabled 或 no 就得先配mysql本身。
- Linux下检查证书路径是否在
my.cnf里正确配置：ssl_ca、ssl_cert、ssl_key必须指向可读的PEM文件，且权限不能是777（MySQL会拒绝加载） - Windows下路径用正斜杠或双反斜杠，比如
C:/mysql/ssl/ca.pem，单反斜杠C:\mysql\ssl\ca.pem会导致启动失败 - 重启MySQL后执行
SHOW STATUS LIKE 'Ssl%';，看到Ssl_version非空才说明真启用了
Navicat里SSL设置项填什么才有效
Navicat连接窗口的“SSL”页签里，4个字段不是全都要填：只有当MySQL配置了require_secure_transport=ON或用户被显式授予 REQUIRE X509 时，才需要客户端提供证书；否则只填CA证书就足够验证服务端身份。
-
SSL CA File：必填，填MySQL服务端的ca.pem，用于校验服务器证书合法性 -
SSL Cert File和SSL Key File：仅当MySQL用户创建时指定了REQUIRE CERTIFICATE才需提供，普通加密传输不需要 -
SSL Cipher留空即可，Navicat会自动协商；填了错误值（如AES256-SHA）反而可能握手失败
连接成功但数据没走加密？检查实际协议版本
即使Navicat显示“Connected”，也可能降级到了非SSL连接——尤其当服务端SSL配置不完整（比如只有 ssl_cert 没配 ssl_key）时，MySQL会静默回退到未加密模式。
- 登录MySQL后执行：
SELECT Ssl_cipher FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_USER = 'your_user';，结果为空说明没走SSL - 抓包验证更直接：用
tcpdump -i lo port 3306抓本地连接，如果能看到明文SQL（如SELECT * FROM users），那肯定没加密 - Navicat连接日志里搜
SSL: Cipher，有具体算法名（如ECDHE-RSA-AES128-GCM-SHA256）才算真正生效
自签名证书被Navicat拒绝：跳过验证不可取
用openssl自己生成的CA和服务器证书，Navicat常报 SSL certificate validation failed。这不是证书无效，而是Navicat默认严格校验主机名和证书链完整性。
- 别勾选“Skip certificate validation”——这等于关掉加密意义，只是让连接通过而已
- 确保生成服务器证书时
-subj "/CN=your-mysql-hostname"中的CN和Navicat连接时填的主机名完全一致（包括localhost vs 127.0.0.1） - 如果MySQL跑在Docker里，宿主机Navicat连的是
localhost，但容器内MySQL看到的客户端IP是网桥地址，此时CN必须设为localhost，且MySQL配置中bind-address不能是127.0.0.1（得是0.0.0.0或具体网桥IP）
实际部署时最容易漏掉的是MySQL服务端的 require_secure_transport 全局变量——不打开它，任何客户端都能绕过SSL直连，前面所有配置都形同虚设。
