Kettle连接MySQL启用SSL加密：从证书生成到避坑完整指南-开发者社区

上周安全扫描报告递到手里的时候，我才意识到问题比想象中严重：内网一台机器上跑着的Kettle到MySQL的3306端口，竟然有人在链路上抓到了明文SQL。查了半天根因，问题根本不在什么高深漏洞，就是Kettle默认没有开启MySQL的SSL加密连接。当天我就把整改任务领了，从证书生成、MySQL服务端配置到Kettle侧的驱动参数，完整走了一遍。这篇就是基于那次实操整理出来的，专门写给用Kettle做数据抽取同步、又需要过安全审计或等保要求的朋友。不管你是刚接触Kettle的新手，还是已经被各种SSL报错磨了几个小时的苦主，按下面的步骤走，基本能少踩一半的坑。

1. 先搞清楚Kettle连MySQL时，SSL到底在保护什么

1.1 MySQL SSL连接的握手过程

很多搞ETL的同事一听“SSL”就头疼，觉得这是DBA的事。其实拆开看不复杂。MySQL的SSL加密连接，本质就是客户端（Kettle跑的Java进程）和MySQL服务器在TCP三次握手之后，再做一次TLS握手，协商出一个只有双方知道的会话密钥，之后的通信全部用这个密钥加密。

这个过程你可以在脑子里过一遍：第一次见面互验身份证，验完身份之后商量一个暗号，之后全程用暗号说话。落在MySQL的具体场景里就是客户端向服务端请求建立TLS连接，服务端把自己的数字证书发给客户端，客户端要么用系统信任库里的CA，要么用连接参数里指定的CA去验证这张证书的真伪，验证通过后双方协商加密算法，生成会话密钥。

MySQL从5.7开始其实是默认支持SSL的，甚至服务端一旦配置了SSL相关证书，新连接会自动协商TLS。这里有个常见误区：服务端支持SSL，不等于客户端一定走SSL。到底走不走、走的话严格到什么程度，完全取决于客户端驱动里的sslMode配置。Kettle默认不自带这个参数，所以很多环境里服务端明明开了SSL，Kettle的连接还是明文。

1.2 “结果集加密”是错觉：Kettle的SSL边界在哪里

有一个认知必须先摆正：SSL加密的是Kettle这台机器到MySQL服务器之间的网络传输链路，而不是MySQL表空间里的数据，更不是Kettle后续把数据推到目标库的那段链路。

如果你的Kettle转换是“MySQL源库 → 目标库”，你要搞清楚的是：源连接要配一套SSL，目标连接也要单独配一套SSL。两边是两条独立的链路，各管各的，不存在一个“全局加密开关”能把你整条数据链路的网都包住。

再一个容易误解的点是“结果集”。Kettle跑批时，执行SELECT、INSERT这些SQL语句本身要走网络，大批量的结果集也一样要走网络。只要驱动配置的是高等级的sslMode，这批流量全部是密文。反过来，如果你用的还是老版本驱动，比如Kettle 8.x自带的mysql-connector-java 5.1.x系列，默认行为可能是useSSL=false的隐式状态，那Kettle在客户端上发出的SQL就是明文的，结果集同样也是明文的。

所以，别以为登录密码传输能加密就够了。MySQL客户端做账号认证时，密码本身有单独的加密机制，但SQL语句、查询结果这些真正敏感的数据，如果没有SSL，全都是在网络里裸奔的。

1.3 什么场景必须上SSL

这个不是玄学，是安全评估时的实际考量。下面是我整理的常见场景判断表，基本覆盖了现实中会遇到的情况：

场景	我的建议
Kettle所在机器与MySQL跨公网、跨机房、混合云互通	必须开SSL，并且建议用VERIFY_CA以上级别
等保、金融、行业合规审计明确要求传输链路加密	必须开SSL，审计报告里要能拿出证据
同一机房，但网络属于多租户共享、有被抓包风险	强烈建议开，代价很小
Kettle和MySQL都在同一台机器（localhost）	可以不开，本机回环流量出不了网卡
独立封闭内网VLAN，网络设备和管理都可控	视风险评估，能开还是开，省得以后补课

顺带提醒一句，安全合规不只是“防外部攻击”，很多时候是“防内网横向嗅探”。明文流量的风险，往往就来自内部某台机器被攻破后的进一步动作。这一步省下来的成本，可能远低于后面一次数据泄露事故的代价。

2. 服务端准备：证书签发、MySQL启用与账号约束

2.1 用自建CA签出一张能被Kettle信任的服务端证书

