Tuesday 27 September 2011

Securing a thin client from WAS to Oracle

My current client is a large user of WAS and Oracle but had not until a few weeks ago set up any SSL connections between the 2 of them. When I came to do this there appeared to be very little documentation on turning on SSL for a thin client and the little I did find tended to be more about coding within an application than within an application server.

This blog proved a useful starting point:

http://blog.anowak.net/2009/09/configuring-encrypted-connection.html

However, it still didn't appear to work.

After a fair bit of testing and tracing it turns out it was in fact the oracle.net.ssl_version setting mentioned in Artur Novaks blog that resolved the
issue in the end but it appeared the negotiation of the SSL version between WAS and Oracle does not work as documented.

I am not sure if this how WAS and Oracle communicate at all versions or if it was just our specific set up.

We had enabled SSL on our Oracle DB which was running version 11.1.0.7.
Within our WAS server we had the latest ojdbc5 driver file which was v
11.2.0.2. The WAS version we were running was 6.1.0.31


Within the oracle DB, the SSL version was left unspecified which by default should have meant that the highest level of SSL should have been negotiated - starting at TLSv1, then SSLv3 and then SSLv2. Or at least that was how I read it in the Oracle documentation.

By setting the custom property in WAS to have a trust store but no ssl version specified we got the following error:

[23/09/11 14:11:13:593 BST] 0000002f DataSourceCon E DSRA8040I: Failed to connect to the DataSource. Encountered "": java.sql.SQLException: IO Error: The Network Adapter could not establish the connectionDSRA0010E: SQL State = 08006,
Error Code = 17,002

followed by

Caused by: oracle.net.ns.NetException: The ssl protocol specified is not
supported.
at
oracle.net.nt.TcpsConfigure.configureVersion(TcpsConfigure.java:181)
at
oracle.net.nt.TcpsNTAdapter.setSSLSocketOptions(TcpsNTAdapter.java:188)
at oracle.net.nt.TcpsNTAdapter.connect(TcpsNTAdapter.java:138)
at oracle.net.nt.ConnOption.connect(ConnOption.java:123)
at oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:353)
... 101 more
Caused by: java.lang.IllegalArgumentException: SSLv2Hello
at com.ibm.jsse2.mb.a(mb.java:30)
at com.ibm.jsse2.lb.(lb.java:4)
at com.ibm.jsse2.jc.setEnabledProtocols(jc.java:570)
at
oracle.net.nt.TcpsConfigure.configureVersion(TcpsConfigure.java:177)


So for some reason TLS and SSL v3 were not tried.

I then tried WAS set to oracle.net.ssl_version=3.0 but that resulted in the following:

[23/09/11 14:12:36:529 BST] 00000031 DataSourceCon E DSRA8040I: Failed
to connect to the DataSource. Encountered "": java.sql.SQLException: IO Error: Received fatalalert: handshake_failureDSRA0010E: SQL State = 08006, Error Code = 17,002

But I didn't get much more in any of the standard output files so I turned on tracing with SSL=all and a custom property on the jvm of javax.net.debug
showed me the handshake going on. These couple of lines show WAS reading sslv3 but receiving a TLSv1 format but then going straight into a failure.

[23/09/11 14:16:42:389 BST] 00000033 SystemOut O WebContainer : 0, READ: SSLv3 Alert, length = 2
[23/09/11 14:16:42:390 BST] 00000033 SystemOut O WebContainer : 0, RECV TLSv1 ALERT: fatal, handshake_failure


So it appears Oracle was sending a handshake as TLSv1, WAS was expecting this in SSLv3 format, but rather than negotiating to use sslv3 it just gives us the handshake error.

Setting the SSL version to TLSv1 wasn't documented so I just set:

oracle.net.ssl_version=1.0;

and this worked as you see WAS reading TLSv1

[23/09/11 14:19:10:891 BST] 00000033 SystemOut O WebContainer : 0, READ: TLSv1 Handshake, length = 97

as well as allowing me to run a successful test connection!

So my connection url string in the end was just this:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=mydbhost)(PORT=2484))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=mydbservice)))

and then set a custom property of "connectionProperties" to the following value:

"oracle.net.ssl_version=1.0;javax.net.ssl.trustStore=/usr/wps6.1/WebSphere/ProcServer/profiles/myprofile/config/cells/myCell/trust.p12; javax.net.ssl.trustStoreType=PKCS12; javax.net.ssl.trustStorePassword=password"

Monday 26 September 2011

Deployment error on WAS 6.1.0.39

Since upgrading our WAS environment a few weeks ago to WAS 6.1.0.39 from 6.1.0.31 we were getting errors anytime we tried to deploy an application ear file.

The error we were getting was:

Caused by: org.apache.commons.logging.LogConfigurationException: org.
apache.commons.logging.LogConfigurationException: org.apache.commons.
logging.LogConfigurationException: Class org.apache.commons.logging.
impl.Jdk14Logger does not implement Log

Which looked pretty much like this PMR https://www-304.ibm.
com/support/docview.wss?uid=swg21502693 although that only related to WAS 7 and the workaround documented wasn't available at 6.1

IBM did some investigation and a fix was targetted for FP 43 which was of course no use to me. They did provide a temp fix in the shape of IFPM45666 but that didn't resolve the issue.

After having initially to go back to FP37, we were finally provided a workaround that allows us to go back to FP39.

In /deploytool/itp/ejbdeploy.sh by adding -DNoCustomConverter=true we were able to succesfully deploy our applications again.