MySQL SSL加密配置实操：从证书生成到强制加密

上个月帮一个做电商的朋友排查数据库慢查询，习惯性地在跳板机上起了一个 tcpdump 抓包，结果眼睁睁看着一条 UPDATE 语句把用户的手机号和收货地址整段整段地暴露在网络上。那一刻我确实有点冒冷汗——这台 MySQL 部署在机房内网，但内网不等于安全，能登录跳板机的人、同一网段被攻破的服务、偶尔要从办公网直连的开发入口，任何一个环节有漏洞，数据就是在裸奔。

这篇文章不聊虚的，直接完整走一遍 MySQL 配置 SSL 加密连接的实操流程：从 OpenSSL 生成 CA 和服务器证书、修改服务端配置、各种客户端（命令行、JDBC、Python、Workbench）的连法，到强制加密、证书轮换、常见报错排查。内容偏 DBA 和全栈开发向，运维和后端同学照着做就行；如果你只想快速跑通一个最小方案，我把核心命令单独标出来了，全程大概 15 分钟。踩过的坑我都会提前指出来，尤其是那些网上教程不会写的细节。

1. 先搞清楚：MySQL 为什么要配 SSL，配完之后解决了什么

1.1 不加密的 MySQL 到底有多“裸”

MySQL 的经典协议（就是 3306 端口跑的那个协议）默认情况下是明文传输的。这里说的明文包括三样东西：客户端发出去的 SQL 语句、服务器返回的结果集、还有认证阶段使用的密码哈希。什么意思呢？就是只要有人在客户端和服务器之间的链路上抓包，你的数据字典、用户资料、业务 SQL 基本等于摊开给人看。

很多人觉得“我在内网，风险不大”，但内网从来不是信任边界。云环境里同一 VPC 下的其他主机、办公网里装了抓包工具的机器、被植入后门的跳板机，都是潜在风险点。而且很多合规审计都会检查数据库传输是否加密，如果连这个都没有，报告基本过不了。我当时那个朋友的情况就是这样，数据库连着公网还开着 3306，明文跑了三年，想想都后怕。

1.2 SSL 到底保护了哪几层东西

配置了 SSL 之后，主要解决三件事。第一是传输加密：SQL 语句和结果集在网络链路上变成密文，即使被抓包，看到的也是一堆不可读的 TLS 记录，而不是能直接用的 SQL。第二是身份验证：客户端可以校验服务器的证书，确认自己连的确实是目标服务器，而不是中间人冒充的假库。第三是完整性保护：TLS 的 MAC 校验能发现数据在传输过程中是否被篡改。

有一点要说清楚：SSL 只保护“客户端到 MySQL 服务器”这一段网络传输，不保护数据库文件本身，也不保护应用服务器和数据库之间的业务逻辑。它解决的是传输链路问题，磁盘加密、权限管控、审计日志这些是另一套工程，别混为一谈。

1.3 握手过程一句话讲明白

MySQL 的 SSL/TLS 握手本质上和 HTTPS 一样：客户端在连接时声明要使用 SSL，服务器把自己的证书链发过来，客户端验证证书是否可信（对应 CA 校验），然后双方协商出会话密钥，后续所有通信都用这把会话密钥加密。MySQL 支持 TLSv1.2 和 TLSv1.3，具体用哪个版本由双方协商结果决定。

理解这个握手过程很重要，因为后面所有报错几乎都出在这几个环节上：证书不可信、证书过期、主机名不匹配、协议版本不兼容、客户端没带证书。把这些环节逐个排查，比瞎试参数高效得多。

2. 证书生成：用 OpenSSL 搭一套自己的 CA

2.1 准备阶段：确认版本和工具

要配置 SSL，首先得有一套证书。生产环境最标准的做法是自己搭一个内部 CA（Certificate Authority，证书颁发机构），用这个 CA 去签发服务器证书和客户端证书。好处是所有证书都在自己手里，需要签多少张都行，证书的 CN、有效期、扩展属性都能自定义。

需要用到的工具就是 OpenSSL，几乎所有的 Linux 发行版都自带。先确认版本：

