把 Kettle 和 MySQL 的 SSL 加密连接配置搞定，这事我没少折腾。先说结论：如果你所在公司的安全规范已经要求数据库连接必须加密，或者你连接的 MySQL 实例在非信任网络上，那这项配置就不是可有可无的加分项，而是必须项。Kettle（也就是 Pentaho Data Integration）在抽取数据时，默认走的是明文传输，用户名、密码、业务数据全裸奔，只要有人在网络链路上抓包，等于把数据库凭据和数据直接递到别人手里。本篇文章就把我实际配置中走过的完整路线、踩过的坑、以及验证加密是否真生效的方法一次性讲清楚，适合正在做数据平台安全加固、或者刚接手这类任务的 ETL 开发者、数据运维同学参考。

1. 先搞懂 Kettle 连接 MySQL 时 SSL 到底是怎么运作的

1.1 为什么数据库连接需要加密，明文连接的风险在哪

MySQL 客户端和服务器之间的连接，默认情况下是不加密的。这意味着当你从 Kettle 发起一个连接去查数据，SQL 语句、查询结果、甚至登录用的账号密码，都会以可读的明文形式在网络里传输。如果这个网络环境是公司内网，可能风险还算可控；但只要链路经过任何你不完全控制的网络设备——比如跨机房专线、云上 VPC 对等连接、或者带公网跳转的混合网络——被监听的可能性就真实存在。

我见过一个真实的场景，某开发团队在测试环境用 Kettle 连生产库做数据比对，生产库跑在云上，测试环境在本地机房，中间走了专线但没做加密。后来安全团队抓包检查，直接看到测试环境连生产库的密码在报文里以明文出现。这不是故意攻击，就是安全审计时顺手一查就查出来了。从那之后，我就把“能用 SSL 就绝不明文连接”当成了默认原则。

SSL 加密连接做的事，本质上是在 TCP 连接之上再建立一个 TLS 加密通道。握手阶段会协商加密算法、交换证书、生成会话密钥，之后的传输内容全部加密。对于 Kettle 这类 ETL 工具来说，传输的数据量通常不小，加密确实会带来一点 CPU 开销，但这个代价跟数据安全相比，完全可以接受，而且现代服务器上的硬件加速对 TLS 的支持已经很成熟。

1.2 单向认证和双向认证，Kettle 里应该选哪种

MySQL 的 SSL 连接有两种模式：单向认证和双向认证。

单向认证的意思是，客户端验证服务器的身份——服务器出示证书，客户端用自己信任的 CA 证书去校验这个证书是否合法。只要校验通过，客户端就认为服务器是真的，之后开始加密通信。这个模式下，客户端不需要有自己的证书，只需要准备一个信任库，里面放着 CA 证书。

双向认证则在单向认证的基础上，增加了服务器对客户端的验证。客户端也要有自己的证书，连接时主动出示，服务器用 CA 证书来校验客户端的身份。这种方式更严格，能防止有人拿着偷来的账号密码从任意机器登录数据库，但对配置的要求也更高，要维护的东西更多。

对于大多数 Kettle 连接 MySQL 的场景，我个人的建议是：先做单向认证。原因很直接——Kettle 是数据抽取工具，跑批任务的服务器 IP 相对固定，账号密码本身已经有访问控制，再加一层客户端证书，日常维护成本（证书更新、分发、轮转）会明显增加，而且收益边际并不大。单向认证已经能把传输内容加密，防住链路监听这个核心诉求。但如果你们的安全基线要求“账号 + 密码 + 证书”三者缺一不可，那再考虑双向认证。

1.3 看穿 JDBC URL 里 SSL 参数的分工

Kettle 连 MySQL 是通过 JDBC 驱动实现的，而 SSL 的配置本质上是把这些参数以key=value的形式拼进 JDBC URL。很多人配置失败，就是因为对这些参数的理解不到位。

