先确认证书问题而非配置错误：执行show variables like 'ssl_ca'获路径，再用sudo -u mysql cat验证权限（600、属主mysql）、openssl检查有效期（须晚于2026-06-12）、云数据库查控制台validtill；新证书必须含subjectaltname（dns/ip全覆盖），否则mysql 8.0.29+/5.7.44+静默禁用ssl。
MySQL升级后SSL连接中断，90%是证书过期或缺失subjectAltName，不是配置写错了——直接换证书，别修my.cnf。
怎么确认真是证书问题，而不是配置路径写错？
先别改配置文件。登录新实例执行：SHOW VARIABLES LIKE 'ssl_ca';，拿到路径后立刻验证三件事：
- 用
sudo -u mysql cat /path/to/ca.pem | head -1测试MySQL进程能否读取（权限600、属主mysql） - 用
openssl x509 -in /path/to/ca.pem -text -noout | grep -E "(Not Before|Not After)"看有效期，2026年6月12日之后过期才算安全 - 云数据库（RDS/AWS/腾讯云）不提供文件访问，必须去控制台「SSL设置」页查
ValidTill字段
新证书为什么一定要带subjectAltName？
MySQL 8.0.29+ 和 5.7.44+ 默认拒绝加载没subjectAltName的证书，但启动时不报错，have_ssl会静默变成DISABLED，SHOW STATUS LIKE 'Ssl_cipher';返回空——你根本不知道它被跳过了。
生成时必须显式包含所有访问方式：
- 连
localhost？证书里得有DNS:localhost,IP:127.0.0.1 - 服务绑在
10.0.1.5？加IP:10.0.1.5 - 客户端用
db.example.com连接？必须写DNS:db.example.com - OpenSSL命令示例：
openssl req -new -key server-key.pem -out server-req.csr -subj "/CN=db.example.com" -addext "subjectAltName = DNS:db.example.com,IP:10.0.1.5,IP:127.0.0.1"（OpenSSL 3.0+）
客户端连不上，是服务端问题还是自己配错了？
用--ssl-mode=VERIFY_CA快速定位责任方：
mysql --ssl-mode=VERIFY_CA --ssl-ca=/etc/mysql/ssl/ca.pem -u user -h host -p- 如果报
unable to get issuer certificate，说明客户端用的CA不是服务端当前发的那张 - 如果连
--ssl-mode=REQUIRED都失败，大概率是服务端TLS协议或cipher不匹配（比如JDK用IBM SDK时cipher名不一致） - 云数据库必须用控制台下载的专用CA，如
aliyun-rds-ca-cert.pem，不能用mysql_ssl_rsa_setup生成的本地证书
ssl-ca路径和权限比证书内容还关键
MySQL启动时读不到ssl-ca文件，日志里往往只写一句Could not set ssl_mode，然后降级为非SSL连接（如果允许的话）。
-
ssl-ca必须写在[mysqld]段，不能放[client]或[mysql] - 路径必须是绝对路径，例如
/etc/mysql/ssl/ca.pem，./ca.pem或~/ssl/ca.pem都会失败 - 文件权限必须是600，属主必须是
mysql用户；644或755会导致加载失败 - 重启前手动测试：
sudo -u mysql cat /etc/mysql/ssl/ca.pem | head -1
最容易被忽略的是：证书本身没问题，但MySQL根本没加载它——因为路径错、权限错、段落错，或者subjectAltName漏了一项IP/DNS。排查时优先验证这四点，比反复调参数快得多。
