DRAC 5 card erroring out. Error when reading from SSL socket connection

I have the same problem.  Recently I needed log in and low and behold no deal.  Go figure.

We have two servers a 2950 and a 1950 running the DRAC 1.65 firmware. The Dell 1950’s DRAC is fine but the 2950 which needs help is not.  They were updated to 1.65 a while back and both worked perfectly.

Anyway I have downgraded the 2950 to the 1.60 firmware and still have the “Error when reading from SSL socket Connection” only with the console redirection. The virtual media works fine.  These DRACs always seem to be a problem when you need them.  On the other hand I suppose that’s pretty good security. LOL.

I’ll repost more as soon as I find the issue and the solution.

please post back when and if you figure out the problem. i have a PE2900-II and III that recently would no longer give me virtual consoles with the Java app. It literally worked just a few days ago, but stopped working on all PE2900 systems. I was on an older firmware, so I thought maybe there's a cert that had expired and updated to the 1.65 firmware tonight. Although I no longer get the Java app just exiting (which I think was caused by an expired cert), I now get the "Error when reading from SSL socket connection".

I'm using Firefox 35.0 with Oracle JDK 1.8.0_31 javaws on Linux.

I'm having the same issue on a PE1950. The Java console says the following interesting SSL-related things: 

01/29/2015 02:26:33:355: SSL: context protocol = SSLv3

01/29/2015 02:26:33:717: SSLv2Hello
01/29/2015 02:26:33:718: SSLv3
01/29/2015 02:26:33:718: TLSv1
01/29/2015 02:26:33:718: TLSv1.1
01/29/2015 02:26:33:718: TLSv1.2

javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

Java versions (Windows 7): 

Java Web Start 11.31.2.13
Using JRE version 1.8.0_31-b13 Java HotSpot(TM) Client VM

My guess would be that the later version(s) of Java are trying to prevent connections on lesser protocols and cipher suites. You can see the supported Cipher Suites by analysing your own DRAC at https://www.ssllabs.com/ssltest/. 

I was having the same problem, and I fixed it by enabling SSLv3 for java 6. I did that by editing

/etc/java-6-openjdk/security/java.security

and commenting out the line

jdk.tls.disabledAlgorithms=SSLv3

by putting a "#" in front of it. After that I could connect to the idrac5 console.

This change does enable the insecure SSLv3 protocol, so the line should probably be returned to default (SSLv3 disabled) after you're done with the idrac5 console.

I can confirm, enabling SSLv3 solved the problem. Although I'm glad to have a way to have the DRAC virtual console work again, it's not comforting that SSLv3 has to be re-enabled, especially in a Java application!

Does Dell monitor these discussions? If so, I hope that Dell considers a firmware update to the DRAC that will use TLS and not require SSLv3.

The corresponding file (at least on my install) for Windows is at C:\Program Files (x86)\Java\jre1.8.0_31\lib\security\java.security .

The jdk.tls.disabledAlgorithms line that needs to be commented out is at the bottom of the file. I agree that Dell needs to update the DRAC5 to support newer ciphers..

This worked it for me also, after upgrading to the latest DRAC 5 FW it broke this functionality.

Thanks to those who posted the fix!..

I'm also experiencing the problem, however downgrading to Java 8 U25 resolved the problem. U31 and U40 both don't work.

thanks!!

that worked great.

i had the same issue i solved it by downloading older version of java   jdk 7.60   coz since ssl3 had major security issues so by default it's not enabled and you won't find it to enable it just download this version and remember to uncheck sslv3 after finishing

I had this issue and resolved it by making sure that my IP was added to the Java security list, and by also switching to compatibility mode in IE.I'm not sure which one of these actually did the trick, but c-mode has been working for me. I had also tried enabling SSL v3, but that didn't work and I disabled it again. IMO, rolling back java is never the right answer, but to each admin their own.

I was also facing this issue, but had to jump some more hurdles:

- In the Java Control Panel, add https:// to the exception site list. (not related to this issue, but needs to be done though)

- In the Advanced tab (this is on windows) enable the console, so I could check what java version was being used. (I have 5 versions installed)

- Edit the mentioned java.security for the correct version, but, I had to make an additional change. I also had to alter the "jdk.certpath.disabledAlgorithms" parameter, and remove MD5 there. Hence, enable MD5 support.

- Sidenote: For "jdk.tls.disabledAlgorithms" the "DH keySize < 768" can stay disabled, yet "SSLv3, RC4, MD5withRSA" have to be enabled (so removed from the parameter)

- In chrome, make sure to re-download the .jnlp file. Might even have to restart the browser.

Thanks CreatedThisJustToSay for figuring this out...

Thank you Steve this did the trick for a problem with a KVM viewer.

It is a wonder why Java implementations and the API are completely non-standard and each update seems to break critical applications.

ive tried all the suggestion and one from one servers I can accrss the console however the other one still has the "Error when reading from SSL socket connection" error

Also disabled the following (temporarily)

jdk.certpath.disabledAlgorithms