When users attempt to connect to an older hardware generation via an iDRAC connection while the hardware runs iDRAC 6 version the client software may fail to connect. If the trace is turned on for the Java console then additional information is provided as to why the connection is failing. Starting in Java 1.8 the list of ciphers for negotiating connections do not overlap with what iDRAC 6 provides. Here is a sample output of what this error looks like:
 

Java Web Start 11.221.2.11 x86_64
Using JRE version 1.8.0_221-b11 Java HotSpot(TM) 64-Bit Server VM
User home directory = 
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to <n>
----------------------------------------------------
KVM/VM Client Version: 5.04.06 (Build 8)
replace numpad
** Max Size: W = 1680 H = 982
** Window Pref Size: W = 1024 H = 806
** Max Size: W = 1680 H = 982
** Window Pref Size: W = 1024 H = 806
JNLPClassLoader: Finding library libVMAPI_DLL.dylib
JNLPClassLoader: Finding library libjawt.dylib
JNLPClassLoader: Finding library libavctKVMIO.dylib
ProtocolAPCP.receieveSessionSetup : reconType = 101
capabilities..4
the cipher suite is provided by the config

Supported protocols: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

Enabled protocols: [TLSv1, TLSv1.1, TLSv1.2]

Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, 
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, 
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, 
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

Enabled ciphers: [SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5]

javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
	at sun.security.ssl.Handshaker.activate(Handshaker.java:509)
	at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1474)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1346)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at com.avocent.d.a.a.a(Unknown Source)
	at com.avocent.d.a.a.a(Unknown Source)
	at com.avocent.d.a.a.b(Unknown Source)
	at com.avocent.d.d.b.a(Unknown Source)
	at com.avocent.a.b.w.g(Unknown Source)
	at com.avocent.a.b.w.a(Unknown Source)
	at com.avocent.app.c.l.m(Unknown Source)
	at com.avocent.app.c.l.d(Unknown Source)
	at com.avocent.idrac.kvm.a.d(Unknown Source)
	at com.avocent.idrac.kvm.Main.a(Unknown Source)
	at com.avocent.idrac.kvm.Main.main(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:748)
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
	at sun.security.ssl.Handshaker.activate(Handshaker.java:509)
	at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1474)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1346)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at com.avocent.d.a.a.a(Unknown Source)
	at com.avocent.d.a.a.a(Unknown Source)
	at com.avocent.d.a.a.b(Unknown Source)
	at com.avocent.d.d.b.a(Unknown Source)
	at com.avocent.a.b.w.g(Unknown Source)
	at com.avocent.a.b.w.a(Unknown Source)
	at com.avocent.app.c.l.m(Unknown Source)
	at com.avocent.app.c.l.d(Unknown Source)
	at com.avocent.idrac.kvm.a.d(Unknown Source)
	at com.avocent.idrac.kvm.Main.a(Unknown Source)
	at com.avocent.idrac.kvm.Main.main(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:748)
CoreSessionListener : connection failed
in CoreSessionListner : fireOnSessionStateChanged
 KVM session state SESSION_FAILED

As users can notice, the Enabled ciphers section displays which ciphers the user's client system is allowed to use for negotiating with the server while Supported ciphers is the list of ciphers the server supports for negotiation. In the above output, users will notice there isn't any overlap among them hence the connection fails. Since H4 and H4R1 iDRAC versions are limited to iDRAC 6, upgrading the cipher list or enabling additional ciphers is not possible. 

This article explains why connectivity to older TIBCO LogLogic hardware via iDRAC fails when attempting to connect with clients running a newer version of JDK/JRE. It also provides a method to bypass the connectivity issues.

This article applies only to hardware appliances that run iDRAC 6 version. Example: H4 and H4R1 series of hardware.

The simple solution to this is a non-recommended method of downgrading the security level on the client system to access the iDRAC. Users can edit the java.security file on their client system to change the disabled cipher list in order to gain access to the iDRAC. Since iDRAC is launched as a Java applet users have to edit the java.security file for the Java browser plug-in rather than the full JDK or JRE installation itself. Sample location on MacOS would be located in:

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security

The reason this is not recommended is because allowing insecure ciphers is not a best practice therefore users should ultimately consider a hardware refresh or use other method to connect to the system in a more secure way like serial console or VGA console. But as an interim solution the modification of the Java security settings will provide a method of accessing iDRAC 6 interfaces.

Note: It's best practice to keep the BIOS and firmware of your LogLogic LMI appliances up to date to avoid running into any additional security exploits that are known to Dell. Only install the Dell BIOS and firmware updates that are provided by TIBCO Software included within LogLogic LMI software upgrade packages. These particular Dell packages distributed by TIBCO have been tested by TIBCO with LogLogic LMI for compatibility purposes.