mysql双向ssl需配置require_secure_transport=on、ssl_ca/ssl_cert/ssl_key路径，并创建用户时用require x509或require subject严格匹配客户端证书dn；客户端连接须显式指定--ssl-mode=required及--ssl-ca/--ssl-cert/--ssl-key参数。
MySQL服务端启用SSL双向验证要改哪些配置
MySQL默认只支持单向SSL（客户端验服务端），要实现双向验证，必须让服务端主动要求客户端提供证书，并校验其合法性。核心在于服务端配置中强制开启require_secure_transport，同时在用户创建时绑定REQUIRE X509或更细粒度的REQUIRE SUBJECT/REQUIRE ISSUER。
-
my.cnf里必须设置：ssl_mode = REQUIRED（仅影响连接行为，不强制校验证书）、require_secure_transport = ON（强制所有连接走SSL，否则拒绝） - 服务端证书路径需明确指定：
ssl_ca、ssl_cert、ssl_key，其中ssl_ca必须包含客户端证书的签发CA（即你用来签客户端证书的那个CA根证书） - 不要遗漏
ssl_crl（证书吊销列表）——如果后续要吊销某个客户端证书，没配这个就无效
创建支持双向验证的MySQL用户要注意什么
用户权限本身不决定是否双向验证，真正起作用的是CREATE USER语句里的REQUIRE子句。用REQUIRE X509是最基础的双向验证门槛，但生产环境建议用更严格的约束。
- 必须用
CREATE USER 'u'@'%' REQUIRE X509（或REQUIRE SUBJECT '/CN=client1/O=myorg'）——只写GRANT ... REQUIRE X509不会生效 -
REQUIRE SUBJECT里的DN字段要和客户端证书subject完全一致，包括空格和顺序；常见坑是证书生成时用了OU=dev，但SUBJECT里写成OU=Dev导致匹配失败 - 不能对同一用户重复执行
ALTER USER ... REQUIRE X509来“叠加”条件，后一次会覆盖前一次
mysql命令行客户端连双向SSL时证书参数怎么传
命令行工具mysql本身不读取系统级SSL配置，所有证书路径都得显式传参。漏掉任何一个，都会报错SSL connection error: SSL is required and the server doesn't support it或更隐蔽的Access denied for user（其实是证书校验失败，但错误信息不提示）。
- 最小必要参数组合：
mysql --ssl-mode=REQUIRED --ssl-ca=/path/to/ca.pem --ssl-cert=/path/to/client-cert.pem --ssl-key=/path/to/client-key.pem -u u -p -
--ssl-mode=REQUIRED不能省，设成PREFERRED或DISABLED会退化为非SSL连接 -
--ssl-cert和--ssl-key必须成对出现，且私钥不能有密码（mysql客户端不支持交互输密钥密码） - 如果服务端配置了
REQUIRE SUBJECT，客户端证书的subject必须严格匹配，可用openssl x509 -in client-cert.pem -text -noout | grep Subject核对
为什么连上了却还是被拒绝：常见证书链与权限陷阱
双向验证失败往往不是配置没开，而是证书链断裂或权限逻辑错位。MySQL在握手阶段完成证书校验，但错误日志通常只写Access denied，看不出根源。
- 客户端证书的
issuer必须能被服务端ssl_ca文件里的CA证书直接签名；如果中间有Intermediate CA，就得把整个链（root + intermediate）都拼进ssl_ca文件 - 服务端启动时若
ssl_ca文件不可读、格式非法或不含有效CA，MySQL会静默忽略该配置，导致看似开了SSL实则未校验客户端证书 - 用户host部分（如
'u'@'192.168.1.%'）必须和客户端实际IP匹配；哪怕证书完全正确，host不匹配也会返回Access denied，且错误信息一模一样
证书路径权限、CA文件内容完整性、subject字符串精确性——这三个点，调通之前最好逐个用openssl verify和mysqladmin variables | grep ssl交叉确认。少一个，就卡在“连得上但登不了”。
