Tunnel Groups
Tunnel groups were introduced in version 7 of the appliance and are unique to Cisco appliances—Cisco routers and concentrators don’t support this type of functionality. Tunnel groups are used to identify information that should be used for a particular VPN type and peer, like an IPSec L2L connection or an IPSec or WebVPN remote access group of users.
Tunnel groups have two basic attributes:
-
General
-
VPN-specific
General attributes are non-VPN-specific and can specify things like the AAA servers to use, where the policies are stored (local to the appliance or on an AAA server), where to find the usernames and passwords to authenticate remote access users, and other information. VPN-specific attributes define properties for the tunnel group that are specific to a particular VPN type, like a pre-shared key or digital certificate to use for an IPSec L2L connection, the use of Dead Peer Detection (DPD) for IPSec connections, or what the home page looks like for clientless WebVPN sessions.
The following sections will introduce you to tunnel groups: how to create them, and how general and VPN-specific properties are associated with tunnel groups. Subsequent chapters in Part IV will discuss tunnel groups in much more depth, covering the commands and parameters that apply to a particular VPN type.
Tunnel Group Creation
A tunnel group, as I mentioned in the last section, represents a particular IPSec L2L connection or a remote access group. To create a tunnel group, use the following command:
ciscoasa(config)# tunnel-group tunnel_group_ID type vpn_type
The tunnel_group_ID uniquely identifies the tunnel group. For example, if the identity for L2L connections were “address,” then the tunnel group ID would be the IP address of the peer; if the identity type were “hostname,” then the group ID would be the fully qualified domain name of the peer. For IPSec and WebVPN remote access users, the tunnel group ID represents the name of the group, like “sales”, “engineers”, or “programmers”.
Following the tunnel group ID is the type of VPN that represents the group. In version 8, you can specify only two parameters:
-
ipsec-l2l The “l2l” part is really “L-2-L,” not “one-two-one”: this represents IPSec site-to-site or L2L connections.
-
remote-access This represents IPSec and WebVPN remote access user groupings.
| Note | In prior appliance versions, instead of remote-access, you had ipsec-ra and webvpn-ra, where these two VPN types were represented by different groups. In version 8, these are no longer supported (they’ve been deprecated): both types are represented by the remote-access type. |
General Tunnel Group Attributes
As I mentioned previously in the introduction to tunnel groups section, general tunnel group attributes are parameters associated with a tunnel group that have no bearing on the type of VPN that is being used. For example, if you had a remote access tunnel group called “engineers,” general properties for the group would include whether an AAA server was used, where the user accounts were located for user authentication, and where the VPN-specific attributes of the group were found.
Once you’ve created your tunnel group, you can assign the general attributes to the tunnel group with the following configuration:
ciscoasa(config)# tunnel-group tunnel_group_ID general-attributes
ciscoasa(config-tunnel-general)# ?
group_policy configuration commands:
accounting-server-group Enter name of the accounting server
group
address-pool Enter a list of address pools to assign
addresses from
annotation Specify annotation text - to be used by
ASDM only
authentication-server-group Enter name of the authentication server
group
authorization-dn-attributes The DN of the peer certificate used as
username for authorization
authorization-required Require users to authorize successfully
in order to connect
authorization-server-group Enter name of the authorization server
group
default-group-policy Enter name of the default group policy
dhcp-server Enter IP address or name of the DHCP
server
exit Exit from tunnel-group general attribute
configuration mode
help Help for tunnel group configuration
commands
ipv6-address-pool Enter a list of IPv6 address pools to
assign addresses from
no Remove an attribute value pair
override-account-disable Override account disabled from AAA
server
password-management Enable password management
strip-group Enable strip-group processing
strip-realm Enable strip-realm processing Notice that you are taken into a subcommand mode where you can configure your general attributes. I’ll be discussing these attributes in subsequent chapters of Part IV.
VPN-Specific Tunnel Group Attributes
Once you’ve created your tunnel group, to associate VPN-specific attributes to it, use the following command:
{ipsec-attributes | webvpn-attributes}
ciscoasa(config-tunnel-{ipsec|webvpn})#
You have two options for the type of attributes, depending on the type of tunnel group: IPSec attributes or WebVPN attributes. You’ll be taken into a subcommand mode where you can specify the VPN-specific attributes. I’ll be discussing these attributes in subsequent chapters of Part IV.
Certificate Authorities
Certificates are the most scalable solution to perform device authentication with VPNs. Certificates must be created by a neutral third-party, called a certificate authority (CA). The appliances support many CAs, including RSA, VeriSign, Netscape, Baltimore, Microsoft, Entrust, Cisco IOS routers, and the security appliances themselves (not discussed in this book). The remainder of this chapter will introduce the use of certificates, how to obtain certificates for appliances, and how to use certificates to authenticate devices for IPSec sessions.
Introducing Certificates
There are two types of certificates: root and identity. Every device participating in the certificate process must have a certificate, including the CA itself. The certificate for the CA is called a root certificate, and certificates for other devices are called identity certificates. Obtaining an identity certificate can be done either out-of-band using the file-based approach or in-band using the Simple Certificate Enrollment Protocol (SCEP), which uses HTTP.
To use certificates, the peers must have an ISAKMP Phase 1 policy that supports certificates (RSA signatures). During authentication, two items are checked, and a third is optional. For the two required items, the peers validate the digital signature on the certificate and then make sure the certificate hasn’t expired. With the third item, an option exists for checking if a peer certificate has been revoked: the use of Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) is supported. A CRL contains a list of all the certificates that have been revoked. CRLs can be downloaded when they are needed, which can be bandwidth-intensive and introduce delay in the VPN setup process, or they can be downloaded periodically and cached, which can create problems of not having the most up-to-date list when authenticating a peer. OCSP, on the other hand, has the device perform a query, with the remote peer serial number on the identity certificate, to the OCSP server in order to determine if the certificate has been revoked. Using OCSP is the preferred method.
Obtaining Certificates
The following sections will discuss how to obtain the root certificate of the CA and how to generate the certificate information, defined by the Public Key Cryptography Standards (PKCS) #10 standard, which the CA needs to create an identity certificate for the appliance.
Identity Information on the Certificate
When generating your PKCS #10 certificate information, by default the appliance associates a common name (CN) of the appliance hostname and domain name configured on the appliance. You can override this behavior and assign your own key label when generating the key pair, as you’ll see in the “Basic Trustpoint Configuration” section.
To assign a name and domain name to your appliance, use the following configuration:
ciscoasa(config)# domain-name your_appliance's_domain_name
These commands were discussed in Chapter 3.
Key Pairs
Cisco supports both the RSA and DSA algorithms for generating public/private keys; these are used to sign the PKCS #10 information. DSA is quicker in generating its keys, but is less secure; and not all CA products support DSA. Because of these limitations, this book only focuses on the use of RSA keys.
Generating RSA keys was discussed in Chapter 3; however, then I didn’t discuss all the options available with the command. Here’s the full syntax of the command:
[label key_pair_label] [modulus key_size]
[noconfirm]
The usage-keys parameter generates two sets of keys, while the general-keys parameter generates one key pair; the default is general-keys if you omit it, which is what you need for certificate purposes. Use usage-keys if you need two identity certificates from the same CA, which is uncommon. If you don’t specify a label for the key pair, it defaults to “Default-RSA-Key.” If you don’t specify a modulus (the size of the keys, in bits), it defaults to 1024: other valid sizes include 512, 768, and 2048. The noconfirm parameter, when configured, will execute the command without any interaction on your part—the default is to prompt you for verification. Use the show crypto key mypub key command to view the public keys on your appliance.
| Tip | |
Here’s an example of generating an RSA key pair:
INFO: The name for the keys will be: mykeys
Keypair generation process
ciscoasa(config)#
In this example, a key pair label of “mykeys” is used to name the key pair.
| Note | |
Date and Time
Items validated on the certificate are two dates: when the certificate becomes valid and when it is no longer valid. The device will compare its local date and time with the dates and times that appear on the certificate, ensuring that the device time falls between the two periods. You can hard-code the date and time on the appliance with the clock set command:
This is the same command used on Cisco IOS devices.
| Note | |
Basic Trustpoint Configuration
The CA, commonly called a trustpoint, configuration on the appliance defines the properties used to interact with a CA as well as to obtain certificates—root and identity. You must configure the trustpoint properties on the appliance before you can obtain the two certificates. This section will discuss some basic trustpoint configuration commands, and subsequent sections will cover how to obtain certificates and CRLs (Certificate Revocation Lists).
Here are the basic trustpoint configuration commands:
ciscoasa(config-ca-trustpoint)# subject-name X.500_info
ciscoasa(config-ca-trustpoint)# email email_address
ciscoasa(config-ca-trustpoint)# fqdn fully_qualified_domain_name
ciscoasa(config-ca-trustpoint)# ip-address IP_address
ciscoasa(config-ca-trustpoint)# serial-number
ciscoasa(config-ca-trustpoint)# keypair key_pair_label
ciscoasa(config-ca-trustpoint)# keysize {512 | 768 | 1024 | 2048}
ciscoasa(config-ca-trustpoint)# id-usage ssl-ipsec
ciscoasa(config-ca-trustpoint)# client-types {ipsec | ssl}
ciscoasa(config-ca-trustpoint)# accept-subordinates
Setting up a trustpoint is similar to how it’s done on a Cisco IOS router. First, you specify the name of the trustpoint, which takes you into a subcommand mode. The name of the CA is a locally significant name and doesn’t have to match the actual name of the server unless specified by the administrator of the CA.
| Note | |
Optionally you can specify the X.500 information that will appear on the requested X.509v3 identity certificate with the subject-name command. If you don’t configure this value, the common name (CN) defaults to the fully qualified domain name (FQDN) of the appliance. If you want to change it, you have to know the field values to use for the certificate information. Here’s an example:
cn=asa1.cisco.com,ou=mydepartment,o=cisco
In this example, the identity name on the certificate is “asa1.cisco.com”, the organizational unit (OU) or department value is “mydepartment”, and the organizational value (O) is “cisco”.
Optionally you can have the CA include an e-mail address in the Subject Alternative Name (SAN) extension field of the certificate with the email command; however, this is not required. Instead of an e-mail address, you can include an FQDN of your choice in the SAN field with the fqdn command. The last two options you have for information that appears on the certificate are to include an IP address (associated with the appliance) with the ip-address command and/or the appliance serial number with the serial-number command.
The key-pair command specifies either an existing key-pair label to use or the name of one that will be created. The key-size command specifies the length of the keys to create when they don’t exist. These two commands, when used together, will generate a new key pair when obtaining an identity certificate versus using an existing key pair on the appliance.
The id-usage command specifies how the identity certificate associated with the trustpoint can be used. With the ssl-ipsec parameter, the identity certificate can be used for SSL VPN and IPSec VPN authentication when the appliance is acting as the server/gateway, which is the default behavior. You can disable this by prefacing the command with the no parameter. The client-type command controls what type of VPN remote clients the certificate can be used for. There is no default value.
The accept-subordinates command specifies whether subordinate CA certificates (in a CA hierarchical implementation) are accepted by a peer during ISAKMP/IKE Phase 1 authentication when the local appliance currently doesn’t have these certificates installed. The default is that this command is enabled.
| Note | |
Network Enrollment—SCEP
There are two methods to obtain the CA (root) certificate and the appliance identity certificate:
- Network enrollment using the Simple Certificate Enrollment Protocol (SCEP)
- File enrollment using an out-of-band approach
This section will discuss the former, and the next section will discuss the latter.
| Note | |
Configuring SCEP Enrollment Parameters
To configure network enrollment using SCEP, the following commands (and possibly the commands discussed in the last section) are used:
ciscoasa(config-ca-trustpoint)# enrollment url URL
ciscoasa(config-ca-trustpoint)# password challenge_password
ciscoasa(config-ca-trustpoint)# enrollment retry count #_of_attempts
ciscoasa(config-ca-trustpoint)# enrollment retry period #_of_minutes
You have to first define the name of the trustpoint, which was discussed in the last section. This takes you into the trustpoint subcommand mode. You then specify how you’ll obtain a certificate: the enrollment url command specifies the use of SCEP. The URL is HTTP-based, and the actual syntax depends on the CA product you’ll interface with. Here’s an example using a Microsoft CA:
ciscoasa(config-ca-trustpoint)# enrollment url
http://172.26.26.151:80/certsrv/mscep/mscep.dll
| Note | |
The password command specifies the challenge password to use during the certificate request process. The password is hashed with the certificate information, which is validated by the CA using the same password. If you are using challenge passwords, which I highly recommend, the CA administrator will have to create one for you. Depending on the administrator’s setup of the CA, the password might be time-sensitive (only valid for a specific amount of time).
The enrollment retry count specifies a maximum number of permitted retries for SCEP enrollment before giving up. The enrollment retry period command specifies a retry period, in minutes, between SCEP enrollment requests when the CA is unreachable.
| Note | |
Obtaining Certificates Using SCEP
Once you have specified your CA and your enrollment command(s), you need to first download the CA root certificate and validate it with the crypto ca authenticate command:
When you get the fingerprint back from the CA on the root certificate—this is the self-signed signature the CA placed on its own certificate—verify the fingerprint by calling the CA administrator and manually comparing the two values. This is the only part of the certificate process that is susceptible to a man-in-the-middle attack.
Here’s an example of obtaining the CA root certificate:
INFO: Certificate has the following attributes:
Fingerprint: 3736ffc2 243ecf05 0c40f2fa 26820675
Do you accept this certificate? [yes/no]: yes
Trustpoint 'caserver' is a subordinate CA and holds a non self signed
cert.
Trustpoint CA certificate accepted.
Make sure you validate the fingerprint/signature that is on the root certificate, since this certificate is used to validate any other certificate associated with this CA.
Once you have the root certificate, you can obtain your identity certificate with the following command:
ciscoasa(config)# crypto ca enroll caserver
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
% password to the CA Administrator in order to revoke your certificate.
% For security reasons your password will not be saved in the
% configuration.
% Please make a note of it.
Password: abc123
Re-enter password: abc123
% The subject name in the certificate will be: asa.example.com
% The fully-qualified domain name in the certificate will be:
securityappliance.example.com
% Include the device serial number in the subject name? [yes/no]: no
Request certificate from CA [yes/no]: yes
% Certificate request sent to Certificate authority.
The certificate has been granted by CA!
As you can see in the preceding example, you are prompted for a challenge password—you must enter something here even if the CA is not using challenge passwords. You have the option of including the serial number of the appliance on the certificate, and then the appliance requests the certificate.
File Enrollment—Manual
Once you have configured the basic trustpoint commands from the “Basic Trustpoint Configuration” section, you can use the enrollment terminal command in the trust-point subcommand mode to enable the file-based approach to obtain certificates:
ciscoasa(config-ca-trustpoint)# enrollment terminal
The enrollment terminal command enables file-based enrollment.
Once you have configured the trustpoint, you can then generate your PKCS #10 certificate information for the CA with the crypto ca enroll command, discussed in the last section. Here’s an example:
% Start certificate enrollment ..
% The fully-qualified domain name in the certificate will be: asa5505-1
% Include the device serial number in the subject name? [yes/no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
MIIBjTCB9wIBADAaMRgwFgYJKoZIhvcNAQkCFglhc2E1NTA1LTEwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAK04Czj3ZY9GJ1o4m5wDWdYwvGOSbrlgRp782k8H
<--output omitted-->
---End - This line not part of the certificate request---
Redisplay enrollment request? [yes/no]: no
Make sure the certificate information between the “Certificate Request follows” and “--End - This line” lines is included—copy and paste this into a file, and give the file to the CA administrator.
The CA administrator will then use this information to create an identity certificate for the appliance. The administrator will then send back two files: one contains the root certificate, and one contains the identity certificate. You’ll need to load these onto the appliance in the listed order.
Use the crypto ca authenticate command to import the CA root certificate. Here’s an example:
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
<--paste in the CA's root certificate-->
quit
INFO: Certificate has the following attributes:
Fingerprint: 24b81433 409b3fd5 e5431699 8d490d34
Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
ciscoasa(config)#
You need to type the word quit upon entering the CA certificate information—this must be on a separate, blank line. Then you must accept the root certificate.
Once you have manually imported the root certificate, you can then import the appliance identity certificate with the crypto ca import command. Here’s an example:
% The fully-qualified domain name in the certificate will be:
ciscoasa.cisco.com
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
<--paste in your certificate-->
quit
INFO: Certificate successfully imported
| Note | |
Certificate Revocation Lists
A Certificate Revocation List (CRL) is a list of certificate serial numbers that have been revoked by the CA. Certificates can be revoked because they have expired, the device associated with a certificate has become compromised, the device is no longer being used, or a change in the security policy requires new certificates (like requiring longer key lengths).
The use of CRLs is controlled by the following trustpoint configuration:
ciscoasa(config-ca-trustpoint)# revocation-check crl [none]
ciscoasa(config-ca-trustpoint)# revocation-check ocsp [none]
ciscoasa(config-ca-trustpoint)# revocation-check none
The revocation-check command specifies how and if CRLs are used. The crl parameter specifies that a CRL is downloaded using HTTP, SCEP, or LDAP from a specified location and cached locally; adding the none parameter specifies that if the CRL cannot be found, then it is not used (CRLs are optional). The ocsp specifies that the Online Certificate Status Protocol (OCSP) is used instead of CRLs to determine if a certificate has been revoked; adding the none parameter specifies that if the OCSP server cannot be found, then it is not used (OCSP is optional). The none parameter, by itself, specifies that CRLs and OCSP are not used during device authentication.
| Note | |
CRL Usage
When using CRLs to determine if a certificate has been revoked, the appliance will periodically download and cache the CRL list. To tune this process, you can use the following configuration:
ciscoasa(config-ca-trustpoint)# crl configure
ciscoasa(config-ca-crl)# policy {cdp | static | both}
ciscoasa(config-ca-crl)# url number URL
ciscoasa(config-ca-crl)# protocol {http | ldap | scep}
ciscoasa(config-ca-crl)# cache-time minutes
ciscoasa(config-ca-crl)# enforcenextupdate
ciscoasa(config-ca-crl)# ldap-defaults server_name_or_IP [port_#]
ciscoasa(config-ca-crl)# ldap-dn directory_path password
To configure parameters for CRL usage, in the trustpoint configuration execute the crl configure command—this will take you into a second subcommand mode. The policy command specifies where to find the CRL list. The cdp parameter, which is the default, specifies that the CRL location will be found by examining the CA root or an RA (Registration Authority) identity certificate. The static parameter specifies that you will configure a static entry or entries on the appliance as to where to find the CRL. The both parameter specifies that the appliance will attempt to use the location on the CA/RA certificate to find the CRL, but if this is unsuccessful, then a static entry on the appliance will be used.
To configure a static entry, use the url command. The number following the command ranks the entry in the order that it should be used. You can create up to five entries, where the number ranges from 1 to 5. Following the number is the actual URL, like “http://172.26.26.151/crldir/caserver.crl”. The protocol command specifies the protocol that will be used to retrieve and process the CRL list. All three protocols are allowed by default; you can use the no parameter to disable a particular protocol if necessary. The cache-time command specifies how long the CRL list is cached locally on the appliance before the CRL list is downloaded again. The default is 60 minutes and can be as large as 1440 minutes. The enforcenextupdate command specifies that the “NextUpdate” field in the CRL must not have expired in order for the CRL itself to be considered valid. By default this is enabled; to disable it, preface the command with the no parameter.
If the CRL is located on an LDAP server and the appliance needs to use the LDAP protocol to access it, you’ll have to define how the appliance should interface with the LDAP server. The ldap-defaults command specifies the LDAP server the CRL is located on. You can either specify the name or IP address of the server; with the former, you must be able to dynamically or statically resolve this to an IP address. If you don’t configure an LDAP port number, it defaults to 389. If the LDAP server requires authentication to access the CRL, use the ldap-dn command to specify the login credentials. The directory path is basically the X.500 information to access the CRL. Here’s a simple example: cn=crl, ou=certs, o=caserver, c=US. This field cannot exceed 128 characters. The directory path is then followed by the LDAP password, which also cannot exceed 128 characters.
OCSP Usage
There are a couple of problems with CRLs. First, the list can be quite long and must be downloaded and stored locally on a device, which can take up space like RAM, flash, or disk space. Second, once the CRL is downloaded, if certificates are revoked by the CA, a device with a cached CRL won’t know this until its cache timer expires and the updated CRL is downloaded—so there is a chance that a revoked certificate would appear as valid to some devices in the network.
OCSP was created to solve these two problems. Instead of downloading a long list and caching the information, OCSP uses a query process: when a device needs to determine if a certificate has or hasn’t been revoked, it sends a query to an OCSP server, which responds with the status of the queried serial number. If you have a large installed base of devices using certificates, OCSP scales much better than using CRLs.
To use OCSP, implement the following configuration:
ciscoasa(config-ca-trustpoint)# revocation-check ocsp [none]
ciscoasa(config-ca-trustpoint)# ocsp url URL
ciscoasa(config-ca-trustpoint)# match certificate map_name
override ocsp [trustpoint trustpoint_name]
sequence_num url URL
ciscoasa(config-ca-trustpoint)# ocsp disable-nonce
The revocation-check command was discussed earlier in the section. The oscp url command specifies how the appliance should contact the OCSP server. HTTP is the protocol used, so an example URL might look like this: “http://172.26.26.151”. If you need to validate certain certificates using a different OCSP server, you can create a certificate map, which matches on one or more certificates, and associate this with the appropriate OCSP server (certificate maps and matching are discussed later in the “Certificate Group Matching” section).
OCSP requests sent by a device to the OCSP server include a nonce extension (basically a signature). The OCSP server should use this information in crafting its response, also creating a nonce extension—basically the nonce extension is used to bind the request and response in order to defeat replay attacks. However, some OCSP server implementations don’t dynamically create the nonce extension; instead, they use a pre-generated response. In this situation, the appliance would see the response as invalid, reject it, and thus authentication of a peer certificate would fail. To disable the use of the nonce extension, use the ocsp disable-nonce command.
Certificate Management
The following sections will discuss how to manage certificates on your appliance: how to save them, how to view them, and how to troubleshoot problems with them.
Saving Certificates
Prior to version 7.0, the ca save all command was used to save certificate and keying information on the PIXs. Starting in version 7.0, this command was deprecated. Now to save the certificate and keying information on the appliances, just use the write memory command.
Viewing Certificates
To view the certificates (root and identity) on your appliance, use the following command:
ciscoasa# show crypto ca certificates [trustpoint_name] Here’s an example of viewing a certificate:
CA Certificate
Status: Available
Certificate Serial Number 2957A3FF296EF854FD0D6732FE25123
Certificate Usage: Signature
Issuer:
CN = caserver
OU = rootou
O = dealgroup
L = oviedo
ST - florida
C = US
EA = admin@dealgroup.com
Subject:
CN = caserver
OU = rootou
O = dealgroup
<--output omitted-->
Notice that the certificate has a serial number at the top, which was assigned by the CA. Below this is who issued the certificate (Issuer section) and whom the certificate is for (Subject section). In the preceding example, the Issuer and Subject information is the same, meaning that this is the certificate of the CA.
Troubleshooting Certificate Problems
One of the most common problems of obtaining and using certificates involves the date and time. When validating a certificate, two things are required, and a third thing is optional. The first two things are comparing the device current time with the beginning and ending time on the certificate (if the device current time falls between these two, then the first authentication step passes), and validating the signature on the certificate. Optionally the device can check to see if the certificate has been revoked by using CRLs or OCSP.
Since the date and time are important in validating certificates, I highly recommend that you don’t statically define the date and time, but use the Network Time Protocol (NTP) to make sure your CA and devices acquiring and using certificates are in synch with each other. The configuration of NTP on the appliances is discussed in Chapter 26.
To troubleshoot all other problems related to obtaining and/or using certificates, use the following command:
ciscoasa# debug crypto ca [messages | transactions] [level_#] The messages parameter displays only debug messages for PKI input and output messages. The transactions parameter displays debug messages for PKI transactions. Not specifying either will include both in the debug output. Optionally you can include a level number in the debug command, which qualifies the amount of output displayed. This can range from 1 to 255. Level 1, the default, displays error messages; level 2 displays warnings; level 3 displays informational messages; and level 4 and higher display additional troubleshooting information.
Using Certificates
The following sections will discuss how to use certificates on your appliance—specifically, how you specify which identity certificate, when more than one is on the appliance, should be used for a particular peer.
Tunnel Groups and Certificates
Tunnel groups were briefly introduced earlier in the “Tunnel Groups” section. Their use will be discussed in much more depth in Chapters 16 and 17. This section will discuss how certificates are used with tunnel groups.
Once you have created a tunnel group, to associate a certificate to it for IPSec VPNs, you must go into the tunnel group IPSec attributes:
ciscoasa(config)# tunnel-group peer_IP_addr ipsec-attributes
ciscoasa(config-tunnel-ipsec)# peer-id-validate {cert | nocheck | req}
ciscoasa(config-tunnel-ipsec)# pre-shared-key key
ciscoasa(config-tunnel-ipsec)# trust-point trustpoint_name
The peer-ip-validate command specifies the use of certificates. The cert parameter specifies that certificates will be used if both peers have certificates and if during the ISAKMP Phase 1 policy negotiation they agreed that certificates should be used. The nocheck parameter specifies that certificates will not be used (pre-shared keys will be used instead with the pre-shared-key command). The req parameter specifies that certificates must be used with the remote peer, or a tunnel won’t be built. The default setting for this command is req, unless you configure a pre-shared key.
The trust-point command specifies the name of the trustpoint (and the corresponding identity certificate) that should be used with the remote peer. If you only have one CA the appliance is using, then this command isn’t necessary: the appliance will use the single root and identity certificates that it has. However, if you have more than one CA, and thus more than one identity certificate on your appliance, you’ll have to tell the appliance which set of certificates should be used with which remote peer by configuring the trust-point command.
Certificate Group Matching
When your appliance is an Easy VPN server for IPSec VPNs (see Chapter 17) and remote access devices are using certificates for authentication, the appliances assume that the OU (Organizational Unit, sometimes called the Department) field contains the name of the tunnel group the user should be associated with. In turn, this tunnel group name tells the appliance which policies should be associated with the connecting user. If this is incorrect, you’ll need to create certificate matching rules to correctly match up the user to the correct tunnel group.
By default the OU field is used in the certificate to match a user to a tunnel group. Therefore, I highly recommend that when users request their certificates, you make sure they configure their tunnel group name correctly (which is case-sensitive!) in their certificate request—otherwise you’ll either have to have them reperform the request with the correct group name, or create a certificate matching rule to match the certificate to the correct group.
You can override the default lookup method with the tunnel-group-map command:
ciscoasa(config)# tunnel-group-map enable {ou | peer-ip | rules} The ou parameter in the first command specifies that the OU field should be used (this is the default). The peer-ip parameter specifies that the IP address of the peer should be used. And the rules parameter indicates that the rules in the crypto ca certificate map command should be used—this command is discussed next.
The crypto ca certificate map command creates a single certificate matching rule, where you must specify a rule number from 1 to 65535:
ciscoasa(config-ca-cert-map)# subject-name attr ser eq serial_#
ciscoasa(config-ca-cert-map)# subject-name attr cn eq common_name
This command takes you into a subcommand mode where you specify the attributes on the peer identity certificate to match on. You can match on any field within the certificate; however, the two most common ones are the serial number (which is unique within a CA domain) and/or the common name (the name of the user or device). You can match on other fields, but I’ve only listed the two I mentioned earlier; of these two, the most common one to match on is the serial number on the certificate.
The tunnel-group-map command associates the matching rule with the group this user or users should belong to:
ciscoasa(config)# tunnel-group-map map_name rule_# tunnel_group_name
The default-group parameter specifies what group a user should be associated with if it cannot be determined what tunnel group the user should be in. The default group is set to DefaultRAGroup. The second tunnel-group-map command allows you to match a particular certificate matching rule to a particular tunnel group.
Here’s a simple example that places a certificate with a common name of “Richard Deal” in the tunnel group called “engineers”:
ciscoasa(config-ca-cert-map)# subject-name attr cn eq Richard Deal
ciscoasa(config)# tunnel-group-map mymap 1 engineers
