Investigating/Fixing HP ILO2 Java Remote Console fails to start with Class Not Found remcons.class

TLDR; Just give me the new fix

This made things work for me when put together with "Stuff Everyone Has Already Done" down below. Uncheck Use TLS 1.1 and Use TLS 1.2 in Java Control Panel, Advanced Tab:

Be sure and close all Firefox windows and restart the browser so that change takes effect.

Also, make sure and run the remote console twice (to the same ILO server) before you consider it not fixed. I'll explain that 2x run thing down below, but essentially on the first run, the remcons class jar file gets cached but NOT used and the next run it actually gets used.  For some reason it will only run "from cache", if that makes any sense. It's like old routers that could run from RAM vs run from FLASH, in this case run from CACHE :)

Background

HP ILO2 has had Java applet issues before but lately things have been terrible, or maybe I never noticed until recently trying to build up some DL360 G6 servers. There's quite a few people on the web looking for answers, this seems to be the latest in the drama.

Using ILO2 firmware 2.27, Java 1.8u31 (32bit), Firefox 36.0 on Windows 7 64bit I have found something that reliably works for me, and also gathered a bunch of info on the problem.

In the hopes that someone who knows more about this than me (and in the right position at HP or Oracle) can use it to find and fix the real problem with Java or the ILO2 firmware, I'm putting all the info I gathered up here.

Quick Summary of the Problem

The file rc175p09.jar contains the remcons class file. The file is present on the ILO web server exactly where it should be. Java has issues downloading, caching, and/or using it. When Java successfully uses it, the Remote Console applet works fine.

When Java cannot download, or cache, or use the file rc175p09.jar, the error you see is always the same "Class Not Found".

The first problem is that with TLS 1.1 and 1.2 enabled, Java cannot download the .jar file due to SSL connection/cert issues with the ILO webserver. Disabling TLS 1.1 and 1.2 allows Java to download the jar file.

The second problem is that it seems that when the jar file is downloaded, it should be successfully used/run+cached immediately. For some reason, it only successfully runs if it was already present in the cache at launch. After download it will be cached, but not used/run. If it's cached, it will be used/run.

Walkthrough

When you click the Remote Console link, at some point the Java plugin begins running and the file rc175p09.jar which contains the file remcons.class (and others) is searched for in the Java cache (not Firefox cache). If it is present in the Java cache it will get used,  the Remote Console will start and you will not see the Class Not Found error.

Unfortunately, that seems to rarely happen for people now.

If rc175p09.jar is NOT found in the Java cache, an attempt will be made to download it from the ILO webserver using the URL http://<iloip>/rc175p09.jar.

You can manually download that file with your browser all day long with no errors, but that is not the case with the Java plugin (v1.8u31). When TLS1.1+1.2 are enabled in Java Control Panel/Advanced, the download(which is performed by Java and not Firefox) will fail and the .jar file will not be stored in the Java cache.

You can verify this by looking at the Java cache via the Java Control Panel applet, General Tab, View button. When the .jar file has been cached it will appear in the list of "Resources" (choose Resources from drop down).

Ok, so at this point, you should be able to see the jar file is not being downloaded. You can setup Java Control Panel to pop up the Java Console and see debug logs which have a couple interesting lines about failed SSL connections, but still end up at a misleading "Class Not Found" error.

Here's some relevant errors from the Java Console when clicking Remote Console with TLS 1.1 and 1.2 enabled:

• com.sun.deploy.security.RevocationChecker$StatusUnknownException: Certificate does not specify OCSP responder
• security: Invalid certificate from HTTPS server
• javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
• javax.net.ssl.SSLException: Received fatal alert: bad_record_mac

I don't know and didn't look into it but it seems OCSP features of TLS 1.1 or 1.2 are causing things to fail when talking to the ILO Webserver. Here's the full log with TLS 1.1 1.2 enabled and jar not cached.

