Hello Susan,
The ASA can be enrolled with a CA (internal like Microsoft or external like VeriSign) and that will result in the ASA having one or more CA certificates as well as one Identity certificate. The Identity cert is what the ASA would use to authenticate itself to clients connecting in (i.e. clientless, AnyConnect, Cisco VPN client, site-to-site, etc.). Going with a VeriSign or similar CA is the most desirable option because all the client browser will automatically trust it. If you go with an in house CA you will need to install the CA cert on all the clients browsers (or they will warn of untrusted issuer cert when connecting).
For SSL (clientless or AnyConnect SSL), without enrolling the ASA with a CA what it will send to clients connecting in is a dynamic auto-generated self-signed cert. This is the least desirable option as it will likely result in the clients getting hostname mismatch and/or untrusted browser warnings.
When any client makes a connection into the ASA, the ASA will send a list of trusted cert DN's down to the client. This allows the client to pick a cert that is issued by one of the CAs that the ASA trusts. For the configuration you mentioned your ASA would have two or more CA certs which it would communicated to the clients. You don't need to link any of the ASA certs to the interfaces for clients to authenticate using certificates from different CAs. The ASA certificate you link to an interface via ssl trustpoint interface , is just the one that you want to ASA to use to identify itself to the clients (the server's certificate).
For example, if let's'say your ASA has 2 trustpoints TP#1 and TP#2.
- TP#1 holds the CA and ASA ID certificate from Verisign.
- TP#2 holds the CA and ASA ID certificate from a private CA
By default all browsers will have Verisign available in the Trusted Root Authorities Certificates store but not the private CA root .
- User John , an employee, has a personal/ID certificate from Verisign in his browser and is allowed to use AnyConnect.
- User Ann , a consultant, has a personal/ID certificate from private CA in her browser and is allowed to use Clientless only.
1) What is the end user behavior if ssl trustpoint TP#1 interface outside is configured on the ASA?
Both the ID certificates from John and Ann will be validated against the 2 CAs, andconnect just fine without any popups, since Verisign is a trusted Root Certificate on both PCs.
2) What is the end user behavior if ssl trustpoint TP#2 interface outside is configured on the ASA?
User Ann will connect just fine without any popups, since Private CA is in the Trusted Root Certificate store on Ann's PC.
User John will be presented with a popup warning that Private CA certificate is untrusted ,since this Private CA is not included by default in Trusted Root Certificate store on John's PC. John can choose to trust the ASA's Private-CA certificate permanently and will not receive any more warnings on subsequent connection attempts. The session operates normally thereafter.
-Gustavo