• useSSL=true：告诉驱动启用 SSL，但不强制。如果服务器不支持 SSL，连接可能降级为明文。在 MySQL 8.0 的驱动中，这个参数默认值已经是 true，而在旧版驱动中默认是 false。
• requireSSL=true：强制使用 SSL，如果服务器端不支持加密，直接报错，绝不降级。实际配置时，我建议一定要带上这个参数，避免出现“以为加密了，实际降级明文”的假象。
• verifyServerCertificate=true：校验服务器证书。这个参数必须配合trustCertificateKeyStoreUrl使用，也就是客户端需要有一个信任库来验证服务器证书的有效性。
• trustCertificateKeyStoreUrl和trustCertificateKeyStorePassword：指定信任库的路径和密码，信任库里存的是 CA 证书。
• clientCertificateKeyStoreUrl和clientCertificateKeyStorePassword：双向认证时使用，指定客户端证书库的位置。

理解这几个参数的分工之后，你就知道自己配置到哪一步了：如果只是要加密传输，useSSL + requireSSL 就够；如果要校验服务器身份，必须再加上 verifyServerCertificate 和信任库；如果要双向认证，还要再加上客户端的证书库。Kettle 的图形界面里虽然也有“选项”标签页，但最稳的做法还是把这些参数直接拼进连接 URL 里，后面我会详细说。

2. MySQL 服务端的 SSL 准备：证书生成与开启

2.1 检查当前 MySQL 是否支持 SSL

配置 Kettle 之前，先去看 MySQL 服务器端的情况。MySQL 从 5.7 开始默认编译了 SSL 支持，但是否开启、是否有证书，要连上去查一下才知道。

用命令行登录 MySQL，执行这条语句：

SHOW VARIABLES LIKE '%ssl%';

重点关注几个变量：

• have_ssl：值为YES表示服务器支持 SSL，DISABLED表示支持但没启用。
• ssl_ca：CA 证书路径。
• ssl_cert：服务器证书路径。
• ssl_key：服务器私钥路径。

如果have_ssl是YES，说明已经启用。如果为DISABLED，说明编译时支持，但没有配置证书文件，需要继续做下面的步骤。另外还有一条语句可以看当前连接是否使用了 SSL：

SHOW STATUS LIKE 'Ssl_cipher';

如果返回非空值（比如TLS_AES_256_GCM_SHA384），说明当前会话已经是加密的。空值说明当前连接是明文。

我碰到过一种情况：服务器的have_ssl是YES，但ssl_cert指向的证书文件已经过期了。MySQL 在证书过期后不会主动断开已有连接，但新连接会握手失败。所以检查时不仅要看状态变量，还要看一下证书的实际过期时间。

2.2 用 OpenSSL 生成自签名 CA 与服务器证书

如果服务器没有 SSL 证书，最快的方式是生成一套自签名证书。生产环境里如果公司有内部 CA 或者公共 CA，应该优先用那些正式签发的证书；如果是内部系统、测试环境，或者暂时不想走证书申请流程，自签名完全够用。这里的原理是：我们自己生成一个 CA，再用这个 CA 给 MySQL 签发服务器证书。Kettle 客户端只需要信任这个 CA，就能校验服务器证书。

第一步，生成 CA 的私钥和自签名证书：

openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem -subj "/CN=MySQL-CA"

第二步，生成服务器私钥和证书签名请求：

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

第三步，用 CA 给服务器证书签名：

openssl x509 -req -in server-req.pem -days 3650 -CA ca.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

第四步，验证生成的服务器证书：

openssl verify -CAfile ca.pem server-cert.pem

这里有一个细节要特别注意：生成服务器证书时，/CN的值最好跟数据库服务器的域名一致。因为如果 Kettle 端启用了verifyServerCertificate=true并且 JDBC URL 里配了serverSslCert相关的校验，某些驱动会校验证书的 CN 或 SAN 是否匹配主机名。如果你直接用 IP 连接，建议在证书里加上 SAN 或者干脆用域名连接。否则可能出现证书链校验通过、但因为主机名不符而报错的情况。

证书生成之后，把ca.pem、server-cert.pem、server-key.pem三个文件放到 MySQL 服务器上，比如/etc/mysql/certs/目录，并确保 MySQL 的运行用户有读取权限。私钥文件的权限尤其重要，建议设为 600。

2.3 配置 MySQL 启用 SSL 并创建强制加密账号

有了证书文件，接下来修改 MySQL 配置文件。不同发行版的配置文件路径有差异，通常位于/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf。在[mysqld]段下添加：

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

如果 MySQL 版本较新，也可以使用ssl_ca、ssl_cert、ssl_key的写法，两者等价。

