tomcat6 sqlnet加密失败

Question

最近继承了一个旧的Java代码库，该代码库与Apache一起使用tomcat6，并且正在尝试设置一个dev环境。当通过前端JSP登录屏幕调用DriverManager.getConnection()时，我得到了ORA-12649代码(“未知加密或数据完整性算法”)。

有许多事情没有道理：

1. 我们已经在运行Oracle11gR2的目标db上实现了加密(通过slqnet.ora中的设置)，它可以处理相同代码库的生产版本；它还可以处理传入sqldeveloper连接等；基本上，数据库端的加密实现没有问题。
2. 开发代码库与生产代码库完全相同(此时)。
3. 开发tomcat6安装与生产安装版本相同。
4. 如果我将连接器指向另一个未实现加密的db，则授权将成功使用有效的用户名和密码。

在深入阅读了Oracle文档和论坛之后，tomcat6文档(特别是它处理CLASSPATH变量的复杂方式)出现了空白。

我的预感是，dev系统上的tomcat6安装没有引用正确的jar文件，即使我在tomcat文件夹中有ojdbc6.jar文件。根据Oracle的说法，让ojdbc6.jar可用应该只适用于从瘦客户端实现这种加密，这就是实现tomcat应用程序的方式。

下面是在客户端实现加密的方式；这样编译时不会出错：

...
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_LEVEL,
    AnoServices.ANO_REQUIRED);
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_ENCRYPTION_TYPES,
    "( " + AnoServices.ENCRYPTION_AES256 + "," +
           AnoServices.ENCRYPTION_3DES168 + "," +
           AnoServices.ENCRYPTION_AES192 + " )");

// require the use of the SHA1 algorithm for data integrity checking
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_LEVEL,
    AnoServices.ANO_REQUIRED);
prop.setProperty(
    OracleConnection.CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPES,
    "( " + AnoServices.CHECKSUM_SHA1 + " )");
...

以下是数据库端的sqlnet.ora文件中的相关行，已知可用于多个客户端：

SQLNET.ENCRYPTION_SERVER=required
SQLNET.ENCRYPTION_TYPES_SERVER=(AES256,AES192,3DES168)
sqlnet.crypto_checksum_server=required
sqlnet.crypto_checksum_types_server=(SHA1)

这是应用程序目录中tomcat的web.xml文件中使用的db url：

jdbc:oracle:thin:@<my_db_name>:1521:<my_db_sid>

我的context.xml文件实现了'allowLinking‘特性，不确定这是否有区别，但这是不标准的，所以我将详细介绍一下。这允许我在tomcat的<webapps>文件夹中提供一个符号链接，指向我的回购中的正确位置。目录权限没有问题，因为tomcat正在从该位置为页面提供服务。

<Context path="/<my_app_name>" allowLinking="true">

Answer 1

在servlet编译期间，CLASSPATH中引用的ojdbc6.jar文件似乎与tomcat6引用的ojdbc6.jar文件不同。我的工作假设是，任何名为"ojdbc6.jar“的文件的内容都是静态的，但显然我错了！(有人能确认Oracle是否确实发布了名为"ojdbc6.jar“的文件的不同版本吗？我找不到任何证据证明他们是这样做的。

在花费了更多时间之后，我确信问题在于使用的驱动程序版本，即使jar文件名在所有实例中都是"ojdbc6.jar“。所以，我使用md5sum来确认两个.jar文件是相同的，当然，它们不是！因此，我从Oracle重新下载了ojdbc6.jar，并将其复制到需要它的两个位置，重新编译了servlet类，并重新启动了tomcat6。在加密的连接上登录没有错误。

因此，在过去，似乎有人有过将ojdbcX.jar文件的旧版本/无效版本重命名为ojdbc6.jar的宏伟想法。我甚至不想知道为什么。:)