生产环境用云厂商的托管数据库，通常证书直接在控制台下载，不用自己动手签。但自建MySQL或者测试环境，最常见的做法是自己做一个私有CA，然后用这个CA签服务端证书。这样做的核心好处是：客户端只需要信任那一张CA证书，就能校验所有由这个CA签发的服务端证书，后续轮换服务端证书都不用动客户端。

整个过程用OpenSSL完成，大概四步。

第一步，生成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=my-private-ca"

第二步，生成MySQL服务端的私钥和证书签名请求（CSR）：

openssl req -newkey rsa:2048 -nodes \ -keyout server-key.pem -out server-req.pem \ -subj "/CN=mysql-server"

第三步非常关键，千万别漏：生成证书请求时一定要带上SAN（Subject Alternative Name），也就是把Kettle连接MySQL时实际使用的主机名或IP地址写进去。否则后面用VERIFY_IDENTITY做主机名校验时，会直接报错。

cat > san.cnf <<'EOF' [v3_req] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = mysql.internal.example.com IP.1 = 10.10.0.5 EOF

第四步，用CA签发出服务端证书：

openssl x509 -req -in server-req.pem -days 3650 \ -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 \ -out server-cert.pem -extfile san.cnf -extensions v3_req

签出来的三个文件要落到MySQL服务器的目录里：server-cert.pem是服务端证书，server-key.pem是服务端私钥，ca-cert.pem是CA证书。建议统一放在/etc/mysql/ssl/下，并且把私钥权限收一下，通常是chown mysql:mysql + chmod 600，不然MySQL进程可能读不了，启动时直接报错或者打了告警日志你都没察觉。

2.2 MySQL开启SSL并强制账号使用加密

服务端证书就位后，在MySQL配置文件my.cnf的mysqld段里加三段路径：

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

重启MySQL之后验证是否真的加载了SSL：

SHOW VARIABLES LIKE 'have_ssl';

正常情况下这个值应该是YES。如果还是DISABLED，别急着往下走，先回去查文件权限、路径拼写和MySQL错误日志。这一步没确认好，后面所有配置都是空中楼阁。

服务端SSL生效之后，如果只是“支持加密”，MySQL还是允许账号用明文连接的。要强制指定账号必须走SSL，就执行：

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

改成这样之后，凡是这个账号发起的非SSL连接都会被MySQL直接拒绝。这个动作我建议做，因为测试环境经常有人漏配客户端，你会发现少了这个约束，很多人会不知不觉继续用明文连上，等于安全整改白做了。

2.3 JVM信任库与驱动版本这两个边角

Kettle本体是Java程序，所以还牵涉两个容易忽略的边角。

第一个是JVM信任库。如果你打算在Kettle里用VERIFY_CA或VERIFY_IDENTITY，就必须让Kettle的Java进程信任你自建的CA证书。老版本的MySQL Connector/J 5.1.x没有sslCA这种友好参数，只能走Java系统信任库，操作就是：

keytool -importcert -alias mysql-ca \ -file /etc/mysql/ssl/ca-cert.pem \ -keystore $JAVA_HOME/lib/security/cacerts \ -storepass changeit -noprompt

但是用Connector/J 8.0.x系列就灵活得多，连接URL里可以直接指定sslCA指向CA证书文件，相当于驱动单独信任这个CA，不污染JVM全局信任库。我强烈推荐这种做法，尤其是Kettle有多个环境引用不同CA的时候，全局信任库会把你绕晕。

第二个边角是驱动版本。Kettle 9.0自带的还是mysql-connector-java 5.1.x系列，拿来连MySQL 8.0会遇到一堆兼容问题，包括但不限于时区报错、caching_sha2_password认证插件不识别等。我当时的做法是直接把Kettle自带的旧驱动卸掉，换成mysql-connector-java 8.0.33。驱动放哪个目录和Kettle版本有关：Kettle 8.x一般是libext/JDBC目录，Kettle 9.x之后统一放在lib目录下。换完驱动必须重启Spoon，否则加载的还是老的。

3. Kettle侧的配置实操：选项页签与自定义URL

3.1 入口一：在“选项”页签里透传JDBC参数

Kettle配置数据库连接时，界面上的“选项”页签是很多人没注意到的入口。它的本质是把你在表格里添加的键值对，原封不动地透传给底层JDBC驱动。也就是说，MySQL Connector/J支持的所有连接参数，都可以在这个页签里维护。

在数据库连接窗口里选择MySQL类型，填好主机名、数据库名、端口、用户名、密码之后，切到“选项”页签，添加下面几个键值对：

