mysql ssl加密连接必须同时满足三个条件：服务端have_ssl=yes、用户权限含require ssl、客户端真实完成tls握手，缺一不可，否则静默降级为明文。
MySQL SSL 加密连接不是“配了证书就自动生效”，必须同时满足三个硬性条件：服务端 have_ssl = YES、用户权限含 REQUIRE SSL、客户端连接时真实完成 TLS 握手。漏掉任意一环，连接都会静默降级为明文——你根本不会收到报错，但数据已在裸奔。
确认 MySQL 是否真正加载了 SSL 支持
很多问题卡在这一步：配置写了、证书放了、服务也重启了，SHOW VARIABLES LIKE 'have_ssl' 却返回 DISABLED 或空值。这说明 mysqld 启动时压根没加载 OpenSSL 模块。
- 执行
SHOW VARIABLES LIKE 'have_ssl'，必须是YES；若为DISABLED，常见于 MariaDB 精简版或编译时未加-DWITH_SSL=system - 顺带查
SHOW VARIABLES LIKE 'ssl_ca'、ssl_cert、ssl_key—— 三者都必须返回非空的绝对路径，且对应文件真实存在 - 如果
have_ssl是DISABLED，重装官方二进制包比自行编译修复更稳妥
生成并放置证书：路径、格式、权限三者缺一不可
MySQL 对证书极其挑剔：只认绝对路径、只读 PEM 格式、私钥权限必须为 600。相对路径、~/、权限 >600 的私钥都会导致启动失败或连接被拒。
- 优先用内置工具生成（MySQL 5.7.6+）：
mysql_ssl_rsa_setup --datadir=/var/lib/mysql --uid=mysql，它自动处理subjectAltName，避免X509_V_ERR_IP_ADDRESS_MISMATCH - 证书必须放在 MySQL 进程有读权限的目录，例如
/var/lib/mysql/ca.pem，不能放/root/或/home/deploy/ - 立刻修正权限：
chown mysql:mysql /var/lib/mysql/*.pem && chmod 600 /var/lib/mysql/server-key.pem—— MySQL 拒绝读取组/其他可读的私钥
配置 my.cnf 并强制启用 require_secure_transport
require_secure_transport = ON 不是可选优化项，而是生产环境的底线配置。它拒绝所有非 SSL 连接，比只设 ssl=ON 或仅依赖用户权限更可靠。
- 编辑
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，只在[mysqld]段添加：ssl_ca = /var/lib/mysql/ca.pem ssl_cert = /var/lib/mysql/server-cert.pem ssl_key = /var/lib/mysql/server-key.pem require_secure_transport = ON
- 路径必须是绝对路径，不能用
~/或相对路径；不要写在[client]段——那是客户端配置，对服务端无效 - 改完必须
systemctl restart mysqld（不是reload），SSL 配置不支持热加载 - 重启后立刻检查错误日志：
tail -n 50 /var/log/mysqld.log | grep -i ssl，出现Failed to set up SSL就说明证书或权限有问题
验证当前连接是否真走 SSL，而不是“看起来配了”
SHOW VARIABLES 只告诉你“配了什么”，STATUS（或 \s）才反映当前连接实际状态。即使服务端开了 SSL、用户设了 REQUIRE SSL，客户端不显式要求，连接仍走明文。
- 创建用户时加
REQUIRE SSL：CREATE USER 'appuser'@'10.0.2.%' IDENTIFIED BY 'p4ssw0rd' REQUIRE SSL - 命令行连接必须加参数：
mysql -u appuser -p --ssl-mode=REQUIRED（MySQL 8.0+ 推荐） - 连接后立即执行
STATUS或SHOW STATUS LIKE 'Ssl_cipher'—— 返回非空值（如ECDHE-ECDSA-AES256-SHA）才表示当前连接确实在用 TLS
最容易被忽略的点是：服务端证书配置正确、用户权限也设了 REQUIRE SSL，但客户端连接时没传 --ssl-mode=REQUIRED，或者应用代码里只设了 ssl=True 而没提供 ca 文件——这种连接虽加密，却不校验服务端身份，防不住中间人攻击。