openssl version

只要是 1.1.1 以上版本就完全够用，1.1.1 和 3.x 的命令兼容性没问题。另外先确认 MySQL 的版本和安装方式，不管你是用 yum、apt 还是 Docker 装的 MySQL，证书生成和服务端配置的思路完全相同，区别只在配置文件路径。Docker 部署的话要注意把证书目录挂载进容器，后面我会专门提到。

注意：我下面的命令都是在专门的证书目录下执行，建议统一放在 /etc/mysql/ssl 或者 /data/mysql-ssl 这类独立目录，不要随手丢在 /tmp 里，避免权限混乱和误删。

2.2 生成 CA 根证书

第一步，生成 CA 的私钥。私钥是整个信任链的根，一定要保护好，权限 600 起步，最好放到只有 root 能读的目录：

mkdir -p /etc/mysql/ssl cd /etc/mysql/ssl openssl genrsa 2048 -out ca-key.pem

2048 位是目前的基本要求，如果机器性能允许，也可以用 4096 位，更安全但握手性能会略受影响。生成完私钥之后，用这个私钥自签一个 CA 根证书：

openssl req -new -x509 -days 3650 -key ca-key.pem -out ca.pem \ -subj "/CN=MySQL-Internal-CA" \ -addext "basicConstraints=critical,CA:TRUE" \ -addext "keyUsage=critical,keyCertSign,cRLSign"

这里几个参数说明一下。-days 3650 是 CA 根证书的有效期，根证书一般给 10 年，但实际运维中建议 5 年就轮换一次，避免根证书泄露的影响面太大。-subj 里的 CN 只是个标识，可以写成你们的组织名，重点在于后面服务器证书的 CN 一定要写准。-addext 是给 CA 加上关键扩展，标注这是一个 CA 证书，并且只能用来签发证书。

2.3 生成服务器证书并签发

CA 有了，接下来给 MySQL 服务器签发证书。这里有一个极其关键的坑：服务器证书的 CN 必须和客户端连接时使用的域名或 IP 匹配，否则后面用 VERIFY_IDENTITY 模式（严格校验主机名）时会直接失败。推荐用域名，如果只能用 IP 连接，CN 就写 IP。

先生成服务器私钥和证书签名请求（CSR）：

openssl genrsa 2048 -out server-key.pem openssl req -new -key server-key.pem -out server-csr.pem \ -subj "/CN=db1.example.com"

然后用刚才的 CA 私钥去签发服务器证书。签发时我建议加上 SAN（Subject Alternative Name），这样一台 MySQL 如果有多个访问域名，可以在 SAN 里都列上，避免以后换域名要重新签发：

openssl x509 -req -days 825 -in server-csr.pem \ -CA ca.pem -CAkey ca-key.pem -CAcreateserial \ -out server-cert.pem \ -extfile <(printf "subjectAltName=DNS:db1.example.com,DNS:db1-internal.example.com,IP:10.0.0.10\n")

签出来的 server-cert.pem 就是服务器给客户端看的证书。825 天是 2 年多几天，我习惯把服务器证书有效期控制在 2~3 年，太长容易忘记轮换，太短频繁续签也是负担。CAcreateserial 参数会生成一个 ca.srl 序列号文件，用来防止签发出重复序列号的证书，这个文件也要保存好。

2.4 可选：生成客户端证书做双向认证

如果你的安全要求更高，想让客户端也持有证书，连数据库时不仅要输密码，还要出示证书，那就需要再签一张客户端证书：

openssl genrsa 2048 -out client-key.pem openssl req -new -key client-key.pem -out client-csr.pem \ -subj "/CN=client-app01" openssl x509 -req -days 825 -in client-csr.pem \ -CA ca.pem -CAkey ca-key.pem -CAcreateserial \ -out client-cert.pem \ -extfile <(printf "extendedKeyUsage=clientAuth\n")

注意客户端证书的 extendedKeyUsage 要标成 clientAuth，服务器证书要标成 serverAuth（签发服务器证书时最好也加上）。这种双向认证模式对应 MySQL 里的 REQUIRE X509，后面第 5 部分会讲。