参数	值
sslMode	VERIFY_CA
sslCA	/etc/mysql/ssl/ca-cert.pem

这里注意一个细节：不同Kettle版本的“选项”页签位置不太一样，9.x里有时是个小标签，需要在连接对话框中切换视图才看得到。我当时第一次找这个页签就找了半天，最后才确认它不是固定的Tab，而是需要点一下才展开的面板。填好之后点“测试”，看到连接成功再保存。

“选项”页签的好处是直观，不用拼一长串URL。坏处是参数多了不好维护，而且有些版本对参数名大小写敏感，比如sslMode写成了SSLMODE，驱动不认，还不会报错，只是悄悄退回明文。

3.2 入口二：用自定义连接URL一次性写全

如果你想对连接行为有完全的控制力，或者需要在多个环境之间复制配置，更推荐用自定义连接URL。在Kettle的MySQL连接界面里，选中“自定义连接URL”单选项，然后填下面这种完整的形式：

jdbc:mysql://10.10.0.5:3306/etl_db?sslMode=VERIFY_CA&sslCA=/etc/mysql/ssl/ca-cert.pem&socketTimeout=60000&connectTimeout=10000

逐个参数说清楚：

sslMode=VERIFY_CA：强制启用SSL并验证CA证书。
sslCA=/etc/mysql/ssl/ca-cert.pem：指定CA证书文件，让驱动直接信任这个CA。
connectTimeout和socketTimeout：建议都写上，尤其在网络抖动明显的跨机房环境里，没有超时的话Kettle很容易一直挂着，作业调度被卡住。

如果Kettle所在机器上Java进程和MySQL之间还有负载均衡或者域名映射，URL里的主机名一定要和证书SAN里写的保持一致。你是用IP连的，证书里就要有对应IP的SAN项；用域名连的，证书里就要有对应DNS的SAN项。

3.3 sslMode四个档位到底该怎么选

这是整个配置里最容易让人纠结的地方。MySQL Connector/J 8.x的sslMode有四个档位，区别我整理成了表：

档位	行为	适用场景
PREFERRED	服务端支持TLS就加密，不支持就自动退回明文	开发环境、对安全无要求。不推荐用于生产
REQUIRED	必须加密，但不校验服务器证书真伪	能防窃听，防不了中间人攻击
VERIFY_CA	必须加密，且校验服务器证书是否由受信CA签发	自建CA、私有环境的标准选择
VERIFY_IDENTITY	在VERIFY_CA基础上，再校验主机名与证书SAN匹配	严格合规，Kettle连接域名/IP稳定时适用

我给出的建议是：合规场景下VERIFY_CA打底，如果你的网络架构稳定、证书SAN覆盖到位，直接上VERIFY_IDENTITY，最严格，审计时也最好看。REQUIRED这个档位看着好像很安全，实际上只是“加密了但不知道对面是谁”，省不掉证书验证，我基本不推荐，除非你实在搞不定证书，先把链路从明文改成密文再说。

还有一个小细节：SSL和Kettle的连接池可以一起开。Kettle的数据库连接“高级”页签里有连接池配置，把初始池大小和最大池调高一点，批处理场景下能明显减少反复握手带来的额外开销，这一点放到后面性能部分再说。

4. 踩坑记录：从“连接都点不通”到稳定跑批的排障过程

4.1 Public Key Retrieval is not allowed的连锁反应

我配置过程中第一个遇到的报错，其实还不是SSL本身的错，而是Kettle的MySQL连接里很经典的“Public Key Retrieval is not allowed”。

现象很统一：Kettle里点“测试”，连接直接失败，弹窗把这句话原样丢给你。我当时第一反应是SSL配错了，排查了半天发现不是。

这个报错的根源在MySQL 8.0的默认认证插件。MySQL 8.0开始默认用caching_sha2_password，客户端第一次认证的时候需要向服务端获取RSA公钥。如果连接没有走SSL，MySQL默认不允许客户端直接拉取公钥，于是就需要你在连接URL里显式加上allowPublicKeyRetrieval=true，驱动才会自动取公钥。

排查链路可以这么梳理：先查驱动版本（是否还是老5.1.x），再查账号的认证插件：

SELECT user, host, plugin FROM mysql.user WHERE user='kettle';

