怎样为新建的MySQL8.0环境生成并绑定客户端双向认证CA证书？-mysql教程-PHP中文网

MySQL双向SSL认证要求客户端证书CN必须与数据库用户名完全一致，创建用户时须用REQUIRE SUBJECT精确绑定，服务端配置require_secure_transport=ON、ssl_ca/ssl_cert/ssl_key路径，并在客户端连接时显式指定--ssl-ca/--ssl-cert/--ssl-key三参数。

怎样为新建的mysql8.0环境生成并绑定客户端双向认证ca证书？

生成CA和客户端证书时，`subj` 中的 `CN` 必须匹配客户端连接时用的用户名

MySQL双向认证不校验主机名或IP，而是把证书里的 CN 字段直接映射为数据库用户名。如果你生成客户端证书时写的是 /CN=app_user，那后续就必须创建一个名为 app_user 的账号，并强制它只用证书登录：CREATE USER 'app_user'@'%' REQUIRE SUBJECT '/CN=app_user';。常见错误是随便写个 /CN=myclient，结果账号名却是 webapp，连接时提示 Access denied for user，其实不是密码错，是身份没对上。

CA私钥和证书只需生成一次：openssl genrsa 2048 > ca-key.pem、openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca-cert.pem -subj "/CN=MyMySQLCA"
客户端私钥和证书要单独签发：openssl genrsa 2048 > client-key.pem，然后用 openssl req -new -key client-key.pem -out client-req.pem -subj "/CN=app_user"，最后用 CA 签：openssl x509 -req -in client-req.pem -days 3650 -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem
生成完务必用 openssl x509 -noout -text -in client-cert.pem 检查输出里 Subject: 行是否真为 CN=app_user，别信文件名

`my.cnf` 里只配服务端证书，客户端证书由连接方提供

MySQL服务器配置文件（通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）只需要声明 CA 和自身证书路径，不涉及客户端证书。重点是这三个参数必须指向可读的 PEM 文件，且权限不能太宽松（比如 client-key.pem 被设成 644 就会启动失败）：

ssl_ca = /etc/mysql/ssl/ca-cert.pem（必须，用于验证客户端证书签名）
ssl_cert = /etc/mysql/ssl/server-cert.pem（必须，服务端对外出示的证书）
ssl_key = /etc/mysql/ssl/server-key.pem（必须，对应证书的私钥）

配完重启服务：sudo systemctl restart mysql，再用 mysql -u root -p -e "SHOW VARIABLES LIKE 'have_ssl';" 确认返回 YES；用 "SHOW STATUS LIKE 'Ssl_version';" 看是否已启用 TLS 协议。

创建用户时 `REQUIRE SUBJECT` 是双向认证的核心开关

光有证书没用，用户账号必须显式绑定证书身份。MySQL 不会自动把任意带证书的连接映射到某个账号，一切由 REQUIRE 子句控制。最简双向认证用户写法是：

CREATE USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'strong_pass';
ALTER USER 'app_user'@'%' REQUIRE SUBJECT '/CN=app_user' AND ISSUER '/CN=MyMySQLCA';

注意两点：一是 ISSUER 必须和你 CA 证书里的 CN 完全一致（包括大小写和空格），二是不能省略 @'%' —— 用 @'localhost' 的话，Unix socket 连接会绕过 SSL 校验，失去双向意义。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

如果还要限制 IP 段，可以加 AND SSL CIPHER 'ECDHE-ECDSA-AES256-SHA' 等条件，但一般没必要
执行后立即用 SELECT User, Host, ssl_type, ssl_cipher, x509_issuer, x509_subject FROM mysql.user WHERE User = 'app_user'; 验证字段是否生效
别忘了 FLUSH PRIVILEGES;，虽然 8.0 多数情况自动刷新，但保险起见仍建议执行

客户端连接必须同时提供三类文件，缺一不可

无论是命令行 mysql 客户端、JDBC 还是 Navicat，只要走双向认证，就必须传三个 PEM 文件：自己的私钥、自己的证书、以及服务端信任的 CA 证书。例如命令行连接：

mysql --ssl-ca=/path/to/ca-cert.pem \
      --ssl-cert=/path/to/client-cert.pem \
      --ssl-key=/path/to/client-key.pem \
      -u app_user -p -h db.example.com

常见坑是漏掉 --ssl-ca：客户端不验证服务端证书，就无法确认自己连的是不是目标 MySQL 实例，中间人攻击风险仍在。另一个典型问题是路径写错或权限不足——Linux 下 MySQL 客户端默认以当前用户身份读文件，若 client-key.pem 属主不是运行 mysql 命令的用户，会报 SSL connection error: SSL_CTX_set_default_verify_paths failed。

双向认证真正麻烦的地方不在生成证书，而在于每个环节的字符串完全匹配：CA 的 CN、客户端证书的 CN、SQL 语句里的 SUBJECT 字符串、账号名、甚至 ISSUER 的斜杠和空格——错一个字符，连接就静默拒绝，日志里往往只写 Access denied，不会告诉你哪一环崩了。