An awful lot of security issues has lead Oracle to tighten things when it comes to Java WebStart as it is used in an awful lot of KVM over IP solutions. Some of those systems are even very picky on the Java version used. *blimey*

Now I had those shiny new IBM SystemX x3650 m4 and a x3550 m4 that I was exploring when I was documenting settings for their remote service processor. In IBM (soon Lenovo?) SystemX M4 series this thing is called IMM2 (Integrated Management Module 2) and once you have installed it with a (not so cheap) license key you get a shiny remote KVM ability.

I was unfortunate to look at the documentation and to discover the CLI parameter 'tls':

system> help tls

  usage:
   tls [-options] - configures the minimum TLS level
   -min <1.0 | 1.1 | 1.2> - Selects the minimum TLS level
   -h - Lists usage and options

system> tls
-min 1.0

So I though: "TLS 1.0 is aging let's at least bump it to 1.1". - Until that moment the remote management capability worked pretty well beyond some random Java quircks. But unfortunately I tried out a couple of settings so at first it wasn't obvious that it was due to this that Java stopped loading the Avocent KVM over IP applets and instead got greeted by this:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
	at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
	at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
	at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
	at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
	at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
	at sun.security.ssl.InputRecord.read(Unknown Source)
	... 20 more

OK, why did that happen - I though TLS 1.1 was supported by Java 7 for som time now- right?

• Java 6 did only support upt to TLS 1.0
• Java 7 (at least up to Update 55) did add support TLS 1.1 and TLS 1.2 but actually never enabled it by default
  If you want to enable it, open the Java Control Panel (javacpl) and enabled the newer TLS versions
• Java 8 seemingly comes with TLS 1.1/1.2 enabled by default

If I had properly read the error message (*dou*) I would have far more quickly realized where to look for.

Curently you have to either set IMM2's TLS version minimum to 1.0 (default) or fix your Java to allow newer TLS version.