MySQL双向TLS认证必须同时满足三条件：服务端require_secure_transport=ON、用户创建时用REQUIRE SUBJECT精确绑定客户端证书DN、客户端显式传--ssl-mode=REQUIRED及--ssl-ca/--ssl-cert/--ssl-key；缺一不可，否则报Access denied而非SSL错误。
MySQL双向TLS认证不是配完证书就自动生效的，必须同时满足服务端强制、用户级证书约束、客户端显式传参三者，缺一不可；否则连接会静默失败，报错却显示Access denied for user，而不是明确的SSL错误。
require_secure_transport = ON 是硬性守门员
没这一步，所有SSL配置都白搭——非SSL连接仍能成功，REQUIRE SUBJECT根本不会触发校验。它必须写在[mysqld]段，重启MySQL后执行SHOW VARIABLES LIKE 'require_secure_transport';确认返回ON。
- 设成
OFF或注释掉，就退化为普通连接 -
ssl_mode = REQUIRED是客户端行为，服务端完全不读这个值，别把它和require_secure_transport混淆 - 如果用的是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字段，否则无法实现身份精确控制。
- SUBJECT值必须与
openssl x509 -in client-cert.pem -subject -noout输出逐字一致：空格、斜杠顺序、大小写都不能差 - 语法必须是
CREATE USER 'u'@'%' REQUIRE SUBJECT '/CN=client1/O=myorg'; -
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-cert和--ssl-key必须成对出现；私钥不能加密（生成时用了-nodes），否则客户端无法加载 -
ca.pem在客户端和服务端必须是同一份；若服务端用了中间CA，客户端也得把根CA + 中间CA拼进一个ca.pem里 - Linux上证书文件权限必须是
600，否则mysql命令拒绝读取
证书生成与路径权限容易被忽略
服务端证书路径配置错误或权限不对，会导致MySQL启动失败或SSL不生效，但错误日志往往不直接提示证书问题。
- 服务端证书（
server-cert.pem）里不能包含私钥；server-key.pem权限必须是600，MySQL启动时会校验 - MySQL 8.0+推荐用
mysql_ssl_rsa_setup --datadir=/var/lib/mysql --uid=mysql自动生成，避免手动生成时DN字段格式不一致 - 如果用OpenSSL手动生成，
openssl req -new交互中填的Common Name必须与REQUIRE SUBJECT中的CN=...严格匹配，且不能留空（某些版本会默认填localhost） - 服务端配置的
ssl_ca路径，必须指向客户端证书的签发CA（即你用来签client-cert.pem的那个ca.pem），不是服务端自己的CA
