Configuring the Cisco PIX Firewall for CA Site-to-Site

This sample chapter explains how to configure Cisco Secure PIX Firewall certificate authority (CA) support for Internet Protocol Security (IPSec). After presenting an overview of the configuration process, the chapter shows you each major step of the configuration, including support tasks, IKE, and IPSec.

Configure CA Support Tasks

This chapter covers how to configure the PIX Firewall to work with a CA. It does not cover the configuration of the CA server, only how the Cisco products interact with one. The lab provides you with the opportunity to configure components in a way that mimics a real network. This section presents an overview of the major tasks you will have to perform to configure a PIX Firewall for CA support.

The IPSec configuration process can be summarized in five major tasks, outlined as follows. To provide more detail, the general tasks used to configure IPSec encryption on the PIX Firewall are summarized here. Subsequent sections of this chapter discuss the CA configuration tasks and steps in detail. Tasks and steps that are identical to those of preshared keys are not covered in detail. Please refer to Chapter 6, "Configuring the Cisco PIX Firewall for Preshared Keys Site-to-Site," for the detailed explanation of these steps.

• Task 1: Prepare for IPSec—This task consists of several steps to identify CA server details, determine IPSec policies, ensure that the network works, and ensure that the PIX Firewall can support IPSec.

• Task 2: Configure CA support—This task consists of several configuration steps that are required to enable the PIX Firewall to use a CA server.

• Task 3: Configure Internet Key Exchange (IKE) parameters—This task consists of several configuration steps that ensure that IKE can set up secure channels to desired IPSec peers. Then IKE can set up IPSec SAs, enabling IPSec sessions.

• Task 4: Configure IPSec parameters—This task consists of several configuration steps that specify IPSec SA parameters between peers and set global IPSec values.

• Task 5: Test and verify VPN configuration—After you configure IPSec, you need to verify that you have configured it correctly and ensure that it works.

Task 1: Prepare for IPSec

Successful implementation of an IPSec network requires advance preparation before beginning configuration of individual PIX Firewalls. This section outlines how to determine network design details to configure a PIX Firewall for CA support.

You must plan in advance if you want to configure IPSec encryption correctly the first time and minimize misconfiguration. You should begin this task by defining the IPSec security policy based on the overall company security policy. Some planning steps follow:

Step 1	Determine CA server details—This includes variables such as the type of CA server to be used, the IP address, and the CA administrator contact information.
Step 2	Determine IKE (IKE phase one) policy—Determine the IKE policies between peers based on the number and location of IPSec peers.
Step 3	Determine IPSec (IKE phase two) policy—Identify IPSec peer details such as IP addresses and IPSec modes. You then configure crypto maps to gather all IPSec policy details together.
Step 4	Check the current configuration—Use the write terminal, show isakmp [policy], show crypto map, and many other show commands, which are covered later in this chapter in the "Test and Verify VPN Configuration" section.
Step 5	Ensure that the network operates without encryption—Ensure that basic connectivity has been achieved between IPSec peers using the desired IP services before configuring IPSec. You can use the ping command to check basic connectivity.
Step 6	Ensure that access lists are compatible with IPSec—Ensure that perimeter routers and the PIX outside interfaces permit IPSec traffic. Implicitly permit IPSec packets to bypass PIX access lists and conduits. In this step, you will need to enter the sysopt connection permit-ipsec command.

Step 1: Determine CA Server Details

Successful implementation of an IPSec network requires advanced planning before beginning configuration of individual routers. This section outlines how to prepare for IKE and CA support.

Configuring CA is complicated. Having a detailed plan lessens the chances of improper configuration. Some planning steps include the following:

• Determine the type of CA server to use—CA servers come in a multitude of configurations and capabilities. You must determine which one fits your needs before configuration. Requirements include, but are not limited to, Rivest, Shamir, and Adelman (RSA) key type; certificate revocation list (CRL) capabilities; and support for Registration Authority (RA) mode.

• Identify the CA server IP address, host name, and URL—This information is necessary if you will be using Cisco Encryption Technology (CET) and Lightweight Directory Access Protocol (LDAP).

• Identify the CA server administrator contact information—Arrange for your certificates to be validated if the process is not automatic.

The goal of these planning steps is to be ready for CA support configuration.

You need to have a CA available to your network before you configure CA. The CA must support Cisco's Public Key Infrastructure (PKI) protocol and the Simple Certificate Enrollment Protocol (SCEP).

Figure 7-1 shows an example of CA server details that you should gather before beginning the configuration. The diagram and table in Figure 7-1 illustrate the network topology and CA server details used in this chapter.

Figure 7-1 Determine CA Server Details

