ASDM will not run after ASA upgrade to 9.6(3)1

[trector]

Running macOS Sierra version 10.12.4

Java Version is 8 Update 131

ASA5512 running 9.6(3)1

ASDM running 7.1(1)151

ASDM will not run as Java Webstart or ASDM Launcher

Get "javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure" under wrapped exception

Get ""com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://xxx.xx.xx.xx:8443/admin/public/asdm.jnlp" under exception

Have an open TAC case with no resolution

Works fine under Windows but not under MAC

Downgrading the ASDM makes no difference.

Backing down the ASA code version allows the ASDM to work.

Here is the full Java message:

com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://xxx.xx.xx.xx:8443/admin/public/asdm.jnlp
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1546)
at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:91)
at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1466)
at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1464)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:782)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1463)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)

TAC has not able to fix the problem.

Any Ideas?

[Marvin Rhoads]

Handshake failure usually means that there are no common SSL/TLS encryption algorithms negotiated between the server (ASA) and client (ASDM using the client's Java installation).

If you do a packet capture during the attempted connection this is usually clear from the SSL handshake decode. 

Successfully fixing it usually involves upgrading the client side Java.

You might also check to make sure your Java has the (non-default) JCE (Java Cryptographic Extensions) available for strong security and that you have not used the default Java high security option which requires a trusted certificate on the server.

http://stackoverflow.com/questions/37741142/how-to-install-unlimited-strength-jce-for-java-8-in-os-x

[trector]

Marvin,

Packet captures with TAC show numerous matches between the 22 cipher options presented by my client and the active ciphers listed on the ASA(s).  It should work, but it doesn't

The JCE option seems to be promising.

I will dig deeper into this later today or over the weekend.

Thanks for the help.

[Marvin Rhoads]

Hmm if the captures are showing matching cipher options then JCE is probably not the issue. That's a less common one that generally only affects clients when the ASA has been "hardened" to allow only strong ciphers.

Also check to ensure that your ASA certificate is SHA-2. That has been cited as a root cause for the Java handshake failure issue.

http://stackoverflow.com/questions/38203971/javax-net-ssl-sslhandshakeexception-received-fatal-alert-handshake-failure

You might also look at this article as it is OS X Java specific:

https://support.apple.com/en-us/HT202643

[trector]

Marvin,

I really appreciate the help.

TAC had a call with the same issue over the weekend.

Their fix was to uncheck the "Use SSL 2.0 compatible ClientHello format" in Advanced tab of the Java Control Panel (At the bottom).

This also worked for me.

Thanks again.

[Marvin Rhoads]

Thanks for the update with your resolution.

I checked mine and that is already unchecked - I will remember to ask folks to look at that setting going forward.

[L Epp]

Thank You! This fixed it for me also!

[Will]

I can confirm that this worked for me also today (6/23/2017)

[jakebrown4]

That fixed my issue! Thank you!! Now I can stop banging my head on the wall.

[rcarmack1]

Thanks, that change fixed my issue.

[darrin.brown]

Wow. I spent almost 8 hours changing Java, importing certificates, etc. This fixed it! Thanks!

[rcarmack1]

Good to hear. I'm trying to figure out how to present the certs under the machine store as the logged on user. I think the issue is the machine cert isn't presented either because it's a machine cert or because it's a machine cert under a different domain. My AD login is a one domain while the company machines are in the company domain. I'm not sure.

[ecastro73]

This fix worked for me as well. Thank you!

[paul.aceves@dkbinnovative.net]

This worked for me. Thanks Marvin!!

[cofee]

Go to Java application folder and open it, look for allowed list under the security tab. You may have to add the address of firewall (https://x.x.x.x). This should resolve your issue if Java is blocking it.