We have a client application running on IBM ZOS that connects via JDBC to Oracle DB running on a Linux box.
This legacy client works just fine on a normal TCP/IP unencrypted port.
We want to use ZOS's AT-TLS to implement an encrypted connection. AT-TLS implements rules in the ZOS TCP/IP stack that adds TLS encryption without the client knowing about it or needing any application changes.
Having set up the relevant AT-TLS rule and certificate chain etc, we can see from an AT-TLS trace that when the jdbc connection is attempted, the rule is triggered and the handshaking occurs as expected. There are no error reported by AT-TLS, but the jdbc connection fails with:
ava.lang.ClassCastException: oracle.net.nt.TcpNTAdapter incompatible with oracle.net.nt.TcpsNTAdapter
This makes no sense, as the whole point of AT-TLS on ZOS, is that it masks all the SSL stuff from the application? It appears that while AT-TLS has done the handshaking and set up the encryption, somehow the jdbc driver ‘sees’ it is an encrypted connection and thinks it should be using the TCPS adaptor, which it is not and should not.
We have confirmed the SSL connection to Oracle works fine from within our network - we can connect using a tool like SQL Squirrel using the same SSL port.
We have tried different versions of the jdbc driver - current is ojdbc17.jar.
We've played around with some of the more obscure AT-TLS parameters, but they should not impact this - and have not.
Anyone done/seen anything similar or have any thoughts?
Thanks