MySQL SSL加密必须同时满足三条件：服务端have_ssl=YES、用户REQUIRE SSL、客户端显式启用TLS；缺一则静默降级为明文，且需确认编译支持、证书属主为mysql、禁用AppArmor、测试用127.0.0.1而非localhost。
必须手动配置三处：证书生成、服务端加载、用户级强制要求，缺一不可；否则 have_ssl 显示 YES 也仍是明文传输。
确认 MySQL 编译时已启用 SSL 支持
这是最容易跳过的前置检查。Ubuntu 官方源的 mysql-server 包默认带 OpenSSL 支持，但某些 Docker 镜像或自编译版本可能不包含。登录 MySQL 执行：
SHOW VARIABLES LIKE 'have_ssl';
结果必须是 YES。若为 DISABLED 或 NO，再查：
SHOW VARIABLES LIKE 'version_ssl_library';
返回为空或报错，说明未链接加密库。修复方式是重装官方包：
sudo apt install --reinstall mysql-server
注意：只重装 mysql-client 无效。
用 mysql_ssl_rsa_setup 生成证书但必须切换用户运行
这个工具只生成文件，不改配置、不重启、不授权，且对运行身份极其敏感——用 root 跑，生成的 server-key.pem 属主是 root，mysqld 读不了，have_ssl 就仍是 DISABLED。
- 先确认数据目录归属：
ls -ld /var/lib/mysql/，输出中属主应为mysql - 切到
mysql用户执行：sudo -u mysql mysql_ssl_rsa_setup --datadir=/var/lib/mysql - 验证生成结果：
sudo -u mysql ls -l /var/lib/mysql/*.pem，确保server-key.pem权限是-rw-------（600）且属主为mysql - 如果报
Permission denied或日志里有SSL_CTX_set_default_verify_paths failed，大概率是 AppArmor 拦截（Ubuntu 默认启用），临时可运行：sudo aa-disable /usr/sbin/mysqld排查
在 /etc/mysql/mysql.conf.d/mysqld.cnf 中配绝对路径并重启
配置项写错路径、漏掉 [mysqld] 段、或只 reload 不重启，都会导致证书不加载。SSL 配置不支持热加载。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
编辑配置文件，在 [mysqld] 下添加：
require_secure_transport = ON<br>ssl_ca = /var/lib/mysql/ca.pem<br>ssl_cert = /var/lib/mysql/server-cert.pem<br>ssl_key = /var/lib/mysql/server-key.pem
三个路径必须是绝对路径；require_secure_transport = ON 是强制所有 TCP 连接走 SSL 的开关，不加它，用户仍可用 --ssl-mode=DISABLED 绕过。
改完必须重启：
sudo systemctl restart mysql
创建 REQUIRE SSL 用户才能真正加密连接
仅配服务端不设用户 REQUIRE，客户端加 --ssl-mode=REQUIRED 也可能被服务端拒绝——因为服务端没收到强制加密指令。
- 新建用户：
CREATE USER 'app'@'%' IDENTIFIED BY 'pwd' REQUIRE SSL; - 已有用户补加：
ALTER USER 'app'@'%' REQUIRE SSL; - 验证当前连接是否加密：
SELECT Ssl_cipher FROM information_schema.PROCESSLIST WHERE ID = CONNECTION_ID();，返回非空表示已加密 - 注意：
mysql -u root -p默认不启用 SSL；必须显式加--ssl-mode=REQUIRED才会协商加密
真正容易被忽略的是：即使 require_secure_transport = ON 已开启，若用户没设 REQUIRE SSL，该用户仍可通过本地 socket（localhost）绕过 SSL——只有 TCP 连接（如 127.0.0.1）才受此限制。所以测试务必用 127.0.0.1，别用 localhost。