修改完后重启 MySQL：

systemctl restart mysqld

重启后重新检查have_ssl变量，如果为YES，说明服务器端已经启用了 SSL。

但这还不够。如果数据库里的用户没有做限制，客户端连接时仍然可以选择不用 SSL。为了让连接必须走加密通道，可以创建一个限定必须使用 SSL 的账号：

CREATE USER 'etl_user'@'%' IDENTIFIED BY 'StrongPassword123' REQUIRE SSL; GRANT SELECT, SHOW VIEW ON *.* TO 'etl_user'@'%'; FLUSH PRIVILEGES;

REQUIRE SSL这个限制的作用是：这个账号连接时如果没启用 SSL，MySQL 会直接拒绝。这样一来，就算有人拿着账号密码从 Kettle 端忘记开加密，也会因为不符合账号的 SSL 要求而连不上。这个做法可以把“人为配置遗漏”的风险也兜住。

3. Kettle 端配置 SSL：不走弯路的关键步骤

3.1 把 SSL 参数塞进 JDBC URL 的正确姿势

Kettle 的图形界面里，新建数据库连接时会让你填主机名、端口、数据库名、用户名、密码。很多人在这个界面上找 SSL 相关的开关，结果发现不同版本、不同驱动下界面差异很大，有的版本有“选项”标签页，有的版本则需要自己手动加参数。我实测下来最稳定、最通用的方式，是在“数据库名”输入框里直接把参数拼进去。

举个例子，假设数据库名是edw，服务器 IP 是10.10.20.30，那么数据库名那一栏不要只填edw，而是填：

edw?useSSL=true&requireSSL=true&verifyServerCertificate=true&trustCertificateKeyStoreUrl=file:///opt/kettle/truststore/truststore.jks&trustCertificateKeyStorePassword=changeit

这里面的逻辑是：Kettle 拼 JDBC URL 时，会把“数据库名”直接放在连接串的最后面。你在数据库名后面追加?参数，相当于自己控制了 URL 的尾巴。这种方式绕开了界面选项在某些版本上失效的问题。

另外，如果你的 Kettle 版本比较老，自带的是 mysql-connector-java 5.x 驱动，我强烈建议先替换成 8.x 驱动。5.x 驱动对 MySQL 8 服务端的 SSL 兼容性不太好，而且参数名和行为也跟新版有差异。替换方法很简单：下载对应版本的 mysql-connector-java.jar，放到 Kettle 的lib目录下，删除旧驱动，重启 Kettle。

替换驱动后，参数用法也要跟着变。8.x 驱动中useSSL默认已经是 true，而且非 SSL 连接时甚至会主动报错提醒，所以你反而要更注意requireSSL和verifyServerCertificate的搭配。

3.2 客户端信任库的生成与导入

Kettle 端如果设了verifyServerCertificate=true，就必须有一个信任库。信任库本质就是一个 JKS 格式的文件，里面放着你信任的 CA 证书。生成方式用 keytool 命令完成。

在装有 Java 的机器上执行：

keytool -import -alias mysql-ca -keystore /opt/kettle/truststore/truststore.jks -file /path/to/ca.pem -storepass changeit -noprompt

/path/to/ca.pem就是之前生成的自签名 CA 文件。-storepass是信任库的密码，后面在 JDBC URL 里填的trustCertificateKeyStorePassword要跟它一致。

生成后可以查看信任库内容确认：

keytool -list -keystore /opt/kettle/truststore/truststore.jks -storepass changeit

你会看到一个条目，别名是mysql-ca，类型是trustedCertEntry。这说明 CA 已经导入成功。

这里有个常见错误：有人把trustCertificateKeyStoreUrl写成了 CA 证书本身的路径，而不是信任库的路径。JDBC 的这个参数要求的必须是 JKS 或 PKCS12 格式的密钥库文件，不是单个 PEM 证书。我之前就见过有人填file:///path/to/ca.pem，结果连接时驱动直接报错说格式不对。

3.3 用查询状态的方法验证加密是否真的生效

配置完成、测试连接也通过后，不能就此收工——你还需要验证连接确实走的是 SSL。我是这么做的：在 Kettle 里写一个“执行 SQL 脚本”的步骤，里面查一张虚拟表，把 SSL 状态捞出来。

