Unable to Access ASDM – “Unable to launch device manager from…”

KB ID 0000915

Problem

A colleague of mine was trying to connect to a firewall via ASDM last week, and was greeted by an error like this.

Now this is a pretty standard error, and usually means you haven’t been allowed access, or there isn’t a firewall at that address, but in this case I knew that a) he did have access, b) that was the correct IP address, and c) it worked fine on my machine, so it was setup correctly.

As I said above this is a pretty generic error make sure your ASDM is configured correctly. If no one else can access it then run though the article below.

Cannot Access / Open ASDM

Solution 1 (Oct 2018)

This stung me once again today! Windows 10, latest version of Java 8, and ASDM version 7.6(1) and 7.9(2). In the debug I was seeing;

[box]%ASA-7-725014: SSL lib error. Function: SSL3_SEND_SERVER_KEY_EXCHANGE Reason: missing tmp dh key[/box]

Fixed by running;

[box]ssl encryption aes256-sha1[/box]

Solution 2 (circa 2015)

I saw this very problem again today, while hardening a firewall I had disabled some SSL encryption ciphers, I had left aes256-sha1 active, and removed the others. Took me a while to realise, but if you only have one (or both), of the following ciphers enabled, ASDM won’t load;

  • aes-256-sha1
  • dhe-aes256sha1

If you have any of the following ASDM should load normally;

  • aes128-sha1
  • dhe-aes128-sha1
  • rc4-sha1
  • 3des-sha1

At this point I would consider the problem ‘fixed’ and move on, but the client I’m installing the firewall for wanted some clarification as to why it would not work. “Was it a bug?” So I opened a TAC call, and did some Googling. I came across an excellent article. And found I could replicate it exactly;

Log output

[box]%ASA-6-302013: Built inbound TCP connection 2698 for inside:192.168.100.10/52674 (192.168.100.10/52674) to identity:192.168.100.1/2456 (192.168.100.1/2456)
%ASA-6-725001: Starting SSL handshake with client inside:192.168.100.10/52674 for TLS session.
%ASA-7-725010: Device supports the following 1 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA
%ASA-7-725008: SSL client inside:192.168.100.10/52674 proposes the following 14 cipher(s).
%ASA-7-725011: Cipher[1] : AES128-SHA256
%ASA-7-725011: Cipher[2] : DHE-RSA-AES128-SHA256
%ASA-7-725011: Cipher[3] : DHE-DSS-AES128-SHA256
%ASA-7-725011: Cipher[4] : AES128-SHA
%ASA-7-725011: Cipher[5] : DHE-RSA-AES128-SHA
%ASA-7-725011: Cipher[6] : DHE-DSS-AES128-SHA
%ASA-7-725011: Cipher[7] : AES128-GCM-SHA256
%ASA-7-725011: Cipher[8] : DHE-RSA-AES128-GCM-SHA256
%ASA-7-725011: Cipher[9] : DHE-DSS-AES128-GCM-SHA256
%ASA-7-725011: Cipher[10] : DES-CBC3-SHA
%ASA-7-725011: Cipher[11] : EDH-RSA-DES-CBC3-SHA
%ASA-7-725011: Cipher[12] : EDH-DSS-DES-CBC3-SHA
%ASA-7-725011: Cipher[13] : RC4-SHA
%ASA-7-725011: Cipher[14] : RC4-MD5
%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no shared cipher
%ASA-6-302014: Teardown TCP connection 2695 for inside:192.168.100.10/52671 to identity:192.168.100.1/2456 duration 0:00:00 bytes 7 TCP FINs[/box]

Note: the Client (My machine running ASDM) offers 14 cipher sets and theres no match.

By this time I had reply from TAC

————————————–

“The ciphers depends on the client, which in this case is ASDM launcher. ASDM launcher depends on ASDM version installed, latest available launcher is 1.5(73) – ASDM 7.4.1.
I did some tests with the latest software (ciphers741.png) but AES256 was still not proposed by the launcher.

I found a bug opened back in 2012 for exactly same issue, which was closed due to inactivity. Developers mentioned there that launcher is using all the ciphers supported by Java installed on client PC.
https://tools.cisco.com/bugsearch/bug/CSCtx78540/

Please refer to:
https://en.wikipedia.org/wiki/Java_Cryptography_Extension

JCE adds additional ciphers support for a Java client.
I downloaded the JCE for Java 7 

Then I copied local_policy.jar and US_export_policy.jar to the $JAVA_HOME/jre/lib/security (these jars were already there so I had to overwrite them).

After that I tried once again and it worked.

————————————–

OK, that seems fair enough, and Kudos to the TAC engineer who had really gone the extra mile. So I thought I’d try and replicate it on the test bench.