2.5 文件权限与放置位置

证书文件生成之后，权限是最容易踩坑的地方。MySQL 服务进程通常以 mysql 用户运行，私钥文件如果其他用户也能读，MySQL 可能直接拒绝启动，或者安全扫描报出风险。标准做法：

chmod 600 ca-key.pem server-key.pem client-key.pem chmod 644 ca.pem server-cert.pem client-cert.pem chown -R mysql:mysql /etc/mysql/ssl

私钥 600，证书 644，目录属于 mysql 用户。这一步做完，证书就绪，可以去配置服务端了。

3. 服务端配置：让 MySQL 加载证书并开启加密

3.1 修改 my.cnf / mysqld 配置段

找到 MySQL 的配置文件，一般路径是 /etc/my.cnf 或者 /etc/mysql/mysql.conf.d/mysqld.cnf，Docker 容器里通常通过挂载配置文件的方式覆盖。在 [mysqld] 段下加三行：

[mysqld] ssl-ca=/etc/mysql/ssl/ca.pem ssl-cert=/etc/mysql/ssl/server-cert.pem ssl-key=/etc/mysql/ssl/server-key.pem

如果你的 MySQL 版本是 8.0，也可以写成下划线风格（ssl_ca、ssl_cert、ssl_key），两种都识别。除此之外，还有一个参数建议顺手加上：

tls_version=TLSv1.2,TLSv1.3

这个参数控制允许使用的 TLS 协议版本。MySQL 5.7.10 之后支持 tls_version，8.0.16 之后支持 TLSv1.3。明确只开 TLSv1.2 和 TLSv1.3，把 TLSv1.0、TLSv1.1 关掉，能直接堵住一大批老协议漏洞。很多安全扫描报告里提到的 CVE-2016-2183 这类问题，本质上就是弱加密算法和老协议导致的，禁用之后基本就能消掉。

修改完配置文件，在确认配置无语法错误的情况下重启 MySQL。先验证一下配置能不能被 MySQL 正常读取：

mysqld --validate-config

这个命令会检查配置文件和参数，有错误会直接输出。如果 MySQL 是 8.0，执行这个命令时可能提示需要指定 datadir，normal 情况下不需要额外处理，直接跑就行。没问题就重启：

systemctl restart mysqld # 或者 Docker 部署 docker restart mysql-container

3.2 重启服务并验证 SSL 状态

重启完成后，登录 MySQL 检查 SSL 相关变量：

SHOW VARIABLES LIKE '%ssl%';

重点看两个值：have_ssl 应该是 YES，ssl_ca、ssl_cert、ssl_key 应该指向你配置的三个文件。如果 have_ssl 是 DISABLED，说明证书加载失败，去错误日志里找原因，大概率是文件权限或者证书文件损坏。

再查一下动态状态：

SHOW STATUS LIKE 'Ssl%';

里面的关键指标是 Ssl_version（当前协议的协商版本）、Ssl_cipher（协商出来的加密套件）、Ssl_accepts（接受 SSL 连接的次数）。如果这些值里有内容，说明服务器已经在提供 SSL 加密服务了。

3.3 关于 MySQL 8.0 自动生成证书的那点事

MySQL 8.0 在初始化数据目录时，如果发现没有配置任何 SSL 相关参数，会自动生成一套自签名证书，参数 auto_generate_certs 默认就是 ON。所以很多 8.0 用户即使什么都不配置，have_ssl 也会是 YES。

但这里有一个很大的误区：8.0 自动生成的证书是自签名的，它的 CA 就是它自己，客户端如果不显式信任这个 CA，用严格校验模式连接会直接报证书不可信。而且自动生成的证书有效期通常只有一年，到期后如果没注意，所有强制校验的客户端会瞬间连不上。所以我强烈建议：哪怕 8.0 自动生成了证书，也按上面步骤手签一套替换掉，把主动权握在自己手里。

4. 客户端连接：命令行、JDBC、Python、Workbench 全覆盖

