Java应用配置Oracle双向TLS认证

在数据库安全领域，存在一个普遍的认知偏差：许多开发者认为为Oracle数据库配置了双向TLS认证便已足够安全。然而，现实情况往往更为复杂，尤其是在Java应用与Oracle数据库交互的场景下。Oracle JDBC驱动对“双向认证”的实现逻辑，可能与开发者的预期存在显著差距。

究其本质，以ojdbc为代表的驱动在处理TCPS连接时，仅完成了SSL/TLS层的基础工作：加密通信通道并验证服务器证书。至于客户端证书的发送，驱动本身并未参与。因此，业界常说的“Oracle数据库双向TLS认证”在严格意义上是一个误解。

Oracle JDBC不处理TLS客户端证书发送

查阅Oracle官方文档或直接分析ojdbc源代码，会发现一个关键事实：该驱动并未提供用于指定客户端密钥库（如javax.net.ssl.keyStore）或密钥密码的配置项，也未开放设置SSLContext.init(KeyManager[], ...)的接口。在建立TCPS连接时，驱动仅作为TLS客户端验证服务器证书，自身不会主动发送任何客户端身份凭证。

这导致以下结果：

• 即使在JVM启动参数中配置javax.net.ssl.keyStore与javax.net.ssl.keyStorePassword，JDBC驱动也会忽略这些设置，既不报错也不产生任何效果。
• 配置项oracle.net.ssl_server_dn_match=true仅用于校验服务器证书的CN或SAN字段，与客户端证书无关。
• 典型场景是，即便在数据库的sqlnet.ora中明确设置SSL_CLIENT_AUTHENTICATION = TRUE

实际可行的方案：Wallet与SSL组合认证

那么业务中提到的“Oracle双向认证”通常指什么？实际上，它指的是一条复合路径：首先通过SSL/TLS加密通信通道，然后利用Oracle Wallet中预置的凭证（如ewallet.p12中保存的数据库用户名、密码或签名密钥）完成应用层身份认证。请注意，后一步发生在TLS握手完成之后，与传输层安全协议本身无关。

实施此方案需注意以下要点：

• 必须启用TCPS协议，否则Wallet中的凭证不会被加载，可能引发ORA-28374或ORA-28365等错误。
• Wallet路径不能通过JDBC URL指定，必须通过JVM参数-Doracle.net.wallet_location=/path/to/wallet传入。
• Wallet目录下必须同时存在cwallet.sso（建议权限设置为≤600）和ewallet.p12（确保Java进程有读取权限）两个文件。
• 连接URL需使用完整的Oracle Net语法，例如：
  jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=...)(PORT=...))(CONNECT_DATA=(SERVICE_NAME=...)))

这是目前多数生产环境采用的方案。它实现了“双重认证”，但并非TLS层面的双向认证（mTLS），这一点需明确区分。

实现TLS双向认证需绕开标准JDBC

在极少数对合规性要求极为严格的场景（如金融、政务领域），确实需要在TLS层面实现双向认证。此时，必须考虑放弃直接使用标准JDBC接口，转而采用替代方案。

可行的技术路径通常较为复杂：

• 放弃ojdbc，改用Oracle提供的Oracle Universal Connection Pool (UCP)，并结合自定义的SSLSocketFactory。UCP 21c及以上版本支持通过setConnectionPoolDataSource()方法注入自定义DataSource，但这需要开发者自行处理SSLContext初始化及证书链校验逻辑。
• 更底层的方案是使用Netty、Vert.x等框架直接封装原生TCPS Socket，并在代码中手动注入KeyManager。此路径基本放弃了JDBC标准接口与事务管理能力，仅适用于对数据一致性要求不高的场景。
• 无论采用哪种方案，Oracle监听器（listener.ora）必须配置SSL_CLIENT_AUTHENTICATION = TRUE，且监听器需信任客户端证书的根CA。客户端证书必须由受信任的CA签发，并导入到JVM的trustStore（而非keyStore）中以便服务端识别。
• 此方案无法利用Spring Boot的spring.datasource.*自动配置，需要手动编写连接池初始化Bean并管理所有配置。

尤其需要注意的是：即使成功让Oracle监听器接受了客户端证书，ojdbc驱动也无法获取该证书的任何上下文信息。驱动未提供API来读取已协商完成的客户端证书的Subject或SAN字段。所有基于客户端证书的授权逻辑都必须在数据库侧处理，例如在PL/SQL中调用sys_context('USERENV', 'SSL_CLIENT_DN')来获取客户端证书的可识别名称并进行权限判断。