Step 2: Determine IKE (IKE Phase One) Policy

You should determine the IKE policy details to enable the selected authentication method, then configure that method. Having a detailed plan lessens the chances of improper configuration. Some planning steps include the following:

• Determine the key distribution method—Determine the key distribution method based on the numbers and locations of IPSec peers. For small networks, you might wish to manually distribute keys. For larger networks, you might wish to use a CA server to support scalability of IPSec peers. You must then configure Internet Security Association Key Management Protocol (ISAKMP) to support the selected key distribution method.

• Determine the authentication method—Choose the authentication method based on the key distribution method. The PIX Firewall supports either preshared keys, RSA encrypted nonces, or RSA signatures to authenticate IPSec peers. This chapter focuses on using RSA signatures.

• Identify IPSec peer's IP addresses and host names—Determine the details of all the IPSec peers that will use ISAKMP and RSA signatures for establishing SAs. You will use this information to configure IKE.

• Determine ISAKMP policies for peers—An ISAKMP policy defines a combination, or suite, of security parameters to be used during the ISAKMP negotiation. Each ISAKMP negotiation begins by each peer agreeing on a common (shared) ISAKMP policy. The ISAKMP policy suites must be determined in advance of configuration. You must then configure IKE to support the policy details you determined. Some ISAKMP policy details include the following:

  • Encryption algorithm

  • Hash algorithm

  • IKE SA lifetime

An IKE policy defines a combination of security parameters used during the IKE negotiation. A group of policies makes up a protection suite of multiple policies that enable IPSec peers to establish IKE sessions and establish SAs with minimal configuration.

Creating IKE Policies for a Purpose

IKE negotiations must be protected, so each IKE negotiation begins by each peer agreeing on a common (shared) IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations.

After the two peers agree upon a policy, the security parameters of the policy are identified by an SA established at each peer. These SAs apply to all subsequent IKE traffic during the negotiation.

You can create multiple prioritized policies at each peer to ensure that at least one policy will match a remote peer's policy.

Defining IKE Policy Parameters

You can select specific values for each IKE parameter per the IKE standard. You choose one value over another, based on the security level you desire and the type of IPSec peer to which you will connect. There are five parameters to define in each IKE policy, as outlined in Table 7-1 and Figure 7-2. Table 7-1 shows the default values of each parameter, and Figure 7-2 shows the relative strengths.

Table 7-1 IKE Policy Parameters

Parameter	Accepted Values	Keyword	Default
Message encryption algorithm	DES 3DES	des 3des	DES
Message integrity (hash) algorithm	SHA-1 (HMAC variant) MD5 (HMAC variant)	sha md5	SHA-1
Peer authentication method	Preshared keys RSA signatures	preshare rsa-sig	RSA signatures
Key exchange parameters (Diffie-Hellman group identifier)	768-bit Diffie-Hellman or 1024-bit Diffie-Hellman	1 2	768-bit Diffie-Hellman
ISAKMP-established SA's lifetime	Can specify any number of seconds	_	86,400 seconds (one day)

Figure 7-2 IKE Policy Example

You can select specific values for each ISAKMP parameter using the ISAKMP standard. You choose one value over another based on the security level you desire and the type of IPSec peer to which you will connect. There are five parameters to define in each IKE policy, as presented in Table 7-2. Table 7-2 shows the relative strength of each parameter. You can select specific values for each ISAKMP parameter using the ISAKMP standard.

Table 7-2 ISAKMP Parameters

Parameter	Strong	Stronger
Message encryption algorithm	DES	3DES
Message integrity (hash) algorithm	MD5	SHA-1
Peer authentication method	Preshare	RSA Encryption RSA Signature
Key exchange parameters (Diffie-Hellman group identifier)	D-H Group 1	D-H Group 2
ISAKMP-established SA's lifetime	86,400 seconds	Less than 86,400 seconds

You should determine IKE policy details for each IPSec peer before configuring IKE. Figure 7-2 shows a summary of some IKE policy details that will be configured in examples in this chapter. The authentication method of RSA signatures is used for CA support.

PIX CA Support Overview

The PIX Firewall supports the following open CA standards:

• IKE—A hybrid protocol that implements Oakley and Skeme key exchanges inside the ISAKMP framework. Although IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec SAs.

• Public-Key Cryptography Standard #7 (PKCS #7)—A standard from RSA Security Inc. used to encrypt and sign certificate enrollment messages.

• Public-Key Cryptography Standard #10 (PKCS #10)—A standard syntax from RSA Security Inc. for certificate requests. The PIX Firewall automatically creates the certificate requests as part of the SCEP process.