如果结果是caching_sha2_password，再确认连接URL里是否带了SSL参数。这里最容易绕进去的一个点是：允许公钥检索是非SSL连接下的补救措施，一旦你把SSL真正配好了，这个参数其实是不需要的，因为认证过程中的密钥交换会走加密通道。所以在最终生产配置里，我建议把allowPublicKeyRetrieval去掉，保持SSL连接参数纯净，也逼着自己确认链路确实已经加密了。

4.2 SSL connection error 2026：证书与权限排查

第二个坑是报错误号2026，当时真是把能试的都试了一遍。

现象比第一个更扎心：明明按文档配好了所有SSL参数，测试连接时MySQL直接回一句“SSL connection error: unknown error number 2026”。我最初直觉是证书文件内容出了问题，但反复检查证书没问题，后来才发现罪魁祸首是私钥文件权限——MySQL进程根本没权限读私钥，SSL功能根本没真正生效。

完整的排查顺序应该是这样的，按这个顺序来能快速定位：

先在MySQL服务端确认have_ssl变量是否为YES，不是的话后面全别看了。
再看MySQL错误日志，找“SSL error”或者“cannot load certificate”这类关键字。
检查证书、私钥、CA三个文件的属主和权限，私钥至少要保证mysql用户能读。
确认账号确实被REQUIRE SSL约束，同时客户端连接URL中的sslCA指向了正确CA路径。
最后，如果你是用Kettle所在机器的Java版本较新，而MySQL比较老（比如5.6、5.7），有可能遇到“No appropriate protocol”的报错，这是Java 11以后默认禁用了TLSv1/TLSv1.1协议。补救方式是连接URL加enabledTLSProtocols=TLSv1.2，或者直接把MySQL的TLS配置提升到TLSv1.2以上，后者更治本。

顺带说一句，别小看证书文件权限这一点，很多自建MySQL的SSL故障都出在这里。你配好CA、证书、私钥之后，最好先用命令行客户端连一次试试，确认能正常走SSL，再回去找Kettle的事。

4.3 主机名校验失败和驱动不生效这两个衍生坑

把2026解决之后，我以为大功告成，结果用了VERIFY_IDENTITY又炸出一个报错：证书的主机名校验不过。

原因是Kettle连接MySQL用的主机名（或IP），和证书SAN里写的名字对不上。比如连接URL写的是10.10.0.5，但证书SAN里只写了DNS域名。解决办法是重新生成证书，把SAN写全，DNS和IP都放进去。这也是我在2.1里专门强调SAN的原因。

还有一个衍生坑出在驱动加载上。有些环境里，你把8.0.x驱动放进lib目录了，Kettle却还是启动老驱动。我当时换完驱动发现连接配置还是旧的行为，后来排查才明白：lib目录下旧jar没删干净，或者Kettle的驱动扫描缓存没刷新。解决方法是把旧的connector jar删掉，重启Spoon，必要时清一下临时目录。

5. 加密是否生效，用数据说话

5.1 在MySQL服务端确认会话的Ssl_cipher

配置完别急着收工，先验证加密真的生效了。最直接的方法是从MySQL服务端看当前会话的加密状态。

用Kettle跑一个最简单的转换（比如执行一次SELECT），然后在MySQL里执行：

SHOW STATUS LIKE 'Ssl_cipher';

如果返回的结果不是空值，而是一串类似AES256-GCM-SHA384这样的加密套件名称，就说明当前这个会话确实走的是加密连接。如果结果是空字符串，说明这个连接是明文的，配置还是有问题。

在连接池场景下要注意，Kettle可能同时维持多个后端会话，SHOW STATUS查的是当前所在的这一个会话。想看得更全，可以查这张表：

SELECT s.PROCESSLIST_ID, s.VARIABLE_VALUE FROM performance_schema.session_status s WHERE s.VARIABLE_NAME = 'Ssl_cipher';

这样能看到所有会话各自的加密状态，方便确认Kettle连接池里的连接全都加密了。

5.2 抓包看TLS握手，直接证明没有明文SQL

对于要过安全审计的场景，服务端变量可能还不够有说服力，最好直接用抓包工具验证链路。

在Kettle所在机器上，对MySQL的3306端口做一下流量抓取：

tcpdump -i eth0 host 10.10.0.5 and port 3306 -w kettle_ssl.pcap

然后跑一个Kettle转换，抓个几十秒，停止抓包。用Wireshark打开pcap文件，过滤规则输入tls，你会看到TLSv1.2或TLSv1.3的ClientHello、ServerHello、EncryptedHandshakeMessage这些记录。这就证明了连接开始时就协商了TLS加密。想更直观的，可以再在后面对比一下：不配SSL的时候抓包，直接能看到明文的SELECT语句字符串；配了SSL之后，payload全是密文，搜不到任何SQL关键字。

