Having the same issue here... -> ssl_error_weak_server_ephemeral_dh_key

I'm using Chrome for Casper, no issues there...

Separating this out to highlight it as a solution.

As a workaround i have found modifying the server.xml file in
/usr/local/jss/tomcat/conf/sever.xml

Change the line chipher string

FROM:

ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"

TO:

ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"

This fixed a separate issue for us where we couldn't view the JSS over 844.

Thanks!

Thanks for cipher solution!

I just wanted to add my symptom for the next person because Chrome acted more vague...

• Chrome (build 43.0.2357.130) on Fedora 21 just gave the error "ERR_INVALID_ARGUMENT".


• Wireshark showed traffic going back and forth, but ended with JSS sending RST packets for each connection.


• Tested with Firefox and received the same error as OP.

Oddly enough Chrome (same build number) on Windows 7 was working just fine.

I just got the same error this weekend when trying to log into the JSS with Firefox 39. I then tried Safari (8.0.7), and it was able to load the web page.

Since RC4 is on it's way out...

Anyone try this cipher list without the 2 RC4 ciphers? I know it shouldn't impact accessing the JSS from a modern browser, but what about client communication?

Thanks for the prompt solution. I was just starting to investigate this today. Saved me a few hours for sure.

You guys are great.

This is because of the Logjam attack on the Diffie-Hellman key exchange. You can read more at https://weakdh.org

I downgraded to FF 38.0.1. It works, so that's an option.

Well, that was an easy fix to a scary problem.

Since RC4 is on it's way out...

Anyone try this cipher list without the 2 RC4 ciphers? I know it shouldn't impact accessing the JSS from a modern browser, but what about client communication?

@cbrewer I would like to know that as well. I'm going to remove RC4 ciphers on our test server, check client communication and report findings here!

I haven't tested this on Firefox for Mac, but found a way to get through it on Firefox on Windows.

Edit: I tested this, this morning and was able to get to the JSS. I'm not sure if it took a minute to make the change, but I had to close out Firefox and relaunch it and all was well.

Go to about:config and search for security.ssl3.

Change the security.ssl3.dhe_rsa_aes_128_sha to false.
Change the security.ssl3.dhe_rsa_aes_256_sha to false.

This allows me to get it after accepting the certificate.

Thank you so much for the fast solution! I started up Firefox this morning and got the updating Firefox window and thought nothing of it. I never expected that a simple browser update would kill my access to the JSS.

This solved my issue I ran into this morning and was able to fix this quickly. Thank You!

We ran into an issue using Safari on Mac OS X 10.11 and this solved the issue. Thanks!

I can confirm that this fixed our issue as well. The only slight problem we had when implementing the fix was we forgot to append the keystore back into the text after pasting it into the xml file. After copying back in from a backup of the original we were just fine.

@jpilege I like your suggestion better. I'd rather make a change on my browser than the server. I found that just setting security.ssl3.dhe_rsa_aes_128_sha to false worked for me.

I had to change the cipher list too to make Firefox working again.... I thought I could change the Protocols too....
But the SelfService still needs TLS1.0 :-(((((

This may be the proper settings for current installs:

sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2, TLSv1.1, TLSv1"
ciphers="TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 , TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA"

If you generally want to test the cryptographic strength of your server communications, Qualys has a great test suite.

https://www.ssllabs.com/ssltest/

Secure your shit.

I have a blog post here for the noobs: https://nerdily.org/hillary-clinton

You can use the Disable DHE add-on (https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/) as well to get Firefox 39 to work with the JSS admin console again.

This post elaborates a little on the change suggested by @Stonham:

How to Disable Weak Ciphers and SSL 2.0 in Tomcat

Comodo has an article too, which does not reference Java/JDK 6 (which is still on our server(s).

HOW TO -- Disable weak ciphers in Tomcat 7 & 8

If I elect to update the JDK to a newer version on our JSS, I am assuming I need to generate a new keystore—is that correct? Any other potential impact?

I highly recommend removing SSL_RSA_WITH_RC4_128_SHA as it's a weak cipher and any type of SSL/TLS scan will ding you on this.

@Stonham Do you have 9.72 installed for this?

Are people seeing this with 9.72 installed?

I believe the JAMF recommended solution is here Configuring Supported Ciphers for Tomcat HTTPS Connections

This doesn't really have anything to do with 9.72 versus 9.73, unless you've installed 9.73 from scratch.

It has everything to do with ciphers.

https://jamfnation.jamfsoftware.com/article.html?id=384