Installing a Cert on an ASA 5510 using Microsoft CA

[gp1200x]

We are having issues getting a cert on an ASA 5510 for out outside interface. All of our PCs have machine certs from an inhouse Microsoft CA. We are trying to put a cert from this CA on our ASA 5510 outside interface so that the end users do not get the annoying cert unknown message from the self signed cert we currently use. 

The cert is from a intermediary cert server off of our root CA. We are using the same trustpoint name trying to install the root (which does on) but the intermediary cert won't since it appears I cannot have both certs using that same trustpoint name. What are we doing wrong?  The certs are in an email form so we are cutting and pasting and it seems to be the correct formats ..... its just we can't put both certs on the same trustpoint. If we change the intermediary to some other trustpoint name it applies but then the cert for the ASA device itself will not install correctly. Is there a writeup for this specific installation?  Do we need to use the root CA to create the cert directly?   Can we just use the intermediary cert and device cert to get this to work?  Each cert has a separate email we trying to paste from.  

Code 8.2.5-59   ASDM 7.62

Thanks

[Philip D'Ath]

Could you upgrade your ASA to software semi-current, like asa917-15-k8.bin?  8.2(5) is something like 6 years old now.

I think an easy way would be to export the certificate from your intermediate CA as a *.PFX file, with a complete certificate chain (root, intermediate, public+private), and import that in one go using the ASDM.

[Marvin Rhoads · Accepted solution]

In principle what you are doing should not differ greatly from using a certificate from a public CA and providing the entire trust chain on the ASA. I do this ofthen to make the installation more complete and it helps the setup pass a third party check like Qualys' SSL checker.

https://www.ssllabs.com/ssltest/index.html

When I do so, I just install the root and any intermediate certificate as separate trustpoints. For instance, my most recent one used a Comodo wildcard certificate. The wildcard is installed as SSLVPN trustpoint which is used as the identity certificate and bound to the outside interface. Comodo's intermediate and public root CAs are installed as CA certificates and appear as such to clients, thus validating the identity certificate chain to a commonly trusted root. (Technically I could probaly omit the root as it's in the browser's trust store but I do it for completeness.)