MySQL主从复制默认明文传输，存在中间人攻击风险；必须主库启用SSL并设require_secure_transport=ON，从库CHANGE REPLICATION SOURCE TO时须完整指定SOURCE_SSL_CA、SOURCE_SSL_CERT、SOURCE_SSL_KEY等参数，且证书角色、路径、权限须严格匹配。
主从复制默认明文传输，不配 SSL 就等于把 binlog、密码、SQL 全裸发到网络上——中间人攻击不是假设，是必然可复现的风险。
主库必须启用 SSL 且 require_secure_transport=ON 才算真正生效
只在 my.cnf 里配了 ssl_ca、ssl_cert、ssl_key 不够，MySQL 仍会接受未加密连接。必须显式开启强制安全传输：
-
SET PERSIST require_secure_transport = ON;（推荐，持久化生效） - 或在配置文件中加
require_secure_transport=ON并重启 mysqld - 验证是否生效：
SHOW VARIABLES LIKE 'require_secure_transport';返回ON - 若从库没配 SSL 就执行
CHANGE REPLICATION SOURCE TO，会直接报错Authentication requires secure connection，而不是静默降级
从库 CHANGE REPLICATION SOURCE TO 必须传全 SSL 参数
漏掉任意一个 SSL 参数，MySQL 就会回退到明文连接，且 SHOW REPLICA STATUS\G 里 Master_SSL_Allowed: No 却不报错——这是最常被忽略的坑。
- 必须带：
SOURCE_SSL=1、SOURCE_SSL_CA='/etc/mysql/ca.pem'（必需） - 推荐加：
SOURCE_SSL_CERT='/etc/mysql/client-cert.pem'、SOURCE_SSL_KEY='/etc/mysql/client-key.pem'（用于双向认证） - 路径是**从库本地路径**，MySQL 进程需有读权限；SELinux 或 AppArmor 可能拦截，用
ausearch -m avc -ts recent查日志 - CA 文件必须和主库的
ssl_ca完全一致，否则握手失败：错误信息是SSL error: certificate verify failed
caching_sha2_password 插件要求 SSL 是硬性前提
MySQL 8.0+ 默认认证插件是 caching_sha2_password，它在主从复制场景下会主动拒绝非 SSL 连接，错误码 MY-002061 就是这个原因。
- 不要回退到
mysql_native_password——那是降级安全性的临时补丁，不是解法 - 真正解决路径只有一条：主库开 SSL +
require_secure_transport=ON，从库连时带全 SSL 参数 - 复制账号不能用 root 或高权限用户，最小权限应为：
REPLICATION SLAVE，禁止REPLICATION CLIENT（除非真要查主库 binlog 状态）
证书不能复用，CA 必须统一且私钥严格隔离
用同一套自签证书同时当主库 server-cert 和从库 client-cert，会导致证书用途冲突，SSL 握手失败或验证绕过。
- 主库只需提供服务端证书：
ssl_cert+ssl_key+ssl_ca（用于验从库） - 从库只需提供客户端证书：
SOURCE_SSL_CERT+SOURCE_SSL_KEY（双向时），以及必填的SOURCE_SSL_CA（用于验主库） - CA 私钥（
ca-key.pem）必须离线保管，绝不能放到任何 MySQL 服务器上 - 证书有效期建议设为 3–5 年，但必须监控到期时间，
openssl x509 -in ca.pem -noout -dates可查
SSL 配置真正的难点不在生成证书，而在于主从双方对证书角色、路径、权限、参数组合的严格匹配——少一个参数、错一个路径、混用一次私钥，就等于没加锁。
