MySQL升级后SSL连接失败90%因证书过期或缺失subjectAltName：先用openssl检查CA证书有效期，云数据库需查控制台；证书必须含DNS/IP等subjectAltName；ssl_ca路径须绝对、权限600、属主mysql；客户端可用--ssl-mode=VERIFY_CA快速定位问题源。
先看证书是否真过期，别急着改配置
MySQL 升级后 SSL 连接失败，90% 的情况不是配置写错了，而是服务端证书已经失效。升级本身不会动证书，但会更严格校验——比如 MySQL 5.7.44+ 和 8.0 默认启用 SSL 且拒绝过期证书，而旧版本可能悄悄绕过。
直接检查服务端 CA 证书有效期：openssl x509 -in /var/lib/mysql/ca.pem -text -noout | grep -E "(Not Before|Not After)"。如果 Not After 时间早于 2026-04-15（当前日期），就是它了。
云数据库（如阿里云 RDS、AWS RDS）不提供文件访问，得去控制台「SSL/TLS 设置」页查证书有效期，或调用 API 查 ValidTill 字段。
更新证书时必须带 subjectAltName
新生成的证书若没加 subjectAltName，MySQL 8.0+ 会直接拒绝握手，报错类似 SSL connection error: certificate verify failed，而不是告诉你缺 SAN。
- 本地测试用
localhost？证书里必须包含DNS:localhost - 服务跑在
10.0.1.5？得加IP:10.0.1.5 - 域名是
db.example.com？必须有DNS:db.example.com
用 OpenSSL 配置文件生成时，确保 [req] 段含 req_extensions = req_ext，并在 [req_ext] 中写明：subjectAltName = DNS:localhost,IP:127.0.0.1,IP:10.0.1.5。
ssl_ca 路径和权限比内容还关键
MySQL 启动时读不到 ssl_ca 文件，have_ssl 就会是 DISABLED，但错误日志里往往只写一句 Could not set ssl_mode，根本不说路径错在哪。
- 确认
ssl-ca在[mysqld]段，不是[client]或其他节 - 路径必须是绝对路径，比如
/etc/mysql/ssl/ca.pem，不能写成./ca.pem - 文件属主得是
mysql用户（Linux），权限不能高于600；否则 MySQL 直接跳过加载 - 重启前用
sudo -u mysql cat /etc/mysql/ssl/ca.pem | head -1测试可读性
客户端连不上？先关掉验证再定位
服务端证书更新后，客户端可能还缓存旧 CA 或用错路径。临时绕过验证能快速分清责任方：
- 命令行测试：用
mysql --ssl-mode=VERIFY_CA --ssl-ca=/path/to/new-ca.pem -u user -h host -p - 如果报
unable to get issuer certificate，说明客户端用的 CA 不是服务端发的那张 - 如果连
--ssl-mode=REQUIRED都失败，问题大概率在服务端 TLS 协议或 cipher 不匹配（比如 JDK 用 IBM SDK 时 cipher 名称不兼容）
真正麻烦的不是换证书，而是换完发现客户端连接池还在复用旧 session，或者中间件（如 ProxySQL、MaxScale）没同步更新 CA 文件——这些地方容易漏，但一漏就全链路中断。