Ok, so once you disable TLS 1.1 and 1.2 in Java Control Panel, Java will be able to download rc175p09.jar from the ILO Webserver. It will get cached, but not used/run when it gets initally downloaded. Here is a full log of jar not cached and TLS 1.1 1.2 DISabled.

The 2nd time you launch Remote Console from that ILO web page, it will work since it is in the cache, which you can verify like this:

A full log of this successful, 2nd Remote Console launch attempt: full log jar cached TLS1.1 and 1.2 disabled Remote Console works

For further confirmation, you can remove the jar file from the cache (highlight it an click the red X as shown in image above) and you'll find that you need to launch Remote Console 2 times again to get the .jar file cached and then to actually use it.

It caches the jar file for each different ILO server IP. Unfortunately the Java cache is "organized and indexed" in some manner and you can't simply copy the jar file into a folder and have it be used (as far as I can tell)

I have a great html file WinMerge generated that shows side by side diff of the Java Console debug logs of 1st and 2nd Remote Console Launch attempts.

Stuff everyone has most likely already done.

The normal items everyone already knows or has tried (that are actually involved):

1. In Java Control Panel, Security Tab, Exception Sites List, add the address of the ILO web server. As in: "https://10.10.10.10" if that's what you use to log into ILO web gui
2. Make sure Java is enabled and working in Firefox, (you need 32 bit JRE). Firefox locks out some older versions of Java so update java, check at java.com by clicking "Do I have Java?" link.
3. When I first click on Remote Console link in ILO2 web gui, the pop up window has scroll bars and the "Activate Java" icon Firefox may display is off the visible portion of window. When you don't realize this, or what the the little Lego block looking icon on the left side of address bar is, then you'll be waiting forever and nothing is happening. Click the Lego block looking thing or scroll right and down to the middle of  the massive window to "Activate" or Allow Java.
   
4. You'll see loads of "Site Not Trusted" type pop ups. I've verified that there is no problem leaving the stock SSL cert in place to get Remote Console working. I've gotten things working smoothly with CA added to the browser and while I see less pop ups for Untrusted sites, it made NO difference in the failure to launch the remcons Java applet.
5. It doesn't hurt to restart Firefox. I have seen it definitely fix things, especially if I cancel/abort one of the "Do you want to trust this Certificate " windows. It seems to store that distrust in memory and Java seems to pull that distrust in also( Java default setting is to also use browser cert/key store). But of course the error is always "Class not found" still.

ILO's SSL Cert - Stock defaults will work (for me anyway :) )

Something I spent some time verifying was the MD5-> SHA-1 and 1024->2048 SSL key/cert changes. At first I thought they worked for me, but eventually I learned that it was due to other factors. I reverted things back to default 1024 bit MD5 signature and was able to use the remote console. I verified the cert/key stuff was MD5 and 1024bits  via openssl commands showing the SSL connection and dumping the Certificate provided by the ILO webserver.

openssl s_client -connect to ILO2 web server

openssl x509 dump of  Public Certificate provided by ILO Webserver
(saved from s_client connect command above) showing MD5 signed 1024 bit key

Another item I ran into in my search for a solution was that Java 1.8u31 disables SSLv3. You can re-enable it by editing a file in (details on this are in the Java 1.8u31 release notes):

%JAVA_HOME%/lib/security/java.security

But, it made no difference and as you can see in the openssl s_client image above, i specified "no ssl3" and it was still able to connect successfully.

So, since I was able to remote console in with Java 1.8u31 and the above shows that a stock/default MD5 1024 bit Cert was being used by the ILO Webserver, I think we can say you dont need to fiddle with the SSL cert parameters to make Remote Console work.

After cert parameter changes I made sure they too effect by changing the ilO 2 Subsystem Name (hostname) on the Administration Tab, Network page. I never checked whether just resetting ILO manually on System Status,Diagnostics page would cause the Cert to be regenerated.

Anyway, hopefully someone can get Java or ILO fixed up again so all this mess doesn't matter (again).