必须强制启用SSL并验证证书链，否则中间人攻击必然发生；需确认have_ssl=YES、ssl_ca/cert/key路径有效且同CA签发、require_secure_transport=ON，并在客户端使用VERIFY_IDENTITY模式校验证书。
MySQL 防中间人攻击，**只配证书不强制加密连接，等于没防**。SSL 配置生效的硬性前提是服务端开启 require_secure_transport=ON，且客户端必须校验证书——否则连接默认走明文，攻击者可直接抓包解密凭证与数据。
如何确认 MySQL 服务端真正启用了 SSL 加密
很多环境看似配了证书，实际仍接受明文连接，根本原因是未满足启动前提。
-
SHOW VARIABLES LIKE 'have_ssl';必须返回YES；若为DISABLED或NO，说明 MySQL 编译时未链接 OpenSSL，改配置无效 -
SHOW VARIABLES LIKE 'ssl%';检查ssl_ca、ssl_cert、ssl_key是否指向真实存在的绝对路径，三者必须由同一 CA 签发（不能复用主库 cert 当从库 client-cert） -
SHOW VARIABLES LIKE 'require_secure_transport';必须为ON；只配证书不设此项，客户端仍可明文连接 - 查错误日志（
log_error指向的文件），搜索SSL或error，常见报错如Failed to set up SSL because of SSL library error，多因私钥权限不对（应为600，属主为mysql用户）或 SELinux/AppArmor 拦截
主从复制场景下 SSL 配置最容易漏掉的关键项
主从之间不加密，binlog、复制账号密码、SQL 全裸发到网络上——这不是风险，是必然可复现的中间人攻击面。
- 主库必须设
require_secure_transport = ON（推荐用SET PERSIST持久化），否则从库即使配了 SSL 参数也会被降级接受明文 - 从库执行
CHANGE REPLICATION SOURCE TO时，SOURCE_SSL=1和SOURCE_SSL_CA是硬性必需项；漏掉SOURCE_SSL_CERT或SOURCE_SSL_KEY不报错，但握手失败，实际走明文 -
SOURCE_SSL_CA路径是**从库本地路径**，MySQL 进程用户（如mysql）必须有读权限；SELinux 可能拦截，用ausearch -m avc -ts recent查拒接日志 -
SHOW REPLICA STATUS\G中Master_SSL_Allowed: No就是已降级的明确信号，但 MySQL 不主动报错——这是最常被忽略的坑
客户端连接时如何真正强制加密并校验身份
服务端开了 SSL，客户端不显式要求，连接默认仍是明文。光加 --ssl-mode=REQUIRED 不够，它只保证加密，不校验证书。
- 必须用
--ssl-mode=VERIFY_IDENTITY（MySQL 8.0+）或--ssl-verify-server-cert（旧版），否则无法防中间人 - MySQL 8.0+ 默认认证插件
caching_sha2_password会主动拒绝非 SSL 连接，报错MY-002061，不是密码错，是连接未加密被拒 - 应用连接字符串中需显式指定证书路径，例如 JDBC：
?useSSL=true&serverSslCert=/path/to/ca.pem&trustCertificateKeyStoreUrl=file:///path/to/truststore.jks - 不要回退到
mysql_native_password来绕过 SSL 要求——那是降级安全性，不是解法
为什么自签名证书在生产环境容易出问题
自签证书本身不构成安全短板，但使用方式极易引入漏洞。
- CA 文件必须和主库的
ssl_ca完全一致，否则握手失败，错误信息是SSL error: certificate verify failed - 证书用途必须匹配：主库用
serverAuth，从库 client-cert 必须含clientAuth扩展，否则双向认证失败 - 时间戳必须有效：证书过期、系统时间偏差 >5 分钟都会导致验证失败
- 证书链不完整（比如漏了 intermediate CA）也会触发
certificate verify failed，但错误日志里不提示缺哪一级
require_secure_transport=ON）、客户端强制校验（VERIFY_IDENTITY）、证书链角色与权限严格匹配。任何一环松动，整条链就失效——而失效时 MySQL 往往静默降级，不会报错提醒你。 
