mysql ssl连接需同时满足have_ssl=yes、证书路径权限格式正确、require_secure_transport=on三条件，否则静默降级明文；验证须查ssl_cipher非空而非仅看配置。
MySQL SSL 不是配完证书就自动加密的——漏掉任一硬性条件，连接都会静默降级为明文。
确认 have_ssl = YES 是第一道生死线
很多配置看似完整，但连接仍是明文，根本卡在这一步：MySQL 启动时压根没加载 SSL 模块。执行 SHOW VARIABLES LIKE 'have_ssl';，返回值必须是 YES；若为 DISABLED 或空，后续所有操作都无效。
常见原因包括：server-key.pem 权限不是 600、私钥被加密过、my.cnf 里证书路径写错、OpenSSL 库缺失（尤其 Alpine 镜像）、或 MySQL 编译时未启用 SSL 支持（如 MariaDB 精简版）。此时重装官方二进制包比自行编译更稳妥。
证书路径、权限、格式三者必须同时满足
MySQL 对证书极其挑剔：只认绝对路径、只读 PEM 格式、且严格校验文件权限。相对路径、~/、权限 >600 的私钥都会导致启动失败或连接拒绝。
- 用
mysql_ssl_rsa_setup --datadir=/var/lib/mysql --uid=mysql生成（MySQL 8.0+ 推荐），它自动处理 CN、subjectAltName、权限等细节 - 证书必须放在 MySQL 进程有读权限的目录，例如
/var/lib/mysql/ca.pem，不能放/root/或用户家目录下 - 检查权限：
sudo -u mysql ls -l /var/lib/mysql/server-key.pem，必须是-rw-------（即 600） - 若服务需通过
127.0.0.1和db.example.com访问，server-cert.pem的subjectAltName必须显式包含这两项
require_secure_transport = ON 是强制开关，不是可选项
仅在 [mysqld] 段配置 ssl_ca、ssl_cert、ssl_key 不等于启用加密——客户端仍可走明文连接。必须加 require_secure_transport = ON 才真正拒绝非 SSL 连接。
配置示例：
[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
改完必须重启 mysqld（不是 reload）；路径必须是绝对路径；MySQL 用户必须能读取这些文件。
验证当前连接是否真加密，而不是只看配置
SHOW VARIABLES LIKE '%ssl%' 只告诉你“配了啥”，不是“连上了啥”。关键要看当前连接是否加密：
登录后执行：mysql -u root -p -e "SHOW VARIABLES LIKE 'have_ssl'; SHOW STATUS LIKE 'Ssl_version'; SELECT * FROM performance_schema.status_by_thread WHERE VARIABLE_NAME = 'Ssl_cipher';"
理想输出：have_ssl = YES、Ssl_version 非空（如 TLSv1.3）、当前连接的 Ssl_cipher 字段非空（如 ECDHE-ECDSA-AES128-GCM-SHA256）。
如果 Ssl_cipher 为空，说明你连的是明文连接——试试加参数重连：mysql -u root -p --ssl-mode=REQUIRED。注意：REQUIRE SSL 用户权限只在服务端 SSL 已启用的前提下才起作用，否则只会报权限错误，实际是握手失败。
最易被忽略的是：证书路径写在 [client] 段而非 [mysqld] 段，服务端根本读不到；SELinux/AppArmor 阻止 mysqld 访问证书目录，日志里只有 Permission denied 却不反映在变量中；还有 TLS 版本不匹配（如客户端只支持 TLSv1.2，而服务端只启用了 TLSv1.3）。
