This document describes the best practice and alternative scenario for deploying ASA-5500 VPN remote access solution in a Load Balancing/Clustering environment using digital certificates authentication.
For more information on VPN Load Balancing/Clustering High Availability services of the ASA appliances please consult the configuraiton guide at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/vpnsysop.html#wp1048834. Please check cisco.com for new versions of the document.
For more information on configuring Certificates on the the ASA appliances please consult the configuraiton guide at
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/cert_cfg.html .Please check cisco.com for new versions of the document.
I. Best Practice procedure for deploying with one Unified Client Certificate (UCC)
General Steps:
1) Obtain One UCC with multiple SANs (Subject Alternative Name extensions) with each ASA FQDN/IP included.
Therefore you need one UCC certificate with the CN for the cluster FQDN and/or cluster IP, and SANs for each ASA in hte cluster: ASA-1 FQDN and/or IP, ASA-2 FQDN and/or IP, and so on. Several PKI/Certificate vendors such as Entrust.com support UCC , a.k.a Unified Client Multi-Domain SSL certificates.
Note: The ASA cannot generate a Certificate Signing Request (CSR) with multiple SANS (CSCso70867 is the enhancement asking for this capability ), so you have to have the CA/PKI vendor submit the enrollment for you.
2) On ASA master configure one trustpoint '<name>' pointing to the virtual/cluster.
Example of CLI is below:
crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
enrollment terminal
Now import the certificate obtained from the CA/PKI vendor:
crypto ca import certificate command.
The adaptive security appliance prompts you to paste the certificate to the terminal in base-64 format.
3)Then export that trustpoint as pkcs12 (certificate and keys will be exported)
crypto ca export asa-cluster pkcs12 <passphrase>
Copy the resulting output and save it to a text file.
4)Then import the pkcs12 to each ASA member of the cluster
crypto ca import asa-cluster pkcs12 <passphrase>
5)Configure all ssl <interface and ssl outside vpnloadbalanced commands pointing to the imported trustpoint '<name>'.
6) Initiate your VPN remote access sessions (IPsec clients, AnyConnect SSL client,Clientless browser-based SSL VPN) to the Load Balanced Virtual IP (VIP) or FQDN.
II. Alternative using Multiple Certificates or Wilcard Certificates
- A) requires n+1 number of IP addresses and/or DNS-FQDN and n+1 number of certifcates.
The example below deploys a 2 node-cluster, therefore 3 IPs/DNS-FQDNs are needed.
-Three certificates (one for asa-cluster, one for asa1, and one for asa2) are required
- B) One wilcard certificate
Wilcard certificates are discouraged in favor of UUC certs. According to one vendor, Entrust, these are 2 main reasons:
- UCC is more secure than wildcard certificates since Entrust UC Certificates specify exactly which hosts and domains are to be protected
- UCC is more flexible than wildcard certificates since Entrust UC Certificates aren't limited to a single domain
The procedure for using Multiple Certifcates follows:
Configuration example with two ASAs operating as a Load-balancing cluster using multiple certificates
VPN cluster IP address: 10.10.1.1
ASA1 outside IP: 10.10.1.2
ASA2 outside IP: 10.10.1.3
DNS Configuration (domain = company.com):
hostname: IP:
asa-cluster 10.10.1.1
asa1 10.10.1.2
asa2 10.10.1.3
VPN Load Balancing configuration ( on all ASA's in the cluster)
vpn load-balancing
redirect-fqdn enable
cluster ip address 10.10.1.1
participate
Name Resolution: The redirect-fqdn enable setting makes the ASA issue a redirect using hostname as opposed to IP address. This *requires* that the DNS in use has appropriate reverse dns records for hostnames involved in order to function, and that the ASA, not the client, can do this resolution.. This should be configured to avoid certificate hostname mismatch popup warnings.
To test that name resolution is working on the ASA, issue a ping command to the cluster's fqdn, and to each member's fqdn. All ASA cluster members should be able to resolve those names in order for redirect to work.
As a workaround, you can put names on the ASA itself to resolve those addresses, if DNS is not an option
Example:
name 10.10.1.1 asa-cluster.example.com
name 10.10.1.2 asa1.example.com
name 10.10.1.3 asa2.example.com
After this, the asa should be able to resolve asa-cluster.example.com, asa1.example.com, and asa2.example.com. You can test this by issuing a ping to all 3 addresses. ICMP may not work, but the asa should be able to give you an IP address for each of the names. If it doesn't, please check name resolution again as redirect-fqdn will not work without it.
Trustpoint configurations
1) asa1 ID certificate trustpoint
crypto ca trustpoint myca
subject-name CN=asa1.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
Optionally ou could include CN=<asa1 IPAddress> in DN above.
2) asa2 ID certificate trustpoint
crypto ca trustpoint myca
subject-name CN=asa2.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
Optionally ou could include CN=<asa2 IPAddress> in DN above.
3) load-balancing trustpoint - configured on either ASA and can be imported to all other ASAs in the cluster
crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
Optionally ou could include CN=<asa-cluster IPAddress> in DN above.
4) Exporting and Importing Load balancing trustpoint to member ASAs
Once this trustpoint is authenticated and enrolled (both CA and ID certs are present) it can be exported to pkcs12 and imported to all load-balancing cluster member ASAs using the following procedure:
a. Export the trustpoint (certificates and keys) to a password protected pkcs12.
crypto ca export asa-cluster pkcs12 <passphrase>
Copy the resulting output and save it to a text file.
b. Import the pkcs12 to other ASA's
crypto ca import asa-cluster pkcs12 <passphrase>
Paste pkcs12 data in and enter 'quit' on a line by itself when finished to end the process.
Note: The export/import process only migrates the certificates/keypair from one device to another. Any necessary trustpoint configuration must be manually reconfigured (like revocation-check, CRL options, etc.).
Important note: In versions prior to 8.0(3)6, you were unable to export a trustpoint that only had the ID certificate properly. This created an issue because in ASDM, the ID certificate and the CA certificate were put in 2 different trustpoints. If you run into an issue where you do the import of the cluster certificate on a cluster member, and it says it was successful but the certificate doesn't show up, this is most likely your issue. Go back to the ASA that issued the CSR for the cluster certificate, and authenticate that trustpoint with the issuing certificate and then re-export it. See CSCsl59266 for more details.
At this point the asa-cluster certificates are installed and can be used to correctly identify SSL requests that come into the cluster IP address/hostname .
SSL configuration for using the LB certificate
ssl trust-point myca outside
ssl trust-point asa-cluster outside vpnlb-ip
III. Client Connection Experience for Clientless SSL VPN using a browser
The client connection experience using a browser (Clientless SSL VPN) is as follows:
a. Client browses to https://asa-cluster.company.com and ASA sends its ID cert to the client. Note: If client certificate authenticaiton is enabled , client will be prompted to choose a ID certificate fro mthe browser popup.
- The issuer of the ASA certificate should be trusted by the client and therefore shouldn't warn.
- The name that was browsed to (asa-cluster.company.com) is in the ASA cluster certificate so it shouldn't warn of hostname mismatch.
b. Cluster master decides best ASA to redirect to (asa2 in this example) and sends a redirect to client.
c. Client silently initiates new connection to https://asa2.company.com and ASA2 sends its ID cert to the client.
- The issuer of the ASA certificate should be trusted by the client and therefore shouldn't warn.
- The name that was browsed to (asa2.company.com) is in the ASA2 certificate so it shouldn't warn of hostname mismatch.
d. Client experience depends on ASA authentication configuration.
- AAA only - client is prompted to authenticate at login portal and/or choose a group (if tunnel-group-list enable and group-alias is set)
- Certificate authentication only with group-url or certificate map - client is connected and sees webvpn portal/links, etc.
- Certificate authentication only without group-url or certificate map (group-alias is enabled instead) - client must select a group from portal and click connect. Connection complete.
- AAA + Certificate authentication - with group-url or certificate map - Certificate autheentication takes place, then client will be prompted for AAA; after entering, connection is complete.
- AAA + Certificate authentication - without group-url or certificate map (group-alias is enabled instead) - client will be prompted for aaa and group selection (if tunnel-group-list enable is set); after entering, connection is complete.