我当时把这两份抓包截图放进了安全整改报告里，审计那边看了直接就通过了。

5.3 SSL对ETL批导性能的影响实测

很多人担心加了SSL之后性能下降。我在测试环境用一张200万行的表做全量抽取对比过，明文连接和VERIFY_CA连接各跑几遍，结论是：对于Kettle这种以批量操作为主的ETL场景，性能影响基本可以忽略。

耗时上的差别大概在1%到3%之间，主要开销来自TLS握手。握手过程是一次性成本，Kettle跑一个长时间的批处理，握手开销摊到整个任务里几乎可以忽略。如果任务特别多、连接频繁开关，握手成本就会累积，这时候最有效的办法就是开连接池，复用连接而不是反复握手。

CPU方面，现在的服务器基本都有AES-NI硬件加速，TLS传输阶段的加解密对CPU的占用很小。真正需要担心的是那种大量短事务、高频写入的场景，SSL的额外CPU开销才会变得明显。Kettle这种批导工具，说实话不用担心这个。

6. 上线之后还要管的几件事：轮换、维护与“能不能不上SSL”

6.1 证书到期的轮换流程

SSL配置完之后，千万别把这件事忘了，证书是会过期的。自签CA的证书有效期我建议设置得长一点，比如十年，但服务端证书建议两三年一换。日常运维里常见的问题就是：证书到期了，Kettle作业大面积连接失败，主因是被MySQL的REQUIRE SSL拦住了。

轮换分两种情况：

第一种是只换服务端证书，CA不变。Kettle侧什么也不用动，因为客户端信任的是CA，服务端证书到期换新，只要新证书还是同一个CA签的，客户端自然信任。MySQL侧替换证书文件、重启MySQL，完事。

第二种是CA也换了。这时候Kettle连接URL里的sslCA要指向新CA文件，如果是走JVM信任库的，还要重新keytool导入新CA。我建议把CA文件路径统一放在固定目录，比如每台机器上的/etc/kettle/ca-cert.pem，轮换时只覆盖文件，连接配置里的路径不用变，减少操作失误。

6.2 替代方案评估：SSH隧道、内网隔离与云数据库TLS

如果因为种种原因暂时配不了SSL，还有几条路可以缓解风险，但要分清主次。

一是SSH端口转发。思路是先把MySQL的3306端口通过SSH映射到Kettle所在机器的本地端口，Kettle连接localhost的映射端口。好处是配置简单，不用动证书；坏处是多了一跳，网络故障面变大，而且跳板机本身成为新的单点。这算“明文的临时救火方案”。

二是内网隔离。把Kettle和MySQL放进同一个受控VLAN，用防火墙规则限制访问来源端口。能显著降低被外部嗅探的风险，但在严格的安全审计面前，内网隔离不能替代传输加密。审计要的是链路加密的证据，不是“我们觉得内网很安全”。

三是云上的托管数据库。现在主流的云RDS全部支持开启TLS，证书在控制台一键下载，Kettle侧配置方式和自建一模一样。如果你们用的是云RDS，强烈建议直接开这个能力，省掉自己维护证书生命周期的一大摊事。

6.3 我的最终建议与维护检查清单

配置Kettle连MySQL的SSL加密连接，说难不难，说简单也有一堆细节。我最终用的是VERIFY_CA加sslCA文件指定，没有动JVM全局信任库，维护成本最低。版本组合上，MySQL 8.0.33、Kettle 9.3、mysql-connector-java 8.0.33，这组搭起来很稳。

最后分享一个我自己的习惯：每次改完Kettle连接配置，不要只点一次“测试”就走了。测试只能证明“能连上”，不能证明“走的是加密”。我一般测完会再到MySQL里看一眼Ssl_cipher，或者直接抓一段包确认一下。把这一步固化成检查习惯，基本就不会再让明文连接溜过去了。

下面这个小表是我贴在不同环境服务器上的自检清单，供你参考：

检查项	操作	目的
MySQL SSL是否开启	SHOW VARIABLES LIKE 'have_ssl'	确认服务端支持
账号是否强制SSL	SELECT user, host, ssl_type FROM mysql.user	防止明文连接继续存在
客户端连接模式	连接URL或选项页签中的sslMode	确认不是PREFERRED兜底
连接加密是否真实生效	SHOW STATUS LIKE 'Ssl_cipher'	确认当前会话加密中
证书有效期	openssl x509 -in server-cert.pem -noout -dates	提前安排轮换