4.1 mysql 命令行的 --ssl-mode 五档说明

服务端配置完成，接下来是客户端。先用 mysql 命令行工具验证。MySQL 5.7.11 之后，客户端支持 --ssl-mode 参数，一共五档，从松到严分别是：

等我配置好之后，生产环境最少要用 VERIFY_CA。验证时把 CA 传给客户端：

mysql --ssl-mode=VERIFY_CA --ssl-ca=/etc/mysql/ssl/ca.pem \ -h db1.example.com -u app_user -p

如果一切正常，登录后在 MySQL 里执行：

SHOW STATUS LIKE 'Ssl_cipher';

能看到一个具体的加密套件名称，比如 TLS_AES_256_GCM_SHA384，就说明这条连接已经是加密状态了。如果结果是空，说明还是明文连接。

4.2 JDBC 连接串配置与常见坑

Java 应用用的是 Connector/J 驱动。老的 5.x 驱动用 useSSL、requireSSL、verifyServerCertificate 这一组参数，新一点的 8.0 驱动推荐直接用 sslMode，语义更清楚。

jdbc:mysql://db1.example.com:3306/app_db?useSSL=true&requireSSL=true&verifyServerCertificate=true&trustCertificateKeyStoreUrl=file:/etc/ssl/ca-truststore.jks&trustCertificateKeyStorePassword=changeit

如果是 8.0 驱动，可以这样写：

jdbc:mysql://db1.example.com:3306/app_db?sslMode=VERIFY_CA&trustCertificateKeyStoreUrl=file:/etc/ssl/ca-truststore.jks&trustCertificateKeyStorePassword=changeit

这里最大的坑是信任库。Java 不认 .pem 格式的 CA，你得先把 CA 导入到 JKS（Java KeyStore）里。导入命令：

keytool -import -alias mysql-ca -file ca.pem \ -keystore ca-truststore.jks -storepass changeit

很多 Java 应用 SSL 连接报错，报错信息里出现 “unable to find valid certification path to requested target” 或者 “certificate_verify_failed”，十有八九就是这个 JKS 信任库没配对，或者根本没导 CA。另外提醒一句，verifyServerCertificate=true 在 5.x 驱动里默认是 false，光写 useSSL=true 不校验 CA 等于白搭，起不到防中间人的作用。

4.3 Python（PyMySQL / mysql-connector-python）

Python 生态里 PyMySQL 用得最多，SSL 配置直接通过 ssl 参数字典传进去：

import pymysql conn = pymysql.connect( host="db1.example.com", user="app_user", password="xxxx", database="app_db", ssl={ "ca": "/etc/mysql/ssl/ca.pem", "verify_cert": True, }, )

PyMySQL 里 verify_cert 对应的是 VERIFY_CA 语义，如果想做主机名校验，还需要传 ssl_verify_identity=True。注意，PyMySQL 的 ssl_verify_identity 在 1.0 版本之后才支持完整校验逻辑，老版本要么升级，要么就只做 CA 校验。

如果用官方 mysql-connector-python，参数更直观：

import mysql.connector conn = mysql.connector.connect( host="db1.example.com", user="app_user", password="xxxx", database="app_db", ssl_ca="/etc/mysql/ssl/ca.pem", ssl_verify_cert=True, )

4.4 MySQL Workbench 图形化配置

图形化工具 MySQL Workbench 在配置连接时，点击 Advanced 或者 SSL 标签页，选择 "Use SSL"，然后填 CA 文件路径。如果是双向认证，还要填客户端证书和客户端私钥的路径。填完之后点 Test Connection，能通过就说明证书链路没问题。

Workbench 还带一个很实用的功能：在 Server Status 面板里可以直接看到 SSL 状态，包括当前连接的加密套件。我平时排查问题时，经常用 Workbench 快速验证一批开发机的 SSL 是否真的生效，比在命令行一个个敲 SHOW STATUS 快得多。

5. 强制加密：不加密就不让连

5.1 账号级别 REQUIRE SSL / REQUIRE X509

