topic Re: Marvin, in Network Security

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

trector — Tue, 12 Mar 2019 09:21:06 GMT

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?

Handshake failure usually

Marvin Rhoads — Fri, 12 May 2017 03:54:53 GMT

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

Go the Java application

cofee — Fri, 12 May 2017 11:22:44 GMT

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.

Thanks for the quick response

trector — Fri, 12 May 2017 12:58:07 GMT

Thanks for the quick response.

I did forget to mention that I have had to add ASDM hosts to the allowed Java list for some time now, and that the multiple firewalls that cannot be accessed properly are all in this list as both IP address and IP address/port. I had to start adding these a year or 2 ago when that big Java change came out.

Thanks

Marvin,

trector — Fri, 12 May 2017 13:07:09 GMT

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.

Hmm if the captures are

Marvin Rhoads — Fri, 12 May 2017 13:32:18 GMT

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

Marvin,

trector — Wed, 17 May 2017 01:56:19 GMT

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.

Thanks for the update with

Marvin Rhoads — Wed, 17 May 2017 02:54:25 GMT

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.

Thank You! This fixed it for

L Epp — Fri, 19 May 2017 15:20:20 GMT

Thank You! This fixed it for me also!

I can confirm that this

Will — Fri, 23 Jun 2017 20:23:02 GMT

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

Re: Marvin,

jakebrown4 — Thu, 19 Oct 2017 22:33:18 GMT

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

Re: Marvin,

rcarmack1 — Mon, 12 Feb 2018 18:39:52 GMT

Thanks, that change fixed my issue.

Re: Marvin,

darrin.brown — Wed, 14 Feb 2018 20:25:44 GMT

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

Re: Marvin,

rcarmack1 — Wed, 14 Feb 2018 20:55:42 GMT

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.

Re: Marvin,

ecastro73 — Tue, 08 Jan 2019 18:39:53 GMT

This fix worked for me as well. Thank you!

Re: Marvin,

paul.aceves@dkbinnovative.net — Thu, 12 Sep 2019 15:21:39 GMT

This worked for me. Thanks Marvin!!