I have a need to have different certificates for different connection types on an ASA. One certificate for SSL AnyConnect connections and another certificate for clientless SSL connections. I was able to install the two certificates on the ASA. But, I am unable to assign them based on the connection. When create a connection type and assign the certificate, the certificate on the outside interface changes.
Could you elaborate further on your requirements...
Jennifer is right and you cannot tie multiple certificates to a single interface but what are you trying to do? If what you are doing is certificate authentication for your AC Clients then you dont need to attach the identity certificate to the interface nor to the tunnel-group as we used to do with the legacy IPsec. In fact the certificate that is tied to the interface is just the SSL certificate of the ASA and its not used for user authentication.
I wanted to ask a question regarding your reply to the support forums post here:
The original poster decided to go with to ASA devices, but I’m thinking that from your reply, that it is possible to authenticate SSL connections via the cert attached to the external interface, but to ALSO on the same ASA device authenticate AnyConnect connections via a different cert. Am I correct? If so, can you point me to a location where this configuration is documented? Thanks!
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...