Java connection problems with tunneled applications

Guest post by Raúl Moros Peña, a senior UAG consultant from Spain

We ran into an issue when publishing IBM HOD via UAG. HOD (Host On-Demand ) is an IBM product to connect to 3270 mainframes. HOD needs no client software because the terminal emulation program is downloaded as a Java applet to the client. We used the suggested “generic browser embedded application” template for this, and even though connection seems to work, the applet didn’t get installed.

Looking at the logs in the Java console, we could see that Java was unable to connect to the published web server to download the app. It was strange, because the browser could connect, HOD was working locally and Java was correctly configured (proxy and so on).

As troubleshooting progressed, we realized that when connecting with Firefox, the UAG client component installation was also failing in a similar manner. Since the UAG Java components are on a different location than the HOD’s, it didn’t seem to be a problem in the back-end servers side. Furthermore, the same client could download the UAG components from a different UAG server.

We decide it was time to take a look under the hood with Wireshark. It became evident that the SSL handshake was being rejected by the server as shown in the screenshot:

Comparing the SSL handshakes of Java and the browser we could see that the cipher suites offered by Java were lower in number and with weaker algorithms than the ones offered by Java:

Could SSL get rejected by a weak algorithm offered by Java? If so, why didn’t the other UAG reject the connection? We considered the F5 load balancer that was in front of UAG, but ruled it out because a client bypassing F5 failed as well (my apologies to Mr. F5 for our mistrust).

So, our attention turned back to the UAG Server, and this time, we looked at the certificate. IT looked perfectly fine…but then we noticed that weak cipher suites were being rejected. What CSP we chose when requesting the certificate? RSA Schannel is the default when requesting the certificate from IIS manager, isn´t it?

Well, this specific certificate was requested using the certificate MMC. Looking at this again, we realized that this is where the problem lay.

As it turns out, the MMC-based form is set to use the Microsoft Strong Cryptographic Provider by default. We were very careful to choose a “legacy key” in the first step of the wizard to avoid problems with next generation cryptography, but later, we accepted the default CSP, and that CSP was leading to the rejection.

We created a new certificate, this time with RSA SChannel, and the problem was resolved!

With all that said and done, we later discovered a hidden gem in the system event viewer:

Source: SChannel, Event: 36874 - An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. Source: SChannel, Event: 36888 - The following fatal alert was generated: 40. The internal error state is 1205.

Had we looked at that earlier, it would have revealed the cause instantly. Good thing we love troubleshooting and we enjoyed it a lot!!

Guest post by Raúl Moros Peña, a senior UAG consultant from Spain

Comments

• Anonymous
  January 01, 2003
  Thank you! I was having a similar problem, your post saved me many hours.