oracle jdbc驱动不支持真正mtls，因其未实现keymanager注入与certificaterequest响应，仅支持ssl加密通道+wallet凭据认证；所谓“双向”实为应用层认证，非tls层双向证书交换。
Oracle 19c 不支持 TLS 层的双向证书认证（mTLS），所谓“双向验证”实际是 SSL 加密通道 + Wallet 凭据认证的组合，不是客户端发证书、服务端校验的真正 mTLS。
为什么 Oracle JDBC 驱动无法实现真正的双向 TLS
ojdbc 驱动在 TCPS 连接建立时只做单向服务器证书校验，既不读取 javax.net.ssl.keyStore，也不参与 TLS 握手中的 CertificateRequest 响应。即使数据库侧设置了 SSL_CLIENT_AUTHENTICATION = TRUE，驱动也完全忽略——它压根没有实现 KeyManager 注入路径。
常见误操作包括：
- 在 JVM 启动参数里加
-Djavax.net.ssl.keyStore=...，但连接仍走明文或报ORA-28374: Cannot load wallet - 在
sqlnet.ora中配了SSL_CLIENT_AUTHENTICATION = TRUE，但 Java 应用连上去后sys_context('USERENV', 'SSL_CLIENT_DN')返回空值 - 抓包看到 TLS Client Hello 没有
Certificate消息段，证实客户端根本没发证书
Java 应用能做的“类双向认证”实操路径
这是生产中唯一稳定可用的方式：用 TCPS 建立加密通道，再靠 Wallet 里的用户凭证完成强身份绑定。
-
orapki wallet create -wallet /path/to/wallet -pwd WalletPass123! -auto_login，主备库各自生成本地 Wallet，-dn必须匹配本机hostname -f输出 - Wallet 目录下必须同时存在
cwallet.sso（权限 ≤600）和ewallet.p12，Java 进程需有读权限 - JVM 启动时强制传入：
-Doracle.net.wallet_location=/path/to/wallet，不能写在 JDBC URL 里 - 连接字符串必须用完整 Net 语法：
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=dbhost)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=ORCL))) - 确保数据库已启用 TCPS 监听，且
LOG_ARCHIVE_DEST_n等归档参数也指向 TCPS 别名，否则静默降级为 TCP
真要 mTLS？得绕开 JDBC 栈
如果合规审计明确要求 TLS 层双向证书（比如等保三级对国密 mTLS 的硬性条款），ojdbc 就不是可选项。
- 改用 Oracle Universal Connection Pool（UCP），配合自定义
SSLSocketFactory注入KeyManager，但会丢失标准 JDBC 事务语义和部分连接池特性 - 用 Netty 或 Vert.x 封装原生
SSLSocket，手动处理 Oracle TNS 协议帧，代价是重写整个网络通信层 - DBA 侧必须同步配置
SSL_VERSION = 1.2、WALLET_LOCATION绝对路径一致、监听器独立启用(PROTOCOL=TCPS)，任一环节错位都会导致ORA-12537或ORA-12547
真正容易被忽略的是：Wallet 不是“配一次就全局生效”的组件——它按实例隔离，CDB/PDB 场景下每个容器都要单独指定 encryption_wallet_location；而 Java 应用一旦启动，oracle.net.wallet_location 就锁定，改配置必须重启 JVM。
