前阵子给一家公司做数据库迁移后的安全加固，安全团队抓包巡检的结果直接把我给看愣了：3306端口上跑的全是明文，包括应用账号的密码。这里说的不是公网，而是内网。但只要有一个人误装抓包工具、存在被挂马的跳板机、或者网络设备做了端口镜像，全量口令就等于摆在那里的裸奔状态。于是领导顺手把任务丢了过来：把MySQL的SSL加密访问配上。这篇文章就是这套操作的完整记录，从证书生成、服务端配置、客户端连接验证，到最常见的MySQL SSL连接错误排查，一次说清楚。适合所有在用MySQL的DBA、后端开发和运维同学，哪怕之前没碰过证书也不慌，照着步骤走就能落地。
1. 明文连接的隐患与SSL加密的定位
1.1 内网抓包就能看到root密码：明文连接的真实风险
MySQL默认情况下，客户端与服务器之间跑的是纯明文协议。所谓“默认”，指的就是你从命令行敲mysql -uroot -p连上去之后，认证阶段的口令、后续所有SQL语句和查询结果都是可直接嗅探的。我用tcpdump在内网机房抓过包，重启服务后顺手一抓，一会儿就看到Authentication Plaintext Password那一行，root的密码就安静地躺在数据包里。这个场景其实很普遍，不是只有被攻破才会出事，安全审计、等保检查、合作伙伴需要提供加密传输截图，这些需求一年总要来几次。
明文连接的真正风险有三层：
- 口令泄露：认证阶段的数据明文可见，抓包等于拿密码。
- 数据被篡改：中间人可以把
UPDATE改成DELETE，客户端和服务端根本感知不到。 - 身份被冒充：客户端以为是你的服务器，其实连到了一个伪装的MySQL实例。
所以，SSL加密访问在MySQL这里的定位，从来不是“防内鬼”那么悲观，而是“假设网络上有人能看、能改，你的连接依然可信”。这个边界先想清楚，后面配置起来思路就顺了。
1.2 SSL在MySQL里的作用：传输加密与身份校验
大家经常说“MySQL SSL”，其实底层就是TLS协议，只是约定成俗叫SSL。它在数据库连接里干两件事：
第一件事是传输加密。握手之后的会话数据全部用对称密钥加密，抓包只能看到一堆密文，再也要不回密码和语句明文。
第二件事是身份校验。服务端会出示证书，客户端可以验证这个证书是不是由你信任的CA签发的，防止连到假服务器。如果需要更强的安全性，还可以让客户端也出示证书，实现双向认证，这样MySQL可以精确到“只允许持有指定客户端证书的账号连接”。
从证书文件的构成来看，一套最小可用体系需要三件东西：CA私钥与CA证书、服务端私钥与服务端证书。如果做双向认证，还要额外给客户端签发一份证书。搞清楚这个结构之后，接下来所有命令都是在围绕这三件套打转。
2. 证书准备：自建CA、OpenSSL生成与权限
2.1 为什么我不建议拿网站SSL证书给MySQL用
很多人的第一反应是：“我有阿里云免费的SSL证书，能不能直接拿去给MySQL用？”我用过之后的结论是：不推荐。
网站SSL证书签发时绑定的是域名，比如api.example.com，而MySQL客户端连接时往往走的是IP地址或内网主机名，证书里的域名和实际连接地址对不上，只要开启严格校验就会失败。另外免费证书的有效期通常只有90天到一年，你得不停续期、替换文件，MySQL又不像Nginx可以无感reload，每换一次证书就得重启一次数据库，这个运维成本不值得。
MySQL内部传输加密更适合的方案是自建CA。自建CA签出来的证书不需要外面任何人信任，只需要参与通信的客户端和服务端信任这份CA证书就行。就像公司内部自己发工作牌，不需要派出所备案，但只要门卫认这个工作牌就没问题。整个过程完全可控，签发年限也能设成10年，减少频繁换证书的烦恼。
如果你的MySQL是官方安装包或源仓库安装的，bin目录下其实带了一个mysql_ssl_rsa_setup脚本，可以一键生成一套自签证书。我的建议是：测试环境拿它快速跑通没问题，生产环境还是用OpenSSL手动生成更稳妥，因为脚本生成的证书CN信息基本没配置，后面一旦要开VERIFY_IDENTITY严格校验，主机名验证基本过不了。
2.2 OpenSSL生成CA和服务端证书的完整过程
先在工作机上建一个目录，后面所有证书操作都在这里进行：
mkdir -p /opt/mysql-certs && cd /opt/mysql-certs第一步，生成CA私钥和CA证书。这里用的-nodes参数表示私钥不加密。CA私钥理论上应该加密保护，但如果CA私钥加了密码，后续每次签发证书都要手动输密码，自动化脚本就没法用了。我的做法是CA私钥留密码并单独收好，下面命令为了方便展示先不带额外口令：
openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca-cert.pem -subj "/CN=MySQL-Internal-CA"第二步，生成服务端私钥和证书签名请求（CSR）。服务端私钥一定不要加密码，因为MySQL每次启动都要读取它，加了口令之后要么无法自动启动，要么得额外处理密钥密码，非常麻烦：
openssl genrsa 2048 > server-key.pem openssl req -new -key server-key.pem -out server-csr.pem -subj "/CN=mysql-server-01"第三步，准备扩展文件，把服务器的域名和IP填进SAN字段。这一步很多人会漏，但客户端在VERIFY_IDENTITY模式下会严格检查证书里的SAN和实际连接主机是否一致，不写SAN后续排查会花掉不少时间。我一般会这样写：
cat > server-ext.cnf <<EOF subjectAltName = DNS:db.example.com, IP:192.168.1.10 EOF第四步，用CA签发服务端证书，指定有效期10年：
openssl x509 -req -in server-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -days 3650 -extfile server-ext.cnf最后生成完后，检查一下证书内容确认SAN和有效期正确：
openssl x509 -in server-cert.pem -text -noout | grep -A1 "Subject Alternative Name"如果以后要做双向认证，再给客户端签发一份证书，流程类似：生成客户端私钥、CSR，再用同一套CA签发即可。
2.3 证书文件权限与路径设计的坑
证书生成完毕，放在哪个目录、权限怎么设，是很容易翻车的环节。我踩过最典型的一个坑是：私钥权限太开放，MySQL启动时直接报权限错误拒绝读取。
可靠的做法是把证书统一放到一个独立路径，比如/etc/mysql/certs/：
mkdir -p /etc/mysql/certs cp ca-cert.pem server-cert.pem server-key.pem /etc/mysql/certs/ chown -R mysql:mysql /etc/mysql/certs chmod 600 /etc/mysql/certs/server-key.pem chmod 644 /etc/mysql/certs/ca-cert.pem /etc/mysql/certs/server-cert.pem这里的关键判断是：私钥必须只有mysql进程能读，权限给600；证书文件本身是公钥性质的，给别人看无所谓，644即可。如果权限给成了其他非mysql用户可读，MySQL在部分发行版上的OpenSSL实现会拒绝使用，报错往往写的是bad permission之类，问题不大但很迷惑人。
3. 服务端开启SSL：配置项、强制加密与验证
3.1 my.cnf配置与require_secure_transport的取舍
证书就位后，修改MySQL配置文件。在[mysqld]段下追加三行：
[mysqld] ssl_ca=/etc/mysql/certs/ca-cert.pem ssl_cert=/etc/mysql/certs/server-cert.pem ssl_key=/etc/mysql/certs/server-key.pem require_secure_transport=ON前三项是告诉MySQL“用哪套证书”，require_secure_transport=ON是强硬表态：所有连接必须走加密通道，不支持SSL的客户端直接拒绝连接。这个选项MySQL 5.7.5以上和8.0全系都支持。
很多初次配置的同学会在这时候犯嘀咕：“我开了强制加密，会不会把现有客户端全部搞挂？”这个担心是对的，所以生产环境建议分两步走：先只配置SSL证书，不开启require_secure_transport，等客户端都验证能连上、确认没问题后，再打开强制加密开关。不要第一天就把门焊死，容易把业务连接全部冲到地上。
另外，[mysqld]段还有一个skip_ssl开关，默认是关闭的，也就是说只要没有显式写skip_ssl，MySQL本身是具备SSL能力的。之所以要显式配置证书，是因为MySQL自带的自动证书生成只覆盖初始化阶段，手动指定之后才可控、可更新、可严格校验。
3.2 重启后怎么验证SSL真正生效
配置完成，重启MySQL：
systemctl restart mysqld重启后用root或其他管理账号登录，执行这条SQL查看SSL相关变量：
SHOW VARIABLES LIKE '%ssl%';几个关键结果的正常状态是：
| 变量名 | 正常值 | 说明 |
|---|---|---|
| have_ssl | YES | 服务端SSL功能已启用 |
| have_openssl | YES | 使用OpenSSL实现 |
| ssl_ca | /etc/mysql/certs/ca-cert.pem | CA证书加载成功 |
| ssl_cert | /etc/mysql/certs/server-cert.pem | 服务端证书加载成功 |
| ssl_key | /etc/mysql/certs/server-key.pem | 服务端私钥加载成功 |
如果have_ssl是DISABLED，说明配置没有被正确加载。这时候第一时间去MySQL错误日志里翻证书相关报错，比如路径不存在、私钥无法解析、权限不足等，逐条核对。日志文件一般在/var/log/mysql/error.log或/var/log/mysqld.log，不同发行版路径略有差异。
如果担心配置前后行为不一致，还可以执行SHOW STATUS LIKE 'Ssl_cipher';看一下当前会话的加密套件。新会话连上后这个值是TLS_AES_256_GCM_SHA384之类的字符串，说明当前连接已经完成TLS握手。特别提醒：通过本地socket连接的会话走的是Unix socket，不是网络协议栈，即使SSL配置成功，socket连接本身并不受SSL保护，这属于正常行为。
调试阶段还有一个非常实用的压测方法：在另一台机器上不指定任何SSL参数直接连接，如果看到ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON，恭喜你，强制加密已经生效。
4. 客户端连接：SSL模式、双向认证与GUI配置
4.1 命令行连接：--ssl-mode=REQUIRED的正确姿势
MySQL 8.0客户端默认的SSL模式是PREFERRED，意思是：服务器支持就加密，不支持就退回明文。这个默认值照顾了兼容性，但也埋了一个隐患——如果服务器SSL配置有问题，客户端会悄无声息地降级成明文，你根本察觉不到。
所以客户端侧要主动用REQUIRED模式强制加密。命令行连接方式如下：
mysql -h db.example.com -u app_user -p --ssl-mode=REQUIRED如果你希望客户端同时校验服务器证书是否可信，再加上CA证书参数：
mysql -h db.example.com -u app_user -p --ssl-mode=VERIFY_CA --ssl-ca=/etc/mysql/certs/ca-cert.pemVERIFY_CA只验证证书是由受信CA签的，VERIFY_IDENTITY还会额外校验主机名。两者差别要分清：前者防伪造CA，后者还能防别人拿着同一CA签发的其他域名证书来冒认服务器。
老版本MySQL 5.7的客户端用的是--ssl和--ssl-verify-server-cert，参数名不同，语义类似。我的建议是能升级客户端就升级到8.0，毕竟--ssl-mode这一套在新老版本里被统一得最干净。
4.2 如何确认真实连接真的在加密
我自己见过不少“配了SSL但实际没生效”的情况，所以验证这一步绝对不能省。连接上MySQL之后，直接在客户端执行：
SHOW SESSION STATUS LIKE 'Ssl_cipher';返回结果里只要有一串加密套件名称，比如TLS_AES_256_GCM_SHA384，就说明当前连接是加密的。如果返回空，就代表这个会话没有走SSL，哪怕服务器已经开了SSL，也可能是客户端这边主动选择了不加密。
也可以用performance_schema查所有会话的加密情况，这个在生产环境排障时更好用：
SELECT PROCESSLIST_ID, VARIABLE_VALUE FROM performance_schema.session_status WHERE VARIABLE_NAME='Ssl_cipher' AND PROCESSLIST_ID IS NOT NULL;这样能一次看清楚当前MySQL实例上的所有连接里，哪些是加密的，哪些还是明文。我上线新的强制加密策略之前，一定会执行这条语句对照一遍，确认没有漏网之鱼。
4.3 进阶：REQUIRE X509双向认证与编程语言连接参数
如果你面对的审计要求比较高，比如“必须双向认证”，那就要走到用户级别的策略了。MySQL可以在账号粒度上做限制，比如：
ALTER USER 'app_user'@'%' REQUIRE X509;这一条执行之后，app_user连接时必须出示客户端证书，缺证书直接拒绝。配合服务端设置的ssl_ca，MySQL会校验客户端证书是否由同一CA签发。这种做法适合对安全极其敏感的内部系统，代价是每个应用服务器都得存放并分发客户端证书和私钥，证书的吊销与轮换需要额外管理流程。
编程语言这边的连接参数也顺带提一下，方便大家直接“抄作业”。Java的JDBC连接串可以这样加：
jdbc:mysql://db.example.com:3306/appdb?sslMode=REQUIREDMySQL Connector/J 8.0.30以上推荐用sslMode，更早的版本用useSSL=true和requireSSL=true。Python的连接示例：
import mysql.connector conn = mysql.connector.connect( host="db.example.com", user="app_user", password="secret", ssl_ca="/etc/mysql/certs/ca-cert.pem", ssl_verify_cert=True, )Go语言的go-sql-driver/mysql则是在DSN里拼tls=true或用tls=skip-verify、tls=preferred等。这些参数名在不同驱动里叫法不一，但核心思路一致：显式指定加密策略，不要依赖默认值。
5. SSL connection error排查链路：从报错到根因
5.1 ERROR 2026：服务端没开启或TLS版本不对
在论坛和社区里，MySQL SSL相关热词的搜索权重一直很高，尤其是“SSL connection error”和“mysql ssl连接错误”，几乎每周都能看到有人问。最常见的报错长这样：
ERROR 2026 (HY000): SSL connection error: protocol version mismatchprotocol version mismatch（协议版本不匹配）这个说法很有迷惑性。我遇到的大部分情况并不是“TLS协议版本不兼容”，而是服务端SSL压根没配好，或者客户端太老、无法和服务器协商出共同支持的加密套件。
排查第一步永远是回服务端确认状态。登录MySQL执行：
SHOW VARIABLES LIKE 'have_ssl';如果结果是DISABLED，问题大概率出在服务端。回去看错误日志，很大概率是证书路径错误、私钥权限不对，或者证书和私钥不配对。这三个原因占掉一半以上。
5.2 证书验证失败：SAN不匹配与自签名证书
另一类高发问题是证书验证失败。客户端如果指定了--ssl-ca或--ssl-mode=VERIFY_IDENTITY，服务端证书不是由该CA签发、证书过期、SAN里没有客户端连接时使用的主机名或IP，都会导致握手失败。
这时候最实用的验证命令是：
openssl x509 -in /etc/mysql/certs/server-cert.pem -text -noout | grep -E "Not Before|Not After|Subject Alternative Name"我推荐把重点放在SAN上。很多人签名证书时只填了CN，没填SAN，客户端连接时又恰好用了VERIFY_IDENTITY，这种组合在MySQL 8.0客户端里基本必报错。另外要记得核对服务器系统时间，证书有效期校验非常依赖时间，服务器时间偏了，没过期的证书也会被当成过期。
还有一种常见场景：用了自签名证书，客户端没有指定--ssl-ca，只用了REQUIRED。这种写法连接是加密的，但客户端并没有校验服务器身份，等于“防偷听但不防冒充”。如果审计明确要求身份验证，就一定要把CA证书发到客户端并显式指定。
5.3 一条可复现的排查步骤清单
在实际运维中，我会按照下面的顺序来排查，基本不会漏：
- 服务端执行
SHOW VARIABLES LIKE '%ssl%';，确认have_ssl=YES。 - 检查错误日志中是否有证书加载报错，路径、权限、格式逐个核对。
- 用
openssl检查服务端证书有效期和SAN字段是否匹配客户端连接地址。 - 客户端先不带
--ssl-ca，只用--ssl-mode=REQUIRED测试连通性。 - 再逐步加上
--ssl-ca和--ssl-mode=VERIFY_IDENTITY，缩小验证范围。 - 如果客户端版本太老，换最新8.0客户端重试。
- 最后检查MySQL账号是否被
REQUIRE SSL或REQUIRE X509限制。
把报错现象、可能原因和定位动作放在一张表里会更直观：
| 报错现象 | 可能原因 | 优先排查动作 |
|---|---|---|
| ERROR 2026 protocol version mismatch | 服务端SSL未启用或套件不兼容 | 检查have_ssl、错误日志 |
| ERROR 3159 insecure transport prohibited | 服务端强制加密，客户端在明文连接 | 客户端加--ssl-mode=REQUIRED |
| Certificate Verification Failed / Unknown CA | 客户端未指定CA，或服务器证书非该CA签发 | 客户端指定--ssl-ca并核对CA链 |
| Hostname/IP does not match certificate | SAN字段缺失或不匹配 | 检查证书SAN并使用匹配连接地址 |
| bad permission / unable to load key | 私钥权限过宽或属主不对 | chmod 600并chown给mysql用户 |
这张表基本覆盖了日常能看到的大部分SSL连接问题。顺着链路走一遍，十分钟内能定位。
6. 容易被忽略的进阶场景：Docker、主从复制与性能损耗
6.1 Docker挂载证书的几个注意点
现在不少人用Docker跑MySQL，比如docker run或者docker-compose。证书挂载进去的姿势比想象中容易踩坑。最简单可靠的方式是启动时用只读挂载：
docker run -d \ --name mysql-ssl \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=secret \ -v /etc/mysql/certs:/etc/mysql/certs:ro \ -v /etc/mysql/conf.d:/etc/mysql/conf.d:ro \ mysql:8.0这里有两个经验值得分享。
第一，容器内的MySQL配置文件需要把证书路径指向挂载目录，并且要保证容器中mysql用户对私钥文件有读取权限。官方镜像里的mysql用户UID通常是999，宿主机的文件如果属主是root且权限是600，容器里会直接读取失败。我的做法是明确执行：
chown 999:999 /etc/mysql/certs/server-key.pem chmod 600 /etc/mysql/certs/server-key.pem第二，挂载目录用:ro只读模式更安全，证书属于不可变配置，没必要让容器往里写。当初我被docker cp填进去的证书坑过一次，容器重建就丢，后来改成宿主机持久化挂载，一劳永逸。
6.2 主从复制的SSL参数
MySQL主从复制同样支持SSL，原理和普通客户端连接一样，因为从库本质就是一个MySQL客户端。老版本通过CHANGE MASTER TO配置：
CHANGE MASTER TO MASTER_HOST='db-master.example.com', MASTER_USER='repl', MASTER_PASSWORD='secret', MASTER_SSL=1, MASTER_SSL_CA='/etc/mysql/certs/ca-cert.pem';MySQL 8.0.22之后的语法改成了CHANGE REPLICATION SOURCE TO，参数名也变成了SOURCE_SSL、SOURCE_SSL_CA，语义完全相同。如果你的全局配置已经开了require_secure_transport=ON，那么从库连接也必须支持SSL，否则复制线程会一直报连接失败。这个坑比较隐蔽，因为它不会体现在业务查询里，只会在复制状态里静默报错。
6.3 加密后的性能影响到底有多大
不少人对开启SSL有顾虑，觉得加解密会拖慢数据库。实测下来的结论是：影响可控，但要看场景。
TLS握手阶段的开销相对明显，每次新建连接都要做一次非对称加密交换，不过在长连接架构下，这个一次性成本会被摊薄。真正持续占用的是对称加密部分，现代CPU基本都支持AES-NI硬件加速指令，加解密损耗通常很低。我在一个压力测试场景里对比过，开SSL后简单查询的QPS大概下降5%左右，高并发写入场景的延迟也有增加，但远没到“不能忍”的程度。
比较稳妥的策略是先开启SSL支持，观察一段时间业务响应时间，再用require_secure_transport强制加密。如果业务对性能极度敏感，可以只对高安全要求的账号单独设置REQUIRE SSL，普通连接继续走明文，既守住底线又控制成本。根据我个人的经验，绝大多数业务场景其实并不会感知到SSL带来的额外开销，真正需要注意的是证书轮换流程，而不是性能。
配置好SSL之后，还有一个细节值得养成习惯：把证书有效期记录在案，提前一个月设置提醒。毕竟数据库实例的证书一旦过期，所有应用连接会成片报错，那场面比配错任何一个参数都更让人头疼。