配置好 SSL 之后，服务端并不会强制所有连接都走加密。默认情况下，客户端可以选择不加密连接，服务器照样放行。要让加密真正落地，必须显式地把账号设成强制 SSL。

用管理员账号登录，创建新账号时直接带 REQUIRE SSL：

CREATE USER 'app_user'@'%' IDENTIFIED BY 'xxxx' REQUIRE SSL;

如果是已有账号，用 ALTER 改一下：

ALTER USER 'app_user'@'%' REQUIRE SSL;

改完之后，这个账号再用明文方式连接会直接报错。想更严格一点，用双向认证的模式：

ALTER USER 'app_user'@'%' REQUIRE X509;

REQUIRE X509 要求客户端不仅要用 SSL，还必须携带一张由受信任 CA 签发的客户端证书。这种方式适合对安全极度敏感的场景，比如支付类、核心用户数据类应用。缺点也很明显：每台应用服务器都要单独发证书、维护证书有效期，运维成本高不少。

5.2 全局级别 require_secure_transport

账号级别一个个改，账号多了容易漏。MySQL 8.0.8 开始支持全局参数 require_secure_transport，设为 ON 之后就变成“所有账号、所有连接都必须走加密或本地 socket”，任何明文连接都会被拒绝：

[mysqld] require_secure_transport=ON

老版本（5.7 及更早）没有这个全局开关，只能在账号维度逐个 REQUIRE SSL，或者通过触发器/定时任务定期扫描 mysql.user 表，把没有 REQUIRE SSL 的账号批量修复。5.7 用户如果嫌麻烦，也可以在应用侧入口统一做限制，比如所有客户端都配置成 VERIFY_CA，从源头杜绝明文连接。

5.3 怎么验证强制加密真的生效了

配置完强制加密，一定要实际验证一次。最直接的办法：用一个不传 SSL 参数的命令行客户端去连接，看是否被拒绝：

mysql --ssl-mode=DISABLED -h db1.example.com -u app_user -p

如果服务端强制生效，这里会提示连接被拒，或者在认证阶段直接报 SSL 相关错误。反过来，用正常的 VERIFY_CA 方式连一次，确认能正常登录。这两步都通过，说明开关是真正落地了，而不是只改了个配置没生效。

6. 常见报错与排查实录

6.1 高频错误速查表

配置过程中我把最常见的报错整理成一张表，建议收藏。逐条对着查，比在黑板上瞎试快得多：

6.2 三个真实踩坑案例

先说第一个：主机名校验失败的坑。我给一台测试机配好了 SSL，客户端用 VERIFY_CA 连接没问题，但一升级到 VERIFY_IDENTITY 就报证书校验失败。查了半天才发现，服务器证书的 CN 写的是 db1.example.com，但测试时客户端连的是 IP 10.0.0.10，主机名完全对不上。解决办法是把 IP 加到证书的 SAN 扩展里重新签发，或者让客户端统一用域名连接。这个坑在跨网段、内网 IP 直连的场景下非常容易出现，提前把 SAN 列全能省很多事。

第二个坑是 Java 应用的信任库。当时一个 Java 服务连库报 unable to find valid certification path，我以为是网络问题，后来发现是连接串里少了 trustCertificateKeyStoreUrl 参数，导致 JVM 拿着默认的 JDK 信任库去校验我自己的 CA，当然过不了。把自定义 CA 导入到一个独立 JKS，并在连接串里显式指定，问题立刻解决。

第三个坑是 Docker 部署的证书权限。同事把证书放到宿主机目录，容器里把证书目录挂载进去后，MySQL 一直启动失败，日志里显示 key 文件无法读取。原因很直接：挂载进来的文件属主是宿主机用户，容器内的 mysql 用户没有读权限。把证书文件的属主改成 UID 999（容器内 mysql 用户的常见 UID），或者直接 chmod 到容器能读的权限，容器才能正常启动。这个问题排查起来很隐蔽，因为文件看起来一直在那个路径下，实际上权限根本不够。

6.3 用抓包和 openssl 命令验证是否真的加密了

