MySQL JDBC 连接出现下面的警告时，连接可能已经建立，但服务器身份验证并没有按预期完成：

WARN: Establishing SSL connection without server's identity verification
is not recommended.

让警告消失不等于修复安全问题。把 useSSL 设为 false 会改变连接保护条件，不是补上证书和主机名验证。

把三层要求分开

  1. 加密：客户端与服务端是否实际协商了 TLS。
  2. 信任链：服务器证书是否能追溯到受信任签发者。
  3. 身份：证书中的身份是否与期望连接的数据库主机匹配。

只保证加密，仍可能连接到不该信任的服务器；只看到 useSSL=true，也不能直接断言三项都已满足。

按 Connector/J 版本解释配置

Connector/J 8.0.13 起引入 sslMode。官方文档区分以下常用模式：

sslMode要求
REQUIRED要求 TLS，但不验证服务器证书身份
VERIFY_CA要求 TLS，并校验证书信任链
VERIFY_IDENTITY在信任链校验之外，还检查主机身份

PREFERRED 可尝试 TLS 但允许回退，不适合用来表达“必须加密且验证身份”的要求。旧版 useSSL、requireSSL、verifyServerCertificate 与新属性的关系应按实际驱动文档检查，不把新属性直接贴到不支持它的旧驱动中。Connector/J TLS 说明

使用能表达真实安全要求的连接目标

对于支持 sslMode 的驱动，如果需求是验证指定主机身份，连接地址的意图可以写成：

jdbc:mysql://db.example.com:3306/app?sslMode=VERIFY_IDENTITY

域名和库名仅为示意，不包含密码。这条 URL 本身不是完整部署配置：还需要受信任的 CA 材料、正确的证书身份、兼容的客户端与服务端 TLS 配置。凭据和信任库设置应使用实际部署中的受保护配置机制，不写进公开连接串。

用 IP 访问时，也要考虑证书是否包含对应的 IP 身份；不能通过关闭主机校验解决名称不匹配。

从真实应用连接验证

记录驱动和服务端版本，用应用实际使用的主机名连接，再检查证书链和主机匹配。成功会话可查看 TLS 协商信息，例如在该会话执行：

SHOW SESSION STATUS LIKE 'Ssl_cipher';
SHOW SESSION STATUS LIKE 'Ssl_version';

非空密码套件能提供已协商加密的线索，但它不证明客户端验证了正确的服务器身份。最终还要核对有效的驱动配置和证书材料，并验证证书不可信或主机不匹配时连接确实失败。不要改成“信任所有证书”来绕过失败。