MySQL双向SSL认证必须同时满足三条件：服务端require_secure_transport=ON、用户创建时用REQUIRE SUBJECT精确绑定客户端证书DN、客户端显式传--ssl-mode=REQUIRED及--ssl-ca/--ssl-cert/--ssl-key；缺一不可，否则报Access denied而非SSL错误。
MySQL双向SSL认证不是配完证书就自动生效的，必须同时满足服务端强制、用户级证书约束、客户端显式传参三者，缺一不可；否则连接会静默失败，报错却显示Access denied for user，而不是明确的SSL错误。
require_secure_transport = ON 是硬性守门员
没这一步，所有SSL配置都白搭——非SSL连接仍能成功，REQUIRE SUBJECT根本不会触发校验。它必须写在[mysqld]段，重启MySQL后执行SHOW VARIABLES LIKE 'require_secure_transport'确认返回ON。设成OFF或注释掉，就退化为普通连接。
如果用的是Azure Database for MySQL灵活服务器，默认已是ON且tls_version = TLSv1.2，但需确认未被人为降级到TLS 1.0/1.1（2025年8月31日起已强制淘汰）。
CREATE USER 必须用 REQUIRE SUBJECT，不能靠 GRANT 或 ALTER USER 补救
只写REQUIRE SSL或REQUIRE X509只能做基础校验，生产环境必须用REQUIRE SUBJECT绑定客户端证书DN字段，否则无法实现身份精确控制。
- 语法必须是
CREATE USER 'u'@'%' REQUIRE SUBJECT '/CN=client1/O=myorg' -
SUBJECT值必须与openssl x509 -in client-cert.pem -subject -noout输出逐字一致：空格、斜杠顺序、大小写都不能差 -
GRANT ... REQUIRE X509无效；ALTER USER 'u'@'%' REQUIRE SUBJECT ''会清空之前所有REQUIRE条件，不是追加 - 切勿给
root用户配REQUIRE SUBJECT，一旦证书路径错或失效，可能彻底锁死管理入口
mysql 命令行客户端必须显式传三个 PEM 文件
mysql命令行客户端不读my.cnf的[client]段，漏掉任一参数，错误表现通常是Access denied for user，而不是明确的SSL错误。
- 最小必要组合：
mysql --ssl-mode=REQUIRED --ssl-ca=ca.pem --ssl-cert=client-cert.pem --ssl-key=client-key.pem -u u -p -
--ssl-mode=REQUIRED不能省，设成PREFERRED或DISABLED会退化为非SSL连接 -
--ssl-cert和--ssl-key必须成对出现，且私钥不能有密码（mysql客户端不支持交互输密钥密码） - 证书文件权限必须为
600，否则MySQL启动或连接时会拒绝加载
服务端证书路径配置与权限检查
服务端证书必须由同一CA签发，并正确配置路径，否则即使客户端证书正确也会因服务端无法完成握手而失败。
-
ssl_ca必须指向签发客户端证书的CA根证书（即ca.pem），不是服务端自己的CA -
server-cert.pem里不能包含私钥内容；可用openssl x509 -in server-cert.pem -text -noout验证是否为纯证书 - 证书文件属主必须是
mysql用户，路径如/var/lib/mysql/ssl/需确保MySQL进程可读 - 不要遗漏
ssl_crl——如果后续要吊销某个客户端证书，没配这个就无效
最容易被忽略的是：服务端require_secure_transport = ON和客户端--ssl-mode=REQUIRED看似重复，实则职责完全不同；前者是服务端准入开关，后者是客户端连接意图声明——两者缺一，双向认证就形同虚设。