前面这些是“配置层面”的验证，最后再说一个“真实流量层面”的验证手段。用 tcpdump 抓一下 3306 端口的包：

tcpdump -ni any tcp port 3306 -A

如果你能看到 SQL 的关键字，比如 SELECT、UPDATE、WHERE 后面跟着表名和字段值，说明这条链路还是明文，SSL 配置一定有问题。如果看到的内容全是乱码一样的二进制数据，而且有 Application Data 这种 TLS 记录特征，说明加密已经生效。

另外，较新版本的 OpenSSL 支持直接对 MySQL 做 STARTTLS 探测：

openssl s_client -starttls mysql -connect db1.example.com:3306 -brief

如果服务器 SSL 正常，这条命令会输出协商出来的 TLS 版本和加密套件。这个方法适合在没有 mysql 客户端的机器上快速探测服务器是否开启了加密端口，非常简单粗暴。

7. 运维向：证书轮换、安全扫描与长期维护

7.1 证书过期检测与平滑轮换

证书有有效期，过期前不处理，客户端会陆续开始报错。很多生产事故都是这么来的：凌晨证书到期，第二天业务方集体反馈连不上库。所以证书的到期监控必须提前做好。

Linux 下查看证书的过期时间很简单：

openssl x509 -in /etc/mysql/ssl/server-cert.pem -noout -dates

可以把这个命令挂到定时任务里，每周检查一次，到期前 30 天发告警。轮换时，新证书签发之后，MySQL 8.0.21 以上版本支持在线重载 TLS 配置，不用重启实例：

ALTER INSTANCE RELOAD TLS;

这个命令会重新读取 ssl_ca、ssl_cert、ssl_key 指向的证书文件，非常适合做无缝轮换。老版本没有这个功能，只能在低峰期重启 MySQL，如果集群有主从或者代理，可以逐个节点重启，避免业务中断。

7.2 TLS 版本与弱加密套件加固

配置完 SSL 只是第一步，安全扫描常常还会盯上 TLS 配置本身。比如刚才提到的 CVE-2016-2183，本质是 TLS 里对 3DES、RC4 这类弱加密算法的支持导致的。MySQL 里可以通过 tls_version 和 ssl_cipher 两个参数来限制：

[mysqld] tls_version=TLSv1.2,TLSv1.3 ssl_cipher=TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

tls_version 控制协议版本，ssl_cipher 控制加密套件白名单。只保留 GCM 类的 AEAD 套件，把 CBC、RC4、3DES 全部排除在外，安全扫描基本就能干净很多。注意 ssl_cipher 的参数格式是冒号分隔，不同版本支持的套件名称略有差异，配置完后一定要用 SHOW VARIABLES LIKE 'ssl_cipher' 确认实际生效情况。

7.3 监控 SSL 连接的使用比例

最后说监控。运维层面除了看证书过期，还要关注“到底有多少连接在走 SSL”。用下面这条 SQL 查所有非本地 socket 连接里，哪些没走 SSL：

SELECT PROCESSLIST_ID, USER, HOST, DB, COMMAND FROM performance_schema.threads WHERE NAME LIKE '%client%' AND PROCESSLIST_ID IS NOT NULL;

更直观的方式是统计服务器端 Ssl 状态变量：

SHOW STATUS LIKE 'Ssl_%';

重点看 Ssl_accepts 和 Ssl_client_connects 的数量变化。如果 Ssl_accepts 增长但业务量没增长，或者某些账号的 Ssl_cipher 一直是空，说明有客户端还在走明文。把这些信息接到监控系统里，做一个“明文连接占比”的告警，一旦有非 SSL 连接出现立即感知，比事后排查要省心得多。

最后一个实操建议：上线 SSL 前，一定要先在测试环境把整套证书生成、服务端配置、客户端连接、强制加密完整走一遍，并且把证书备份放到另外一个安全位置。我见过太多人生产环境直接开干，结果证书路径写错导致服务起不来，或者忘记在客户端信任库里导入 CA 导致大面积连不上。这套流程本身不复杂，难就难在细节多、链路长，按这个顺序一步步来，基本不会翻车。