h1ghlevelb1ts

After too much time wrestling with setting up a two way SSL connection between one WebLogic Server 10 instance and one WebLogic Server 9 instance through one Apache instance I have now come to a solution. I don't know much about these matters. In the 12 years I have spent in the business I have only worked with issues like these once before. And it seems that not many people know about how to solve it. I asked everyone I could think of in the organisation and finally I found Rickard Lundin that was the first person that actually seemed to understand the whole chain of events. So with Rickards help and with a lot of help from Google a solution is now at hand.

The solution we found was rather simple and it is kind of disturbing that it took so long. I spent several hours in the console of WebLogic Server where there are one tab for SSL and one for Keystores for every server instance in a domain. This didn't work at all and one WLS expert I talked to said he never got it to work properly. This may still not be the case but I can tell you that it sure is not easy to make it work. So scrap WLS configurations. Instead what to do is rely on Javas built in support for SSL and HTTPS. Whenever instances of java.net.URL gets called with openConnection() and the protocol https is used in the url there are 4 system properties that are used. (For older versions of Java you may need to install JSSE specifically to make this work.) These are javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword for the key and certificate you want to use to certify your client. And then there is javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword that is used to to make sure that the client can trust the server it is calling. Both "store"-properties must point to a file stored in JKS (Java KeyStore) format. And the password parameters are naturally used to access those key stores. If you have pem files or some other kind of file format for you keys and certs you can use the open source tool Portecle to put them into a JKS file instead. There is also the keytool tool (!) in JDK that knows a lot about how to maniuplate JKS files. And more generic perhaps - openssl on the command line.

A very good post about this.

In my case I needed to make 2 calls to the server - the first one to get a login and a session and the second to get some data. This is hard with the normal JDK classes so I downloaded httpclient 3.1 (version 4 is in beta) and used the classes HttpClient and GetMethod to do my calls. The session still wasn't kept alive between the calls. Some more googling led me to the documentation about cookies (!) at httpclient home page. And it makes sense since the web server store the session identity as a cookie. No need to rewrite the session id when calling from a controlled environment. It turned out that the code

 method.getParams().setCookiePolicy(CookiePolicy.RFC_2109)

made wonders when put in between creating the method object and executing it. So a couple of system properties and about 10 lines of code solved this problem. It is so easy to get lost in the app server jungle when there often is a simpler solution close by. And this solution works from a standalone client too!