• RSA keys—RSA is the public key cryptographic system developed by Ronald Rivest, Adi Shamir, and Leonard Adelman. RSA keys come in pairs: one public key and one private key.

• X.509v3 certificates—Certificate support that allows the IPSec-protected network to scale by providing the equivalent of a digital ID card to each device. When two devices wish to communicate, they exchange digital certificates to prove their identity (thus removing the need to manually exchange public keys with each peer or to manually specify a shared key at each peer). These certificates are obtained from a CA. X.509 is part of the X.500 standard.

• CA interoperability—CA interoperability permits CAs to communicate with your PIX Firewall so that it can obtain and use digital certificates from the CA. Although IPSec can be implemented in your network without the use of a CA, using a CA with SCEP provides manageability and scalability for IPSec.

SCEP

The PIX Firewall supports the SCEP to automate the exchange of certificates with a CA server.

The SCEP is an Internet Engineering Task Force (IETF) draft sponsored by Cisco that provides a standard way of managing the certificate lifecycle. This initiative is important for driving open development for certificate handling protocols that can be interoperable with many vendors' devices.

PKCS #7 and #10 are acronyms for the Public-Key Cryptography Standards #7 and #10. These are standards from RSA Security Inc. used to encrypt and sign certificate enrollment messages.

The Manual Enrollment Process

SCEP provides two authentication methods: manual authentication and authentication based on a preshared secret. In the manual mode, the end entity submitting the request is required to wait until the CA operator, using any reliable out-of-band method, can verify its identity. An MD5 fingerprint generated on the PKCS # must be compared out-of-band between the server and the end entity. SCEP clients and CAs (or RAs, if appropriate) must display this fingerprint to a user to enable this verification, if manual mode is used. When using a preshared secret scheme, the server should distribute a shared secret to the end entity that can uniquely associate the enrollment request with the given end entity. The distribution of the secret must be private: only the end entity should know this secret. When creating the enrollment request, the end entity is asked to provide a challenge password. When using the preshared secret scheme, the end entity must type in the redistributed secret as the password. In the manual authentication case, the challenge password is also required because the server might challenge an end entity with the password before any certificate can be revoked. Later on, this challenge password will be included as a PKCS #10 attribute and will be sent to the server as encrypted data. The PKCS #7 envelope protects the privacy of the challenge password with Data Encryption Standard (DES) encryption.

CA Servers Interoperable with PIX Firewall

There several other CA vendors that interoperate with PIX Firewalls, as follows:

• Entrust Technologies, Inc.—Entrust/PKI 4.0

• VeriSign—OnSite 4.5

• Baltimore Technologies—UniCERT v3.05

• Microsoft Corporation—Windows 2000 Certificate Services 5.0

Each of the CA vendors supports the SCEP for enrolling PIX Firewalls. Cisco is using the Cisco Security Associate Program to test new CA and PKI solutions with the Cisco Secure family of products. More information on the Security Associate Program can be found at the following URL:

http://www.cisco.com/warp/public/cc/so/neso/sqso/csap/index.shtml

Entrust Technologies

The Entrust CA server is one of the servers interoperable with Cisco. One of the major differences among CA servers is the question of who administers it.

Entrust is software that is installed and administered by the user. The Cisco IOS interoperates with the Entrust/PKI 4.0 CA server. Entrust/PKI delivers the ability to issue digital IDs to any device or application supporting the X.509 certificate standard, meeting the need for security, flexibility, and low cost by supporting all devices and applications from one PKI. Entrust/PKI offers the following features:

• Requirements—Entrust runs on the Windows NT 4.0 (required for Cisco interoperability), Solaris 2.6, HP-UX 10.20, and AIX 4.3 operating systems. Entrust requires RSA usage keys on the routers. You must use PIX Firewall release 5.1 and later.

• Standards supported—Entrust supports CA services and the RA capability, SCEP, and PKCS #10.

Refer to the Entrust Web site at http://www.entrust.com for more information.

VeriSign OnSite 4.5

The VeriSign OnSite CA server is interoperable with PIX Firewalls. VeriSign administrates the CA, providing the certificates as a service.

VeriSign's OnSite 4.5 solution delivers a fully integrated enterprise PKI to control, issue, and manage IPSec certificates for PIX Firewalls and Cisco routers. VeriSign OnSite is a service administered by VeriSign. VeriSign OnSite offers the following features:

• Requirements—There are no local server requirements. Configure the router for CA mode with a high (greater than 60 second) retry count. You must use PIX Firewall release 5.1 and later.

• Standards supported—It supports SCEP, x509 certificate format, and PKCS #7, #10, #11, #12.

Refer to the VeriSign Web site at http://www.verisign.com for more information.

