Install identity cert on asa

[tolinrome tolinrome]

Hello,

I would to install a certificate on an ASA so that when I log into it via ASDM, it does not give me the security warning that the site is untrusted. I created an identity CSR on the ASA and received the cert back from my internal CA server and applied it on the ASA, but it still shows up as a security warning when logging in, I may have missed something or not done it correctly. My workstation has the CA cert in its local store. So I figured that is the ASA's identity cert was signed by the internal CA and I have the internal CA in my computers cert store, shouldn't that be suffice? So the questions are:

Do I need only a identity cert on the ASA, or do I also need a CA cert on the ASA?

Is not my internal CA (Windows server) suffice to authenticate the identity cert on the ASA?

Is there a way to do this for many ASA's, instead of manually on each ASA by logging into the ASDM etc?

All the research I have done only talks about identity certs for vpn clients. My objective is to have it only for logging into the ASDM from workstations that have already the internal CA cert in their store and to not have the security warning appear when logging in to the ASA via the ASDM.

Thank you.

[Marvin Rhoads]

When you create an identity certificate via generating a CSR and getting your internal CA to sign it, it will generally suffice to have the internal CA in your trusted root certificate store.

However, the CSR must have been well-formed - the most common issues I run across is that the Common Name (CN) in the CSR must match the FQDN that you will be using in ASDM.

For instance, even with a certificate issued by a trusted internal CA, if the certificate says the device is asa.mycorp.com and you point ASDM instead to the interface address of 192.168.1.1, that mismatch will cause ASDM to complain.

You can usually easily check for common mismatch errors by, instead of using the ASDM launcher directly, simply browsing to the ASA's admin interface (i.e. https://192.168.1.1/admin ) and seeing what the certificate inspection tool built into your browser tells you.

[tolinrome tolinrome]

Yes, I actually made sure during the CSR that for the CN I specifically made it the IP address that I access it with. I did as you mentioned and went to admin interface in the browser and viewed the certificate, it shows that it is the CA cert and verified and shows the IP address correctly. I'll have to recreate it and see how it goes. I do know that when I did the request from the internal Windows CA server there were many options on what type of certificate template request to choose from, I chose web server.

Thanks.

[Marvin Rhoads · Accepted solution]

OK - sounds like you're on the right track.

On further reflection, it may be a Java thing. It does some odd things and might not be respecting the Windows Trusted Root certificate store.

When you get the security warning that pops up when connecting your ASDM launcher to the ASA, there is a "More Information" hyperlink. Clicking it should give you some details of why Java is complaining about the certificate validity.

[tolinrome tolinrome]

Yes, that was actually it. It was Java. The error message was saying:

"The digital signature for this application was generated with a certificate from a trusted certificate authority, but we are unable to ensure that it was not revoked by that authority."

In the Java control panel, under "Perform TLS certificate revocation check on" - I chose "Do not check (not recommended)". The problem was resolved. 

Although I wonder why its checking with TLS and not SSL? Also a problem that Java cant even verify from the ASA that its not in the revoke list.

[Marvin Rhoads · Accepted solution]

Great - glad we were able to resolve that. Please mark the question as answered if it has been.

Generally speaking SSL/TLS-based communications will negotiate during session establishment to the highest mutually acceptable (i.e. most secure) cryptographic protocol.

Java has been notoriously insecure and over the course of updates it will always try to "lock down" itself. So be careful when you do a Java update not to allow it to "Restore Java Security prompts" (I think that's what they call the option) during the upgrade process.

I have also, in my Java environment, added in the Java Cryptographic Extensions (JCE) which add even stronger crypto support. Unfortunately I have to re-add them every time I update Java since they are a separate download from Oracle.

http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

[tolinrome tolinrome]

Thank you very much.