27 February 2015

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 :)


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.


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: "" 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):
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).


  1. Great article.

    Just two comments.
    1) I have a network trace that proves there is an issue with Java TLS implementation. When I attempt to open iLO2 Java Remote Console, I see both client/server negotiating TLS 1.0 as expected but, then iLO2 closes the connection with a bad MAC alert. This suggests that JRE is using the wrong MAC algorithm when TLS 1.1 / 1.2 are enabled but, the connection has been negotiated down to TLS 1.0

    2) Using Self-Signed SSL Certificates makes you vulnerable to Man-In-The-Middle attacks. I would suggest you to configure a Certification Authority in your network and replace those Self-Signed SSL Certs with trusted ones. iLO2 webserver becomes noticeable slower when 2048bit RSA keys are used so, you could try SSL certs with 1024bit with SHA-1. However, do not use MD5.
    Using certs with 1024bit may not sound right these days but, it is still more secure than leaving those Self-Signed SSL certs in place.

  2. Thanks.

    Your testing supports TLS 1.1/1.2 being the issue then.... Java or iLO2 doesn't like what the other is doing. I'm not sure which one is doing the right thing.

    Were you able to sniff inside the https connection via wireshark? I've done this before but I had the private key.... you sound like you would have no trouble MITM attack on the self signed cert instead :)

    Thanks for the pointers on SSL cert for ILO2, We are setting up HP SIM and I was considering redoing the certs across all servers. Up till now they have been self signed stock ones.

    They are on a dedicated and isolated 10.x management LAN so we've never really worried about the Certs. Although, there is VPN access to it so I guess it's not totally isolated.

  3. Thank you so much! Disabling TLS 1.1 and 1.2 did the trick.

  4. This comment has been removed by the author.

  5. Disabling TLS 1.1 and 1.2 alone didn't work for me.

    What got it to load for me was deleting all cached apps and resources, and quit out of Firefox. Reloaded Firefox, got the error, reloaded the second time, and it came right up.

    I thank you for the info you've published!

  6. on Linux, just add or edit java.security file:
    jdk.tls.disabledAlgorithms=TLSv1.1, TLSv1.2

    1. from "iLO 2 v2.27 - 27 January 2015" change log:
      "Disabled the old SSL version 3. From now on, iLO 2 only supports TLS 1.0. "

    2. You can re-enable it from the ILO2 CLI.

      set /map1/config1 oemph_ssl_v3_enable=yes

      Note that the ILO will reset when this setting is changed.

  7. Many thanks for this - it looked grim indeed until I found this :)


  8. Good news. HP is testing a fix.
    See the forum thread by clicking on the "latest in the drama" link in the article.

  9. great article. thank you.

  10. Helpful article, thanks. HP has not issued a fix yet.

  11. HP has just released iLO2 v2.29. This version fixes the Java Remote Console issue

  12. Thank you for the troubleshooting guide! It was very helpful. We spend a lot of time on different approaches with different browsers and settings. But disabling the options in the java console finally did the trick. Thank you!

  13. Free easy & simple way to learn java online and much more.. go to =>> http://foundjava.blogspot.in