Baltimore Technologies

Baltimore Technologies has implemented support for SCEP in UniCERT (Baltimore's CA server) as well as the PKI Plus toolkit; these make it easy for customers to enable certificates within their environments.

• Requirements—The current release of the UniCERT CA module is available for Windows NT. You must use PIX Firewall release 5.2 and later.

• Standards supported—The following standards are supported with this CA server: X509 v3, X.9.62, X.9.92, X9.21-2; CRl v2; RFC 2459; PKCS #1, #7, #10, #11, #12; RFC 2510, RFC 2511; SCEP; LDAP v2, LDAP v3; DAP; SQL; TCP/IP; POP3; SMTP; HTTP; OCSP; FIPS 186-1, FIPS 180-1, FIPS 46-3, and FIPS 81 CBC.

Refer to the Baltimore Web site at http://www.baltimore.com for more information.

Microsoft Windows 2000 Certificate Services 5.0

Microsoft has integrated SCEP support into the Windows 2000 CA server through the Security Resource Kit for Windows 2000. This support lets customers use SCEP to obtain certificates and certificate revocation information from Microsoft Certificate Services for all of Cisco's VPN security solutions.

• Requirements—You need a compatible PC capable of running Windows 2000 Server. You must use PIX Firewall release 5.2 and later.

• Standards supported—The following standards are supported with this CA server: X.509 version 3, CRL version 2, PKCS family (PKCS #7, #10, #12), PKIX, SSL version 3, Kerberos v5 RFC 1510, 1964 tokens, SGC, IPSec, PKINIT, PC/SC, and IETF 2459.

See Chapter 3, "Configuring Cisco IOS Routers for Preshared Keys Site-to-Site," for more information about configuring the Microsoft Windows 2000 CA for SCEP support.

Refer to the Microsoft Web site at http://www.microsoft.com for more information.

Enroll a Device with a CA

The typical process for enrolling in a CA follows:

Step 1	Configure the PIX Firewall for CA support.
Step 2	The public and private keys are generated on the PIX Firewall.
Step 3	The PIX Firewall authenticates the CA server.
Step 4	The PIX Firewall sends a certificate request to the CA.
Step 5	The CA signs the certificate.
Step 6	The CA returns the certificate to the PIX Firewall and posts the certificate in the public repository (directory).

Most of these steps have been automated by Cisco and the SCEP protocol that is supported by many CA server vendors. Each vendor determines how long certificates are valid. Contact the relevant vendor to determine how long the certificates will be valid in your particular case.

Task 2: Configure CA Support

Configuring PIX Firewall CA support requires careful attention for successful implementation. Having a detailed plan will lessen the chances of improper configuration. Some planning steps and their associated commands follow:

Step 1	Manage Flash memory usage (optional)—CA certificates, CRLs, and RSA key pairs might use up a significant amount of Flash memory space and might need to be monitored.
Step 2	Configure the PIX Firewall's time and date— The PIX Firewall must have an accurate time and date to enroll with a CA server.
Step 3	Configure the PIX Firewall's host name and domain name—The host name and domain name are required to associate the fully qualified domain name (FQDN) with the keys and certificates used by IPSec.
Step 4	Generate RSA signature key pairs—The RSA signature key pairs are used to sign and encrypt IKE key management messages used to obtain a certificate.
Step 5	Declare a CA—Specify the nickname and IP address of the CA.
Step 6	Configure CA communication parameters—Specify CA, RA, and retry parameters.
Step 7	Authenticate the CA—Obtain the CA's public key and certificate.
Step 8	Request signed certificates—Request signed certificates from your CA for all of your PIX Firewall's RSA key pairs.
Step 9	Save the configuration—Save the configuration to Flash memory.
Step 10	Verify CA support configuration—Verify CA support configuration with various show commands.
Step 11	Monitor and maintain CA interoperability (optional)—Delete certificates and update CRLs.

Step 1: Manage Flash Memory Usage (Optional)

In some cases, storing certificates and CRLs locally will not present a problem. However, in other cases, memory might become an issue—particularly if your CA supports an RA and a large number of CRLs are stored on your PIX Firewall. A PIX Firewall stores the following types of certificates:

• RSA signature key pairs

• Its own certificate

• The CA's certificate

• Two RA certificates (only if the CA supports RA)

The PIX Firewall stores the following numbers of CRLs:

• One, if the CA does not support an RA

• Multiple, if the CA supports an RA

Step 2: Set the PIX Firewall's Date and Time

Ensure that the PIX Firewall's time and date have been accurately set with the show clock command. The clock must be accurately set before generating RSA key pairs and enrolling with the CA server because the keys and certificates are time-sensitive.

To set the PIX Firewall's time and date, use the clock set configuration command. The command syntax is as follows:

clock set hh:mm:ss day month year
clock set hh:mm:ss month day year

hh:mm:ss	Current time in hours (military format), minutes, and seconds
day	The current day of the month, for example, 1
month	The current month expressed as the first three characters of the month, for example, apr for April
year	The current year expressed as four digits, for example, 2001

The following example sets the time to one second before midnight, December 31, 2000:

PIX1(config)# clock set 23:59:59 31 dec 2000

Cisco's PKI protocol uses the clock to make sure that a CRL is not expired. Otherwise, the CA might reject or allow certificates based on an incorrect time stamp.

Step 3: Configure the PIX Firewall's Host Name and Domain Name

You must configure the PIX Firewall's host name and IP domain name if this has not already been done. This is required because the PIX Firewall assigns a FQDN to the keys and certificates used by IPSec, and the FQDN is based on the host name and IP domain name you assign to the PIX Firewall. For example, a certificate is named "pix1.xyz.com" based on a PIX Firewall host name of "pix1" and a PIX Firewall IP domain name of "xyz.com."

To configure the PIX Firewall's host name and IP domain name, there are two commands to use. To configure the PIX Firewall's host name, use the following command:

hostname newname

To configure the PIX Firewall's IP domain name, use the following command:

domain-name name

Step 4: Generate RSA Key Pairs

RSA key pairs are used to sign and encrypt IKE key management messages and are required before you can obtain a certificate for your PIX Firewall.

To generate an RSA key pair, enter the following command in configuration mode:

ca generate rsa {key | specialkey} key_modulus_size

key	This specifies that one general purpose RSA key pair will be generated.
specialkey	This specifies that two special purpose RSA key pairs will be generated instead of one general purpose key.
key_modulus_size	The size of the key modulus, which is between 512 and 2048 bits. Choosing a size greater than 1024 bits might cause key generation to take a few minutes, but it increases key entropy or life.

The ca generate rsa command is not saved in the PIX Firewall configuration. However, the keys generated by this command are saved in the persistent data file in Flash memory, which is never displayed to the user or backed up to another device.

In the following example, one general purpose RSA key pair is to be generated. The selected size of the key modulus is 512.

pixfirewall(config)#ca generate rsa key 512

Step 5: Declare a CA

Declare one CA to be used by your PIX Firewall with the ca identity command in configuration mode. You can also specify the location of the CA server's CGI script and the LDAP IP address, if used. The command syntax is as follows:

ca identity ca_nickname ca_ipaddress [:ca_script_location] [ldap_ip address]

ca_nickname	The CA's name. Enter any string that you desire. (If you previously declared the CA and just want to update its characteristics, specify the name you previously created.) The CA might require a particular name, such as its domain name.
ca_ipaddress	The CA's IP address.
:ca_script_location	The default location and script on the CA server is /cgi-bin/pkiclient.exe. If the CA administrator has not put the CGI script in this location, provide the location and the name of the script in the ca identity command.
ldap_ip address	(Optional) Specify the IP address of the LDAP server. By default, querying a certificate or a CRL is done with Cisco's PKI protocol. If the CA supports LDAP, query functions can also use LDAP.

An example of entering a ca identity command is as follows:

pixfirewall(config)#ca identity labca 172.30.1.51

Step 6: Configure CA Communication Parameters

Configure CA communication parameters with the ca configure command in configuration mode. You can use the command to indicate whether to contact the CA or an RA to obtain a certificate. Use different parameters for each type of supported CA. The command syntax is as follows:

ca configure ca_nickname {ca | ra} retry_period retry_count [crloptional]

ca_nickname	The CA's name. Use the nickname entered with the ca identity command.
ca | ra	Indicates whether to contact the CA or RA when using the ca configure command. Some CA systems provide an RA, which the PIX Firewall contacts instead of the CA.
retry_period	Specifies the number of minutes the PIX Firewall waits before resending a certificate request to the CA when it does not receive a response from the CA to its previous request. Specify from 1 to 60 minutes. By default, the firewall retries every minute.
retry_count	Specifies how many times the PIX Firewall will resend a certificate request when it does not receive a certificate from the CA for the previous request. Specify from 1 to 100. The default is 0, which indicates that there is no limit to the number of times the PIX Firewall should contact the CA to obtain a pending certificate.
crloptional	Allows other peers' certificates to be accepted by your PIX Firewall even if the appropriate CRL is not accessible to your PIX Firewall. The default is without crloptional.

An example of defining VeriSign CA server-related commands is as follows. The IP address of onsiteipsec.verisign.com server is 172.31.1.50.

pixfirewall(config)#ca identity vsec.cisco.com 172.31.1.50
pixfirewall(config)#ca configure vsec.cisco.com ca 1 20 crloptional

Note that the CA mode is specified.

An example of defining a Baltimore or an Entrust CA server is as follows. The IP address of the CA server is 172.30.1.51.

pixfirewall(config)#ca identity labca 172.30.1.51 172.30.1.51
pixfirewall(config)#ca configure labca ra 1 20 crloptional

The second IP address is for an LDAP query server running on the same host. Note that the RA mode is specified.

An example of defining a Microsoft Windows 2000 CA is as follows:

pixfirewall(config)#ca identity labca 172.30.1.51:/certsrv/mscep/mscep.dll
pixfirewall(config)#ca configure labca ra 1 20 crloptional

Step 7: Authenticate the CA

Authenticate the CA to verify that it is legitimate by obtaining its public key and its certificate with the ca authenticate command in configuration mode. After entering the command, manually authenticate the CA's public key by contacting the CA administrator to compare the CA certificate's fingerprint. An RA, if used (as in the Entrust CA), acts as a proxy for a CA. The command syntax is as follows:

ca authenticate ca_nickname [fingerprint]

ca_nickname

The CA's name. Use the nickname entered with the ca identity command.

fingerprint

A key consisting of alphanumeric characters the PIX Firewall uses to authenticate the CA's certificate. The fingerprint is optional and is used to authenticate the CA's public key within its certificate. The PIX Firewall discards the CA certificate if the fingerprint that you included in the command statement is not equal to the fingerprint within the CA's certificate. Depending on the CA you are using, you might need to ask your local CA administrator for this fingerprint. You also have the option to authenticate the public key manually by comparing the two fingerprints after you receive the CA's certificate, rather than entering it within the command statement.

An example of authenticating a CA is as follows:

pixfirewall(config)#ca authenticate labca

The certificate has the following attributes:

Fingerprint: 93700c31 4853ec4a ded81400 43d3c82c

Step 8: Request Signed Certificates

Request signed certificates from your CA for all your PIX Firewall's RSA key pairs using the ca enroll command. Before entering this command, have your CA administrator authenticate your PIX Firewall manually before granting its certificates. The command syntax is as follows:

ca enroll ca_nickname challenge_password [serial] [ipaddress]

ca_nickname	The CA's name. Use the nickname entered with the ca identity command.
challenge_password	A required password that gives the CA administrator some authentication when a user calls to ask for a certificate to be revoked. It can be up to 80 characters in length.
serial	Specifies the PIX Firewall's serial number (optional).
ipaddress	The PIX Firewall's IP address (optional).

The ca enroll command requests certificates from the CA for all your PIX Firewall's RSA key pairs. This task is also known as enrolling with the CA.

During the enrollment process, you are prompted for a challenge password that can be used by the CA administrator to validate your identity. Do not forget the password you use. (Technically, enrolling and obtaining certificates are two separate events, but they both occur when the ca enroll command is issued.)

Your PIX Firewall needs a signed certificate from the CA for each of your PIX Firewall's RSA key pairs. If you already have a certificate for your keys, you will not be able to complete this command; instead, you will be prompted to remove the existing certificate first.

If you want to cancel the current enrollment request, use the no ca enroll command.

An example of authenticating a CA is as follows:

pixfirewall(config)#ca enroll labca mypassword1234567

The argument mypassword1234567 in the example is a password, which is not saved with the configuration.

The ca enroll command requests as many certificates as there are RSA key pairs. You need to perform this command only once, even if you have special usage RSA key pairs.

Step 9: Save the Configuration

Save your configuration with the ca save all and write memory commands.

• The ca save all command allows you to save the PIX Firewall's RSA key pairs; the CA, the RA, and the PIX Firewall's certificates; and the CA's CRLs in the persistent data file in Flash memory between reloads. The no ca save command removes the saved data from PIX Firewall's Flash memory. The ca save command itself is not saved with the PIX Firewall configuration between reloads.

• The write memory command stores current CA configuration in Flash memory.

Step 10: Verify CA Support Configuration

Use the show ca identity command to view the current CA identity settings stored in RAM.

Use the show ca configure command to view CA communication parameter settings.

Use the show ca certificate command to verify that the enrollment process was successful and to view PIX Firewall, CA, and RA certificates.

Use the show ca mypubkey rsa command to view your RSA key pairs. Example 7-1 displays sample output from the show ca mypubkey rsa command.

Example 7-1 show ca mypubkey rsa Command Output

% Key pair was generated at: 15:34:55 Jan 01 2000

Key name: labca.cisco.com

Usage: General Purpose Key

Key Data:

305c300d 06092a86 4886f70d 01010105 00034b00 30480241 00c31f4a ad32f60d

6e7ed9a2 32883ca9 319a4b30 e7470888 87732e83 c909fb17 fb5cae70 3de738cf

6e2fd12c 5b3ffa98 8c5adc59 1ec84d78 90bdb53f 2218cfe7 3f020301 0001.

Step 11: Monitor and Maintain CA Support

The following steps are optional, depending on your particular requirements:

• Request a CRL

• Delete PIX Firewall's RSA keys and certificates

• Delete CA data from Flash memory

Request a CRL

Request a CRL at any time with the ca crl request command. The PIX Firewall automatically requests a CRL from the CA at various times, depending on whether the CA is in the RA mode or not. If the CA is not in the RA mode, a CRL is requested whenever the system reboots and finds that it does not already contain a valid (unexpired) CRL. If the CA is in the RA mode, no CRL can be obtained until a peer's certificate is sent by an IKE exchange. When a CRL expires, the PIX Firewall automatically requests an updated one. Until a new valid CRL is obtained, the PIX Firewall will not accept peers' certificates.

Delete PIX Firewall's RSA Keys and Certificates

Delete all your PIX Firewall's RSA keys with the ca zeroize rsa command. The command deletes all RSA keys that were previously generated by your PIX Firewall. If you issue this command, you must also perform two additional tasks. Perform these tasks in the following order:

Use the no ca identity command to manually remove the PIX Firewall's certificates from the configuration. This deletes all the certificates issued by the CA.

Ask the CA administrator to revoke your PIX Firewall's certificates at the CA. Supply the challenge password you created when you originally obtained the PIX Firewall's certificates using the crypto ca enroll command.

Delete CA Data from Flash Memory

The no ca save command removes the PIX Firewall's RSA key pairs; the CA, the RA, and the PIX Firewall's certificates; and the CA's CRLs from the persistent data file in Flash memory.

Example of a CA Server Configuration

Example 7-2 shows a sample of CA commands for an Entrust CA server.

Example 7-2 CA Commands for an Entrust CA Server

pix1# write terminal

!

hostname Pix1

domain-name labca.cisco.com

!

ca identity labca 172.30.1.51:cgi-bin/pkiclient.exe 172.30.1.51

ca configure labca ra 1 100 crloptional

Task 3: Configure IKE

Configuring IKE consists of three essential steps.

Step 1	Enable or disable IKE—Enable or disable IKE (ISAKMP) negotiation for authentication and key exchange. Set the ISAKMP identity.
Step 2	Create IKE policies—Define a suite of IKE policies to establish ISAKMP peering between two IPSec endpoints.
Step 3	Verify IKE configuration—The write terminal and show isakmp policy commands display configured policies.

Step 2: Create IKE Policies

The next major step in configuring the Pix Firewall ISAKMP support is to define a suite of ISAKMP policies. The goal of defining a suite of IKE policies is to establish ISAKMP peering between two IPSec endpoints. Use the IKE policy details gathered during the planning task. Configure an IKE phase one policy with the isakmp policy command to match expected IPSec peers:

Step 1	Identify the policy with a unique priority number.
	pixfirewall(config)# isakmp policy priority
Step 2	Specify the encryption algorithm. The default is des.
	pixfirewall(config)# isakmp policy priority encryption {des | 3des}
Step 3	Specify the hash algorithm. The default is sha.
	pixfirewall(config)# isakmp policy priority hash {md5 | sha}
Step 4	Specify the authentication method.
	pixfirewall(config)# isakmp policy priority authentication {pre-share | rsa-sig}

Step 5	Specify the Diffie-Hellman group identifier. The default is group 1.
	pixfirewall(config)# isakmp policy priority group {1 | 2}
Step 6	Specify the IKE SA's lifetime. The default is 86400.
	pixfirewall(config)# isakmp policy priority lifetime seconds

When configuring ISAKMP (IKE) for certificate-based authentication, it is important to match the IKE identity type with the certificate type. The ca enroll command used to acquire certificates will, by default, get a certificate with the identity based on host name. The default identity type for the isakmp identity command is based on the address instead of the host name. You can reconcile this disparity of identity types by using the isakmp identity hostname command when configuring CA support.

If you are using RSA signatures as your authentication method in your IKE policies, Cisco recommends you set each participating peer's identity to the host name. Otherwise, the ISAKMP security association to be established during phase one of IKE might fail.

Use the no isakmp identity hostname command to reset the IKE identity to the default value of IP address.

Task 4: Configure IPSec

The next major task in configuring PIX Firewall IPSec is to configure IPSec parameters that you previously determined. This section presents the steps used to configure IPSec parameters for IKE RSA signatures.

The general tasks and commands used to configure IPSec encryption on the PIX Firewall are summarized as follows. Along with this chapter, they are covered in detail in Chapter 6.

Step 1	Configure crypto access lists with the access-list command.
Step 2	Configure transform set suites with the crypto ipsec transform-set command.
Step 3	Configure crypto maps with the crypto map command.
Step 4	Configure global IPSec SA lifetimes with the crypto ipsec security-association lifetime command.
Step 5	Apply crypto maps to the terminating/originating interface with the crypto map map-name interface command.
Step 6	Verify IPSec configuration using the variety of available show commands.

Task 5: Test and Verify VPN Configuration

The last major task in configuring PIX Firewall IPSec is to test and verify the IKE and IPSec configuration accomplished in the previous tasks. This section summarizes the methods and commands used to test and verify the VPN configuration including CA, IKE, and IPSec configuration.

Test and verify CA configuration with the commands in Table 7-3.

Table 7-3 Commands to Test and Verify CA Configuration

Command	Description
show ca identity	Displays the CA your PIX Firewall uses
show ca configure	Displays the parameters for communication between the PIX Firewall and the CA
show ca mypubkey rsa	Displays the PIX Firewall's public RSA keys
show ca certificate	Displays the current status of requested certificates and relevant information of received certificates, such as CA and RA certificates

Debug CA messages with the debug crypto ca command. This command displays communications between the PIX Firewall and the CA server.

Delete RSA keys and CA certificates with the commands in Table 7-4.

Table 7-4 Commands to Delete RSA Keys and CA Certificates

Command	Description
ca zeroize rsa	Deletes all RSA keys that were previously generated by your PIX Firewall. If you issue this command, you must also enter the no ca identity command to delete CA certificates and ask the CA administrator to revoke your PIX Firewall's certificates at the CA.
no ca identity	Manually removes the PIX Firewall's certificates from the configuration; this command deletes all the certificates issued by the CA.

Test and Verify IKE Configuration

Test and verify IKE configuration on the PIX Firewall with the commands in Table 7-5.

Table 7-5 Commands to Test and Verify IKE Configuration

Command	Description
show access-list	Lists the access-list command statements in the configuration. Used to verify general access lists to permit IPSec traffic.
show isakmp	Displays configured ISAKMP policies in a format similar to a write terminal command.
show isakmp policy	Displays default and any configured ISAKMP policies.

Test and Verify IPSec Configuration

Test and verify IPSec configuration on the PIX Firewall with the commands in Table 7-6.

Table 7-6 Commands to Test and Verify IPSec Configuration

Command	Description
show access-list	Lists the access-list command statements in the configuration. Used to verify that the crypto access lists select interesting traffic. Displays number of packets that matched the access list.
show crypto map	Displays the configured crypto map parameters.
show crypto ipsec transform-set	Displays the configured IPSec transform sets.
show crypto ipsec security-association lifetime	Displays the correct global IPSec SA lifetime values.

Monitor and Manage IKE and IPSec Communications

Monitor and manage IKE and IPSec communications between the PIX Firewall and IPSec peers with the commands in Table 7-7.

Table 7-7 Commands to Monitor and Manage IKE and IPSec Communications

Command	Description
show isakmp sa	Displays the current status of ISAKMP SAs
show crypto ipsec sa	Displays the current status of IPSec SAs—useful for ensuring traffic is being encrypted
clear crypto isakmp sa	Clears ISAKMP SAs
clear crypto ipsec sa	Clears IPSec SAs
debug crypto isakmp	Displays ISAKMP (IKE) communications between the PIX Firewall and IPSec peers
debug crypto ipsec	Displays IPSec communications between the PIX Firewall and IPSec peers

Summary

This chapter provided detailed information on how to configure a Cisco Secure PIX Firewall to use a CA for IPSec VPNs. It started by looking at the tasks involved in configuring CA support for IPSec encryption. Many of these tasks were the same as in Chapter 6, which covers preshared key support for Cisco PIX-based VPNs. This chapter also provided an overview of CAs and their related technologies. Following this overview, the chapter looked at the configuration steps involved in configuring CA support for a Cisco IOS router. After the CA was configured, the chapter continued with the rest of the IPSec configuration tasks until the VPN was established.

Now that you have configured both preshared keys and CA support on Cisco PIX Firewalls, Chapter 8, "Troubleshooting Cisco PIX Firewall VPNs," looks at the troubleshooting tools that are available for Cisco PIX-based IPSec VPNs.

Review Questions