Then it worked fine, so I logged the results once again;

[box] %ASA-6-302013: Built inbound TCP connection 2900 for inside:192.168.100.10/63760 (192.168.100.10/63760) to identity:192.168.100.1/2456 (192.168.100.1/2456)
%ASA-6-725001: Starting SSL handshake with client inside:192.168.100.10/63760 for TLS session.
%ASA-7-725010: Device supports the following 1 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA
%ASA-7-725008: SSL client inside:192.168.100.10/63760 proposes the following 23 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA256
%ASA-7-725011: Cipher[2] : DHE-RSA-AES256-SHA256
%ASA-7-725011: Cipher[3] : DHE-DSS-AES256-SHA256
%ASA-7-725011: Cipher[4] : AES256-SHA
%ASA-7-725011: Cipher[5] : DHE-RSA-AES256-SHA
%ASA-7-725011: Cipher[6] : DHE-DSS-AES256-SHA
%ASA-7-725011: Cipher[7] : AES128-SHA256
%ASA-7-725011: Cipher[8] : DHE-RSA-AES128-SHA256
%ASA-7-725011: Cipher[9] : DHE-DSS-AES128-SHA256
%ASA-7-725011: Cipher[10] : AES128-SHA
%ASA-7-725011: Cipher[11] : DHE-RSA-AES128-SHA
%ASA-7-725011: Cipher[12] : DHE-DSS-AES128-SHA
%ASA-7-725011: Cipher[13] : AES256-GCM-SHA384
%ASA-7-725011: Cipher[14] : DHE-RSA-AES256-GCM-SHA384
%ASA-7-725011: Cipher[15] : DHE-DSS-AES256-GCM-SHA384
%ASA-7-725011: Cipher[16] : AES128-GCM-SHA256
%ASA-7-725011: Cipher[17] : DHE-RSA-AES128-GCM-SHA256
%ASA-7-725011: Cipher[18] : DHE-DSS-AES128-GCM-SHA256
%ASA-7-725011: Cipher[19] : DES-CBC3-SHA
%ASA-7-725011: Cipher[20] : EDH-RSA-DES-CBC3-SHA
%ASA-7-725011: Cipher[21] : EDH-DSS-DES-CBC3-SHA
%ASA-7-725011: Cipher[22] : RC4-SHA
%ASA-7-725011: Cipher[23] : RC4-MD5
%ASA-7-725012: Device chooses cipher : AES256-SHA for the SSL session with client inside:192.168.100.10/63760
%ASA-6-725002: Device completed SSL handshake with client inside:192.168.100.10/63760
[/box]

Note: We now have 23 cipher proposals from the client.

Solution 3

Java 7 Update 51

Java Version 7 update 51 (Released Jan 2014) does not play nice with the Cisco ASDM.

Note: This is NOT the case if the ASDM presents a known, trusted, (not self signed) digital certificate.

Option 1

The easiest option is simply remove Java and downgrade to Java Version 7 Update 45

OR

You can also upgrade your ASDM to version 7.1(5.100) or later, and use the Java Web Start Option.

java

OR

Create a Java site exception. Note: This DID NOT WORK for me with Java version 7 update 51 to both ASDM Versions 7.1(1) and 7.1(5.100). I only put it here for completeness, because Cisco say it’s a solution.

Related Articles, References, Credits, or External Links

Original Article Written 11/02/14

Kudos and thanks to Michal Kunikowski from Cisco TAC for his assistance.

 

Accessing Dell ‘DRAC’ Fails – ‘DRAC5 Console Redirection Client Unable to launch application’

KB ID 0000918

Problem

After I got a new laptop, I attempted to connect to my test server and was greeted with this error.

Application Error
Unable to launch the application

Name: DRAC5 Console Redirection Client
Publisher: Dell Inc
Location: {ip-address}:443

So I hit the details tab and got this,

Error: Missing required Permissions manifest attribute in main jar:
https://{ip-address}:443/plugins/vkvm/avctDRAC5Viewer.jar

Solution

Luckily I had seen a similar error a couple of weeks ago, while a colleague was trying to set up a Cisco ASDM. This is a ‘security feature’ of Java version 7 (Update 51). Work had pre-built my new laptop, so I simply downgraded to Java version 7 Update 45. And it burst into life.

DRAC 5 Java Workaround

Currently Dell consider DRAC5 EOL (End Of Life) and will not fix the certificate issue with updated firmware. Their official response is ‘Maintain an older version of Java’. So either downgrade or lower the security settings;

1. Windows Key + X > Control Panel.

2. Java > Security> Set to Medium.

Related Articles, References, Credits, or External Links

Original article written:19/02/14

Dell DRAC 5 – ‘Error when reading from SSL socket Connection’