ASDM issue on 5516-x

[jkay18041]

Hello, I was hoping someone could help me figure out the best way to fix the issue where when I try to connect to the ASA via asdm I get the message "unable to launch the device manager from IP address"

We recently made changes to our ssl cyphers and I've read that will break the asdm. I would prefer to not add back less secure cyphers unless fully necessary. I saw there are some Java files you can use to patch but I'm not entirely sure how to go about that. I have asdm-782-151 and running Java 8u151.

Thank you!

[Karsten Iwen · Accepted solution]

What is your client? For older Windows-versions TLS1.1/TLS1.2 is not enabled by default.

What are your SSL-settings? I run DH-group14, TLS-server version either 1.1 or 1.2, ciphers as "fips" and the ASDM is working.

[jkay18041]

Not sure what you mean by client. I am running tls1.2 only and the ciphers
are set to high. I can try fips and see if that works.

Thank you

[Karsten Iwen]

The client is the PC you use to launch the ASDM. If it is a Win7 or 2008R2, then some registry-changes are also needed.

[jkay18041]

It's a Windows 10 pc

[jkay18041]

changing ssl ciphers to fips fixed it. What is the difference between high and fips?

Thank you for the help!

[Karsten Iwen]

"high" only has some very secure ciphers enabled. "fips" allows some more compatible but still secure ciphers. You can compare them with "show ssl ciphers high" and "show ssl ciphers fips".

[Karsten Iwen]

Not to forget: It is possible to "fix" this and make it work with the "high" settings. But for that you make sure that you can control all PCs using the ASDM. If you install the "Java Cryptography Extensions (JCE)" on all client PCs it will work with the setting "high".

[Marvin Rhoads]

Hi Karsten,

I noticed last month that the most recent Java 8 updates finally started including the JCE by default.

[Karsten Iwen]

Hi Marvin,

that is great news, but on which platforms did you observe this? I just tried with Java8U151 on macOS and Win8.1 and it didn't work ...

[Karsten Iwen]

Ok, there is something noted in the Java release-notes:

http://www.oracle.com/technetwork/java/javase/8u151-relnotes-3850493.html

But it seems not to be enabled by default and at the moment I can't find an option to enable it ...

[Marvin Rhoads]

Karsten,

If you look in the java.security file on a Java 8u151 or later installation you should see some verbiage like I have quoted below.

It just started working for me - perhaps because my previous installation already had the JCE policy files? You should be able to unremark the line "#crypto.policy=unlimited"to flip the setting for an installation that's enforcing limited security.

# To support older JDK Update releases, the crypto.policy property
# is not defined by default. When the property is not defined, an
# update release binary aware of the new property will use the following
# logic to decide what crypto policy files get used :
#
# * If the US_export_policy.jar and local_policy.jar files are located
# in the (legacy) <java-home>/lib/security directory, then the rules
# embedded in those jar files will be used. This helps preserve compatibility
# for users upgrading from an older installation.
#
# * If crypto.policy is not defined and no such jar files are present in
# the legacy locations, then the JDK will use the limited settings
# (equivalent to crypto.policy=limited)
#
# Please see the JCA documentation for additional information on these
# files and formats.
#crypto.policy=unlimited

[Karsten Iwen]

Great, uncommenting the line "crypto.policy=unlimited"worked like a charm. I think I can manage that for most clients to further improve the security. Good to know that it's that easy with the actual Java.

[Marvin Rhoads]

Perfect - thanks for the confirmation and the rating.

Cheers!