比如在数据库连接测试通过后，新建一个转换，加一个“表输入”步骤，SQL 写：

SHOW STATUS LIKE 'Ssl_cipher';

或者更直接一点，用 JDBC 能执行的查询：

SELECT variable_name, variable_value FROM performance_schema.session_status WHERE variable_name IN ('Ssl_cipher', 'Ssl_version', 'Ssl_session_id');

如果返回结果中Ssl_cipher是非空值，说明 Kettle 当前这个连接确实在 SSL 加密隧道里。如果返回空，说明虽然 Kettle 显示连接成功，但实际还是明文连接，需要回头检查参数配置。

我在实际项目中就一直把这个查询步骤留在测试转换里，每次排查连接问题时先跑一遍，三秒钟就能确认问题是否跟加密有关，比抓包看报文方便多了。

4. 高频踩坑：连接失败的报错对照与解决办法

4.1 SSL 握手失败与证书链不完整

报错信息通常是SSLHandshakeException或者PKIX path building failed。前者多半是服务器端证书有问题，后者基本是客户端信任库不完整。

如果报PKIX path building failed，并且提示unable to find valid certification path to requested target，意思就是客户端信任库里没有对应的 CA 证书。解决办法就是检查 truststore 是否导入了正确的 CA，以及 JDBC URL 里的trustCertificateKeyStoreUrl是否指向了正确的文件路径。

这里还有一个容易忽略的细节：自签名 CA 的证书是有有效期限制的。如果你在生成 CA 时没加-days参数，OpenSSL 默认有效期只有 30 天。等证书过期后，新连接会立刻开始报握手失败。生产环境的自签名 CA，建议生成时直接给 10 年有效期，并在日历里设置续期提醒。

4.2 Public Key Retrieval is not allowed 与 allowPublicKeyRetrieval

这个报错在 MySQL 8 使用 caching_sha2_password 认证插件时很常见。原因是客户端尝试用 SSL 连接但实际没成功，而 caching_sha2_password 在非 SSL 连接下需要先获取服务器的 RSA 公钥。驱动出于安全考虑默认不允许自动获取公钥，就会抛出这个异常。

解决办法有两种，但推荐的方向完全不同。第一种是让连接真正走通 SSL，也就是检查前面所有配置，确保加密连接生效，这是正路。第二种是在 JDBC URL 加allowPublicKeyRetrieval=true，这会让驱动在非 SSL 连接时自动获取公钥——这明显会降低安全性，只适合临时调试。

我个人的习惯是：遇到这个报错先不急着加参数，先回头确认 SSL 为什么没启用。只要 SSL 真正生效，这个报错自然消失。

4.3 时区报错与 TLS 版本不匹配

连接时如果报The server time zone value 'CST' is unrecognized，这跟 SSL 无关，但会挡住后续的 SSL 排查。解决方式是给 JDBC URL 加上时区参数：

edw?serverTimezone=Asia/Shanghai&useSSL=true&requireSSL=true...

还有一个跟 TLS 版本相关的坑：旧版 JDBC 驱动可能默认使用 TLSv1，但 MySQL 8 默认禁用了 TLSv1，导致握手失败。解决办法是替换成 8.x 驱动，或者在驱动支持时显式指定 TLS 版本。新版 mysql-connector-java 会默认协商出合适的 TLS 版本，所以“换驱动”往往是最省事的方案。

4.4 一个常用参数速查表

我把排查时涉及的核心参数整理成一张表，方便对照使用：

每次排查时，按这张表从上到下核对一遍，我能解决的问题基本都能定位。最后一列的值只代表我的推荐，实际要根据你们的 CA 路径、密码、时区设置调整。

我在多次配置里的体会是：Kettle 配 MySQL SSL，难点从来不在“点哪个按钮”，而在于理解 JDBC 驱动参数如何跟服务器端状态联动。只要把 MySQL 那段先确认好——证书有效、账号强制 SSL，再把 Kettle 的 URL 参数补齐、信任库放对位置，整个过程就不会有大坑。最后再多说一句：配置完成后，那个查询Ssl_cipher的习惯一定要养起来，因为 SSL 配置中“看似成功实则明文”的状态太隐蔽了，每次换驱动、换数据库、换服务器，都值得花十秒验证一次。