Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 3.2 - Configuring Certificates [Cisco Services Modules]

Table Of Contents

Configuring Certificates

Public Key Cryptography

About Public Key Cryptography

Certificate Scalability

About Key Pairs

About Trustpoints

About Revocation Checking

Certificate Configuration

Preparing for Certificates

Generating Key Pairs

Removing Key Pairs

Establishing AAA Authentication

Verifying Configurations for Specified Settings

Exporting and Importing Keypairs and Certificates

Exporting a Keypair and Certificate

Importing a Keypair and Certificate

Linking Certificates to a Trustpoint

Configuration Example: Cut-Through-Proxy Authentication

Configuring Certificates

This chapter describes how to configure certificates. CAs are responsible for managing certificate requests and issuing digital certificates. A digital certificate includes information that identifies a user or device, such as a name, serial number, company, department, or IP address. A digital certificate also includes a copy of the public key for the user or device. A CA can be a trusted third party, such as VeriSign, or a private (in-house) CA that you establish within your organization.

This chapter includes the following sections:

•Public Key Cryptography

•Certificate Configuration

Public Key Cryptography

This section includes the following topics:

•About Public Key Cryptography

•Certificate Scalability

•About Key Pairs

•About Trustpoints

•About Revocation Checking

About Public Key Cryptography

Digital signatures, enabled by public key cryptography, provide a means to authenticate devices and users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other.

In simple terms, a signature is formed when data is encrypted with a private key. The signature is attached to the data and sent to the receiver. The receiver applies the public key of the sender to the data. If the signature sent with the data matches the result of applying the public key to the data, the validity of the message is established.

This process relies on the receiver having a copy of the public key of the sender and a high degree of certainty that this key belongs to the sender, not to someone pretending to be the sender.

Obtaining the public key of a sender is normally handled out-of-band or through an operation performed at installation. For example, most web browsers are configured with the root certificates of several CAs by default. For VPN, the IKE protocol, a component of IPSec, can use digital signatures to authenticate peer devices before setting up security associations.

Certificate Scalability

Without digital certificates, you must manually configure each IPSec peer for every peer with which it communicates, and every new peer you add to a network would then require a configuration change on every peer with which you need it to communicate securely.

When you use digital certificates, each peer is enrolled with a CA. When two peers try to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new peer is added to the network, you enroll that peer with a CA and no other peers need modification. When the new peer tries an IPSec connection, certificates are automatically exchanged and the peer can be authenticated.

With a CA, a peer authenticates itself to the remote peer by sending a certificate to the remote peer and performing some public key cryptography. Each peer sends its unique certificate that was issued by the CA. This process works because each certificate encapsulates the public key for the associated peer, each certificate is authenticated by the CA, and all participating peers recognize the CA as an authenticating authority. This is called IKE with an RSA signature.

The peer can continue sending its certificate for multiple IPSec sessions, and to multiple IPSec peers, until the certificate expires. When its certificate expires, the peer administrator must obtain a new one from the CA.

CAs can also revoke certificates for peers that no longer participate in IPSec. Revoked certificates are not recognized as valid by other peers. Revoked certificates are listed in a CRL, which each peer may check before accepting a certificate from another peer.

Some CAs have an RA as part of their implementation. An RA is a server that acts as a proxy for the CA so that CA functions can continue when the CA is unavailable.

About Key Pairs

Key pairs are RSA keys, which can be used for SSH or SSL connections, have the following characteristics:

•For the purposes of generating keys, the maximum key modulus for RSA keys is 2048 bits. The default size is 1024 bits. Many SSL connections using identity certificates with RSA key pairs that exceed 1024 bits can cause a high CPU usage on the FWSM and rejected clientless logins.

•For signature operations, the supported maximum key size is 4096 bits.

•You can generate a general-purpose RSA key pair, used for both signing and encryption, or you can generate separate RSA key pairs for each purpose.

Separate signing and encryption keys help reduce exposure of the keys. This is because SSL uses a key for encryption but not signing, while IKE uses a key for signing but not encryption.

About Trustpoints

Trustpoints let you manage and track CAs and certificates. A trustpoint is a representation of a CA or identity pair. A trustpoint contains the identity of the CA, CA-specific configuration parameters, and an association with one enrolled identity certificate.

After you have defined a trustpoint, you can reference it by name in commands requiring that you specify a CA. You can configure many trustpoints.

Note If an FWSM has multiple trustpoints that share the same CA, only one of these trustpoints sharing the CA can be used to validate user certificates. To control which trustpoint sharing a CA is used for validation of user certificates issued by that CA, enter the support-user-cert-validation command.

You can export and import the keypair and issued certificates associated with a trustpoint in PKCS12 format, which is useful if you want to manually duplicate a trustpoint configuration on a different FWSM.

About Revocation Checking

When a certificate is issued, it is valid for a fixed period of time. Sometimes a CA revokes a certificate before this time period expires; for example, because of security concerns or a change of name or association. CAs periodically issue a signed list of revoked certificates. Enabling revocation checking forces the FWSM to check that the CA has not revoked a certificate every time it uses that certificate for authentication.

When you enable revocation checking during the PKI certificate validation process, the FWSM checks certificate revocation status using either CRL checking, OCSP, or both, with the second method you set in effect only when the first method returns an error (for example, if the server is unavailable).

With CRL checking, the FWSM retrieves, parses, and caches CRLs, which provide a complete list of revoked certificates. OCSP offers a more scalable method of checking revocation status because it localizes certificate status on a Validation Authority, which it queries for the status of a specific certificate.

Certificate Configuration

This section describes how to configure the FWSM with certificates and other procedures related to certificate use and management, and includes the following topics:

•Preparing for Certificates

•Generating Key Pairs

•Removing Key Pairs

•Establishing AAA Authentication

•Verifying Configurations for Specified Settings

•Exporting and Importing Keypairs and Certificates

•Linking Certificates to a Trustpoint

•Configuration Example: Cut-Through-Proxy Authentication

Preparing for Certificates

Before you configure a FWSM with certificates, be sure that the FWSM is correctly configured to support certificates. An incorrectly configured FWSM can cause enrollment to fail or create a certificate that includes inaccurate information.

To prepare the FWSM for certificates, perform the following steps:

Step 1 Be sure that the hostname and domain name of the FWSM are configured correctly. To view the hostname and domain name as currently configured, enter the following command:
hostname(config)# show running-config 
For information about configuring the hostname, see the "Setting the Hostname" section on page 8-2.

For information about configuring the domain name, see the "Setting the Domain Name" section on page 8-3.

Step 2 Be sure that the FWSM clock is set accurately before configuring the CA. Certificates have a date and time on which they become valid and then expire. When the FWSM enrolls with a CA and obtains a certificate, the FWSM checks that the current time is within the valid range for the certificate. If the time is outside that range, enrollment fails.

For information about setting the clock, see the "Setting the Date and Time" section on page 8-3.

Generating Key Pairs

Key pairs are RSA keys, as discussed in the "About Key Pairs" section. You must generate key pairs for the types of certification that you want to use.

To generate key pairs, perform the following steps:

Step 1 Generate the types of key pairs needed for your PKI implementation. To do so, perform the following steps, as applicable:

a. To generate RSA key pairs, enter the following command.
hostname/contexta(config)# crypto key generate rsa
If you do not use additional keywords, executing this command generates one, general-purpose RSA key pair. Because the key modulus is not specified, the default key modulus of 1024 bits is used. You can specify other modulus sizes with the modulus keyword.

Note Many SSL connections using identity certificates with RSA key pairs that exceed 1024 bits can cause high CPU usage on the FWSM and rejected clientless logins.

You can also assign a label to each key pair using the label keyword. The label is referenced by the trustpoint that uses the key pair. If you do not assign a label, the key pair is automatically labeled Default-RSA-Key.

b. To assign a label to each key pair, enter the following command:
hostname/contexta (config)# crypto key generate rsa label key-pair-label
Step 2 (Optional) To view key pair(s), enter the following command:
hostname/contexta(config)# show crypto key mypubkey
The following is sample output from the show crypto key mypubkey command:
Key pair was generated at: 16:39:47 central Feb 10 2009
Key name: <Default-RSA-Key>
 Usage: General Purpose Key
 Modulus Size (bits): 1024
 Key Data:
  30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00ea51b7 
  0781848f 78bccac2 4a1b5b8d 2f3e30b4 4cae9f86 f4485207 159108c9 f5e49103 
  9eeb0f5d 45fd1811 3b4aafce 292b3b64 b4124a6f 7a777b08 75b88df1 8092a9f8 
  5508e9e5 2c271245 7fd1c0c3 3aaf1e04 c7c4efa4 600f4c4a 6afe56ad c1d2c01c 
  e08407dd 45d9e36e 8cc0bfef 14f9e6ac eca141e4 276d7358 f7f50d13 79020301 0001
Key pair was generated at: 16:34:54 central Feb 10 2005
Step 3 Save the key pair that you have generated. To do so, save the running configuration by entering the following command:
hostname(config)# write memory
Removing Key Pairs

To remove key pairs, enter the following command:
hostname(config)# crypto key zeroize rsa
The following is sample output from the crypto key zeroize rsa command:
WARNING: All RSA keys will be removed.
WARNING: All device certs issued using these keys will also be removed.
Do you really want to remove these keys? [yes/no] y
Establishing AAA Authentication

To establish AAA authentication for traffic on which you want to perform cut-through-proxy authentication, perform the following steps:

Step 1 Enter either one of the following commands:
hostname (config)# aaa authentication match
hostname (config)# aaa authentication include
For the aaa authentication match command, you can use TACACS+ or RADIUS user accounting, or the local IP address of the host or network of hosts that you want to be authenticated or authorized on a server designated by the aaa-server command.

For the aaa authentication include command, you can use only TACACS+ or RADIUS user accounting to be authenticated or authorized on a server designated by the aaa-server command.

Step 2 To configure secure authentication to the HTTP client, enter the following command:
hostname (config)# aaa authentication secure-http-client
For more information about command usage, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference.

Verifying Configurations for Specified Settings

Before you import third-party certificates, you must have configured certain AAA settings, the AAA server, access lists, and optionally, virtual HTTP. To verify configurations for specified settings, perform the following steps:

Step 1 To verify that the required access lists have been configured, enter the following command:
hostname(config)# show run access-list
The following is sample output from the show run access-list command that displays the configured access-list:
access-list temp extended permit ip any any
Step 2 To verify that the AAA server has been configured, enter the following command:
hostname(config)# show run aaa-server
The following is sample output from the show run aaa-server command that displays the configured AAA server:
aaa-server new protocol tacacs+
aaa-server new (outside) host 10.77.152.80
key cisco
Step 3 To verify that the AAA settings have been configured, enter the following command:
hostname(config)# show run aaa
The following is sample output from the show run aaa command that displays the configured AAA settings:
aaa authentication match temp outside new
aaa authentication secure-http-client
Step 4 (Optional) To display the imported certificate name and its associated IP address, enter the following command:
hostname(config)# show run name
The following is sample output from the show run name command that displays the imported certificate name and its associated IP address:
name 10.77.152.104 atl-lx-sbacchus.cisco.com
Step 5 (Optional) To display the virtual IP address, enter the following command:
hostname(config)# show running-config virtual
The following is sample output from the show running-config virtual command, which displays the name of the imported certificate that has been mapped to the virtual IP address:
virtual http atl-lx-sbacchus.cisco.com
Exporting and Importing Keypairs and Certificates

You can export and import keypairs and issued certificates associated with a trustpoint configuration. The FWSM supports the PKCS12 format for exporting and importing trustpoints.

This section includes the following topics:

•Exporting a Keypair and Certificate

•Importing a Keypair and Certificate

Exporting a Keypair and Certificate

To export keypairs and certificates associated with a trustpoint configuration in PKCS12 format, enter the following command:
hostname (config)# crypto ca export pkcs12
You can copy the data. The trustpoint data is password protected; however, if you save the trustpoint data in a file, be sure that the file is in a secure location.

For example, to manually export PKCS12 data for a trustpoint called newton using cisco123 as the passphrase, enter the following command:
hostname (config)# crypto ca export newton pkcs12 cisco123
Exported pkcs12 follows:
[ PKCS12 data omitted ]
---End - This line not part of the pkcs12---
Importing a Keypair and Certificate

To import keypairs and issued certificates associated with a trustpoint configuration in PKCS12 format, perform the following steps:

Step 1 Enter the following command:
hostname (config)# crypto ca import pkcs12
The key pair imported with the trustpoint configuration is assigned a label that matches the name of the trustpoint that you create. For example, if an exported trustpoint used an RSA key labeled Default-RSA-Key, creating a trustpoint called Main by importing the PKCS12 format creates a key pair called Main.

Note If an FWSM has trustpoints that share the same CA, only one of the trustpoints sharing the CA can be used to validate user certificates. Entering the crypto ca import pkcs12 command can create this condition. To control which trustpoint sharing a CA is used for validation of user certificates issued by that CA, enter the support-user-cert-validation command.

For example, to manually import PKCS12 data to the trustpoint called newton with the passphrase cisco123, enter the following command:
hostname (config)# crypto ca import newton pkcs12 cisco123
Enter the base 64 encoded pkcs12.
End with a blank line or the word "quit" on a line by itself:
[ PKCS12 data omitted ]
quit
INFO: Import PKCS12 operation completed successfully
Step 2 To display an imported certificate and verify that it has been imported correctly, enter the following command:
hostname (config)# show crypto ca certificates
The following is sample output from the show crypto ca certificates command, which lists the name of the trustpoint, newton:
CA Certificate
  Status: Available
  Certificate Serial Number: 18dad19e267de8bb4a2158cdcc6b3b4a
  Certificate Usage: General Purpose
  Public Key Type: RSA (2048 bits)
  Issuer Name: 
    cn=VeriSign Class 3 Public Primary Certification Authority - G5
    ou=(c) 2006 VeriSign\, Inc. - For authorized use only
    ou=VeriSign Trust Network
    o=VeriSign\, Inc.
    c=US
  Subject Name: 
    cn=VeriSign Class 3 Public Primary Certification Authority - G5
    ou=(c) 2006 VeriSign\, Inc. - For authorized use only
    ou=VeriSign Trust Network
    o=VeriSign\, Inc.
    c=US
  Validity Date: 
    start date: 23:00:00 IST Nov 7 2006
    end   date: 22:59:59 IST Jul 16 2036
  Associated Trustpoints: newton-1 
Certificate
  Status: Available
  Certificate Serial Number: 5b178bf40eda86f320c4302cb055a743
  Certificate Usage: General Purpose
  Public Key Type: RSA (1024 bits)
  Issuer Name: 
    cn=VeriSign Class 3 Extended Validation SSL CA
    ou=Terms of use at https://www.verisign.com/rpa (c)06
    ou=VeriSign Trust Network
    o=VeriSign\, Inc.
    c=US
  Subject Name:
    cn=atl-lx-sbacchus.cisco.com
    o=Cisco Systems\, Inc
    sa=170 West Tasman Dr
    l=San Jose
    st=California
    pc=95134
    c=US
    serialNumber=C1183477
    2.5.4.15=#131256312e302c20436c6175736520352e286229
    1.3.6.1.4.1.311.60.2.1.2=#130a43616c69666f726e6961
    1.3.6.1.4.1.311.60.2.1.3=#13025553
  CRL Distribution Points: 
    [1]  http://EVSecure-crl.verisign.com/EVSecure2006.crl
  Validity Date: 
    start date: 23:00:00 IST Sep 26 2007
    end   date: 22:59:59 IST Sep 26 2008
  Associated Trustpoints: newton 
CA Certificate
  Status: Available
  Certificate Serial Number: 5b7759c61784e15ec727c0329529286b
  Certificate Usage: General Purpose
  Public Key Type: RSA (2048 bits)
  Issuer Name: 
    cn=VeriSign Class 3 Public Primary Certification Authority - G5
    ou=(c) 2006 VeriSign\, Inc. - For authorized use only
    ou=VeriSign Trust Network
    o=VeriSign\, Inc.
    c=US
  Subject Name: 
    cn=VeriSign Class 3 Extended Validation SSL CA
    ou=Terms of use at https://www.verisign.com/rpa (c)06
    ou=VeriSign Trust Network
    o=VeriSign\, Inc.
    c=US
  CRL Distribution Points: 
    [1]  http://EVSecure-crl.verisign.com/pca3-g5.crl
  Validity Date: 
    start date: 23:00:00 IST Nov 7 2006
    end   date: 22:59:59 IST Nov 7 2016
  Associated Trustpoints: newton 
Linking Certificates to a Trustpoint

After you have imported the third-party certificate. you must link it to the trustpoint, which allows you to communicate with multiple clients.

To display the name of the trustpoint, which has the same name (newton) as was used during import of the third-party certificate, enter the following command:
hostname (config)# show run ssl
ssl trust-point newton
Configuration Example: Cut-Through-Proxy Authentication

To configure an FWSM for cut-through-proxy authentication, enter the following commands:
hostname(config)# access-list FWACL extended permit tcp any any eq ftp
access-list FWACL extended permit tcp any any eq telnet
access-list FWACL extended permit tcp any any eq www
access-list FWACL extended permit tcp any any eq https
access-group FWACL in interface outside
timeout uauth 0:05:00 absolute
aaa-server TacacsServers protocol tacacs+
reactivation-mode depletion deadtime 2
aaa-server TacacsServers host 100.136.0.3
timeout 22
key secretpassword
aaa authentication match FWACL outside TacacsServers
aaa accounting match FWACL outside TacacsServers
aaa authentication secure-http-client
auth-prompt prompt (JCPIX249) Login:
auth-prompt accept (JCPIX249) Login Accepted!
auth-prompt reject (JCPIX249) Login Rejected!
The access-list series of commands defines which protocols are allowed through the FWSM. Only those shown in the example and SSH are supported for cut-through-proxy authentication.

The timeout uauth command allows the FWSM to re-request authorization for all those protocols in five minutes.

The aaa authentication command is cut-through-proxy authentication. Executing this command matches the protocols in the access list, and intercepts and prompts users for authentication.

The auth-prompt series of commands changes the prompt that users see, so you know that the FWSM is making the request.

	Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 3.2
	Configuring Certificates
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 3.2 About This Guide Quick Start Steps Introduction to the Firewall Services Module Configuring the Switch for the Firewall Services Module Getting Started Managing Security Contexts Configuring the Firewall Mode Configuring Interface Parameters Configuring Basic Settings Configuring IP Routing and DHCP Services Configuring IPv6 Identifying Traffic with Access Lists Permitting and Denying Network Access Configuring NAT Configuring Failover Configuring AAA Servers and the Local Database Configuring Certificates Applying AAA for Network Access Applying Filtering Services Configuring ARP Inspection and Bridging Parameters Using Modular Policy Framework Configuring Advanced Connection Features Applying Application Layer Protocol Inspection Configuring Management Access Managing Software, Licenses, and Configurations Monitoring the Firewall Services Module Troubleshooting the Firewall Services Module Specifications Sample Configurations Using the Command-Line Interface Mapping MIBs to CLI Commands Addresses, Protocols, and Ports Open Source License Acknowledgments Glossary Index	Download this chapter Configuring Certificates Download the complete book Book-Level PDF: Firewall Services Module Configuration Guide, 3.2 (PDF - 15 MB) Table Of Contents Configuring Certificates Public Key Cryptography About Public Key Cryptography Certificate Scalability About Key Pairs About Trustpoints About Revocation Checking Certificate Configuration Preparing for Certificates Generating Key Pairs Removing Key Pairs Establishing AAA Authentication Verifying Configurations for Specified Settings Exporting and Importing Keypairs and Certificates Exporting a Keypair and Certificate Importing a Keypair and Certificate Linking Certificates to a Trustpoint Configuration Example: Cut-Through-Proxy Authentication Configuring Certificates This chapter describes how to configure certificates. CAs are responsible for managing certificate requests and issuing digital certificates. A digital certificate includes information that identifies a user or device, such as a name, serial number, company, department, or IP address. A digital certificate also includes a copy of the public key for the user or device. A CA can be a trusted third party, such as VeriSign, or a private (in-house) CA that you establish within your organization. This chapter includes the following sections: •Public Key Cryptography •Certificate Configuration Public Key Cryptography This section includes the following topics: •About Public Key Cryptography •Certificate Scalability •About Key Pairs •About Trustpoints •About Revocation Checking About Public Key Cryptography Digital signatures, enabled by public key cryptography, provide a means to authenticate devices and users. In public key cryptography, such as the RSA encryption system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other. In simple terms, a signature is formed when data is encrypted with a private key. The signature is attached to the data and sent to the receiver. The receiver applies the public key of the sender to the data. If the signature sent with the data matches the result of applying the public key to the data, the validity of the message is established. This process relies on the receiver having a copy of the public key of the sender and a high degree of certainty that this key belongs to the sender, not to someone pretending to be the sender. Obtaining the public key of a sender is normally handled out-of-band or through an operation performed at installation. For example, most web browsers are configured with the root certificates of several CAs by default. For VPN, the IKE protocol, a component of IPSec, can use digital signatures to authenticate peer devices before setting up security associations. Certificate Scalability Without digital certificates, you must manually configure each IPSec peer for every peer with which it communicates, and every new peer you add to a network would then require a configuration change on every peer with which you need it to communicate securely. When you use digital certificates, each peer is enrolled with a CA. When two peers try to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new peer is added to the network, you enroll that peer with a CA and no other peers need modification. When the new peer tries an IPSec connection, certificates are automatically exchanged and the peer can be authenticated. With a CA, a peer authenticates itself to the remote peer by sending a certificate to the remote peer and performing some public key cryptography. Each peer sends its unique certificate that was issued by the CA. This process works because each certificate encapsulates the public key for the associated peer, each certificate is authenticated by the CA, and all participating peers recognize the CA as an authenticating authority. This is called IKE with an RSA signature. The peer can continue sending its certificate for multiple IPSec sessions, and to multiple IPSec peers, until the certificate expires. When its certificate expires, the peer administrator must obtain a new one from the CA. CAs can also revoke certificates for peers that no longer participate in IPSec. Revoked certificates are not recognized as valid by other peers. Revoked certificates are listed in a CRL, which each peer may check before accepting a certificate from another peer. Some CAs have an RA as part of their implementation. An RA is a server that acts as a proxy for the CA so that CA functions can continue when the CA is unavailable. About Key Pairs Key pairs are RSA keys, which can be used for SSH or SSL connections, have the following characteristics: •For the purposes of generating keys, the maximum key modulus for RSA keys is 2048 bits. The default size is 1024 bits. Many SSL connections using identity certificates with RSA key pairs that exceed 1024 bits can cause a high CPU usage on the FWSM and rejected clientless logins. •For signature operations, the supported maximum key size is 4096 bits. •You can generate a general-purpose RSA key pair, used for both signing and encryption, or you can generate separate RSA key pairs for each purpose. Separate signing and encryption keys help reduce exposure of the keys. This is because SSL uses a key for encryption but not signing, while IKE uses a key for signing but not encryption. About Trustpoints Trustpoints let you manage and track CAs and certificates. A trustpoint is a representation of a CA or identity pair. A trustpoint contains the identity of the CA, CA-specific configuration parameters, and an association with one enrolled identity certificate. After you have defined a trustpoint, you can reference it by name in commands requiring that you specify a CA. You can configure many trustpoints. Note If an FWSM has multiple trustpoints that share the same CA, only one of these trustpoints sharing the CA can be used to validate user certificates. To control which trustpoint sharing a CA is used for validation of user certificates issued by that CA, enter the support-user-cert-validation command. You can export and import the keypair and issued certificates associated with a trustpoint in PKCS12 format, which is useful if you want to manually duplicate a trustpoint configuration on a different FWSM. About Revocation Checking When a certificate is issued, it is valid for a fixed period of time. Sometimes a CA revokes a certificate before this time period expires; for example, because of security concerns or a change of name or association. CAs periodically issue a signed list of revoked certificates. Enabling revocation checking forces the FWSM to check that the CA has not revoked a certificate every time it uses that certificate for authentication. When you enable revocation checking during the PKI certificate validation process, the FWSM checks certificate revocation status using either CRL checking, OCSP, or both, with the second method you set in effect only when the first method returns an error (for example, if the server is unavailable). With CRL checking, the FWSM retrieves, parses, and caches CRLs, which provide a complete list of revoked certificates. OCSP offers a more scalable method of checking revocation status because it localizes certificate status on a Validation Authority, which it queries for the status of a specific certificate. Certificate Configuration This section describes how to configure the FWSM with certificates and other procedures related to certificate use and management, and includes the following topics: •Preparing for Certificates •Generating Key Pairs •Removing Key Pairs •Establishing AAA Authentication •Verifying Configurations for Specified Settings •Exporting and Importing Keypairs and Certificates •Linking Certificates to a Trustpoint •Configuration Example: Cut-Through-Proxy Authentication Preparing for Certificates Before you configure a FWSM with certificates, be sure that the FWSM is correctly configured to support certificates. An incorrectly configured FWSM can cause enrollment to fail or create a certificate that includes inaccurate information. To prepare the FWSM for certificates, perform the following steps: Step 1 Be sure that the hostname and domain name of the FWSM are configured correctly. To view the hostname and domain name as currently configured, enter the following command: hostname(config)# show running-config For information about configuring the hostname, see the "Setting the Hostname" section on page 8-2. For information about configuring the domain name, see the "Setting the Domain Name" section on page 8-3. Step 2 Be sure that the FWSM clock is set accurately before configuring the CA. Certificates have a date and time on which they become valid and then expire. When the FWSM enrolls with a CA and obtains a certificate, the FWSM checks that the current time is within the valid range for the certificate. If the time is outside that range, enrollment fails. For information about setting the clock, see the "Setting the Date and Time" section on page 8-3. Generating Key Pairs Key pairs are RSA keys, as discussed in the "About Key Pairs" section. You must generate key pairs for the types of certification that you want to use. To generate key pairs, perform the following steps: Step 1 Generate the types of key pairs needed for your PKI implementation. To do so, perform the following steps, as applicable: a. To generate RSA key pairs, enter the following command. hostname/contexta(config)# crypto key generate rsa If you do not use additional keywords, executing this command generates one, general-purpose RSA key pair. Because the key modulus is not specified, the default key modulus of 1024 bits is used. You can specify other modulus sizes with the modulus keyword. Note Many SSL connections using identity certificates with RSA key pairs that exceed 1024 bits can cause high CPU usage on the FWSM and rejected clientless logins. You can also assign a label to each key pair using the label keyword. The label is referenced by the trustpoint that uses the key pair. If you do not assign a label, the key pair is automatically labeled Default-RSA-Key. b. To assign a label to each key pair, enter the following command: hostname/contexta (config)# crypto key generate rsa label key-pair-label Step 2 (Optional) To view key pair(s), enter the following command: hostname/contexta(config)# show crypto key mypubkey The following is sample output from the show crypto key mypubkey command: Key pair was generated at: 16:39:47 central Feb 10 2009 Key name: <Default-RSA-Key> Usage: General Purpose Key Modulus Size (bits): 1024 Key Data: 30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00ea51b7 0781848f 78bccac2 4a1b5b8d 2f3e30b4 4cae9f86 f4485207 159108c9 f5e49103 9eeb0f5d 45fd1811 3b4aafce 292b3b64 b4124a6f 7a777b08 75b88df1 8092a9f8 5508e9e5 2c271245 7fd1c0c3 3aaf1e04 c7c4efa4 600f4c4a 6afe56ad c1d2c01c e08407dd 45d9e36e 8cc0bfef 14f9e6ac eca141e4 276d7358 f7f50d13 79020301 0001 Key pair was generated at: 16:34:54 central Feb 10 2005 Step 3 Save the key pair that you have generated. To do so, save the running configuration by entering the following command: hostname(config)# write memory Removing Key Pairs To remove key pairs, enter the following command: hostname(config)# crypto key zeroize rsa The following is sample output from the crypto key zeroize rsa command: WARNING: All RSA keys will be removed. WARNING: All device certs issued using these keys will also be removed. Do you really want to remove these keys? [yes/no] y Establishing AAA Authentication To establish AAA authentication for traffic on which you want to perform cut-through-proxy authentication, perform the following steps: Step 1 Enter either one of the following commands: hostname (config)# aaa authentication match hostname (config)# aaa authentication include For the aaa authentication match command, you can use TACACS+ or RADIUS user accounting, or the local IP address of the host or network of hosts that you want to be authenticated or authorized on a server designated by the aaa-server command. For the aaa authentication include command, you can use only TACACS+ or RADIUS user accounting to be authenticated or authorized on a server designated by the aaa-server command. Step 2 To configure secure authentication to the HTTP client, enter the following command: hostname (config)# aaa authentication secure-http-client For more information about command usage, see the Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Command Reference. Verifying Configurations for Specified Settings Before you import third-party certificates, you must have configured certain AAA settings, the AAA server, access lists, and optionally, virtual HTTP. To verify configurations for specified settings, perform the following steps: Step 1 To verify that the required access lists have been configured, enter the following command: hostname(config)# show run access-list The following is sample output from the show run access-list command that displays the configured access-list: access-list temp extended permit ip any any Step 2 To verify that the AAA server has been configured, enter the following command: hostname(config)# show run aaa-server The following is sample output from the show run aaa-server command that displays the configured AAA server: aaa-server new protocol tacacs+ aaa-server new (outside) host 10.77.152.80 key cisco Step 3 To verify that the AAA settings have been configured, enter the following command: hostname(config)# show run aaa The following is sample output from the show run aaa command that displays the configured AAA settings: aaa authentication match temp outside new aaa authentication secure-http-client Step 4 (Optional) To display the imported certificate name and its associated IP address, enter the following command: hostname(config)# show run name The following is sample output from the show run name command that displays the imported certificate name and its associated IP address: name 10.77.152.104 atl-lx-sbacchus.cisco.com Step 5 (Optional) To display the virtual IP address, enter the following command: hostname(config)# show running-config virtual The following is sample output from the show running-config virtual command, which displays the name of the imported certificate that has been mapped to the virtual IP address: virtual http atl-lx-sbacchus.cisco.com Exporting and Importing Keypairs and Certificates You can export and import keypairs and issued certificates associated with a trustpoint configuration. The FWSM supports the PKCS12 format for exporting and importing trustpoints. This section includes the following topics: •Exporting a Keypair and Certificate •Importing a Keypair and Certificate Exporting a Keypair and Certificate To export keypairs and certificates associated with a trustpoint configuration in PKCS12 format, enter the following command: hostname (config)# crypto ca export pkcs12 You can copy the data. The trustpoint data is password protected; however, if you save the trustpoint data in a file, be sure that the file is in a secure location. For example, to manually export PKCS12 data for a trustpoint called newton using cisco123 as the passphrase, enter the following command: hostname (config)# crypto ca export newton pkcs12 cisco123 Exported pkcs12 follows: [ PKCS12 data omitted ] ---End - This line not part of the pkcs12--- Importing a Keypair and Certificate To import keypairs and issued certificates associated with a trustpoint configuration in PKCS12 format, perform the following steps: Step 1 Enter the following command: hostname (config)# crypto ca import pkcs12 The key pair imported with the trustpoint configuration is assigned a label that matches the name of the trustpoint that you create. For example, if an exported trustpoint used an RSA key labeled Default-RSA-Key, creating a trustpoint called Main by importing the PKCS12 format creates a key pair called Main. Note If an FWSM has trustpoints that share the same CA, only one of the trustpoints sharing the CA can be used to validate user certificates. Entering the crypto ca import pkcs12 command can create this condition. To control which trustpoint sharing a CA is used for validation of user certificates issued by that CA, enter the support-user-cert-validation command. For example, to manually import PKCS12 data to the trustpoint called newton with the passphrase cisco123, enter the following command: hostname (config)# crypto ca import newton pkcs12 cisco123 Enter the base 64 encoded pkcs12. End with a blank line or the word "quit" on a line by itself: [ PKCS12 data omitted ] quit INFO: Import PKCS12 operation completed successfully Step 2 To display an imported certificate and verify that it has been imported correctly, enter the following command: hostname (config)# show crypto ca certificates The following is sample output from the show crypto ca certificates command, which lists the name of the trustpoint, newton: CA Certificate Status: Available Certificate Serial Number: 18dad19e267de8bb4a2158cdcc6b3b4a Certificate Usage: General Purpose Public Key Type: RSA (2048 bits) Issuer Name: cn=VeriSign Class 3 Public Primary Certification Authority - G5 ou=(c) 2006 VeriSign\, Inc. - For authorized use only ou=VeriSign Trust Network o=VeriSign\, Inc. c=US Subject Name: cn=VeriSign Class 3 Public Primary Certification Authority - G5 ou=(c) 2006 VeriSign\, Inc. - For authorized use only ou=VeriSign Trust Network o=VeriSign\, Inc. c=US Validity Date: start date: 23:00:00 IST Nov 7 2006 end date: 22:59:59 IST Jul 16 2036 Associated Trustpoints: newton-1 Certificate Status: Available Certificate Serial Number: 5b178bf40eda86f320c4302cb055a743 Certificate Usage: General Purpose Public Key Type: RSA (1024 bits) Issuer Name: cn=VeriSign Class 3 Extended Validation SSL CA ou=Terms of use at https://www.verisign.com/rpa (c)06 ou=VeriSign Trust Network o=VeriSign\, Inc. c=US Subject Name: cn=atl-lx-sbacchus.cisco.com o=Cisco Systems\, Inc sa=170 West Tasman Dr l=San Jose st=California pc=95134 c=US serialNumber=C1183477 2.5.4.15=#131256312e302c20436c6175736520352e286229 1.3.6.1.4.1.311.60.2.1.2=#130a43616c69666f726e6961 1.3.6.1.4.1.311.60.2.1.3=#13025553 CRL Distribution Points: [1] http://EVSecure-crl.verisign.com/EVSecure2006.crl Validity Date: start date: 23:00:00 IST Sep 26 2007 end date: 22:59:59 IST Sep 26 2008 Associated Trustpoints: newton CA Certificate Status: Available Certificate Serial Number: 5b7759c61784e15ec727c0329529286b Certificate Usage: General Purpose Public Key Type: RSA (2048 bits) Issuer Name: cn=VeriSign Class 3 Public Primary Certification Authority - G5 ou=(c) 2006 VeriSign\, Inc. - For authorized use only ou=VeriSign Trust Network o=VeriSign\, Inc. c=US Subject Name: cn=VeriSign Class 3 Extended Validation SSL CA ou=Terms of use at https://www.verisign.com/rpa (c)06 ou=VeriSign Trust Network o=VeriSign\, Inc. c=US CRL Distribution Points: [1] http://EVSecure-crl.verisign.com/pca3-g5.crl Validity Date: start date: 23:00:00 IST Nov 7 2006 end date: 22:59:59 IST Nov 7 2016 Associated Trustpoints: newton Linking Certificates to a Trustpoint After you have imported the third-party certificate. you must link it to the trustpoint, which allows you to communicate with multiple clients. To display the name of the trustpoint, which has the same name (newton) as was used during import of the third-party certificate, enter the following command: hostname (config)# show run ssl ssl trust-point newton Configuration Example: Cut-Through-Proxy Authentication To configure an FWSM for cut-through-proxy authentication, enter the following commands: hostname(config)# access-list FWACL extended permit tcp any any eq ftp access-list FWACL extended permit tcp any any eq telnet access-list FWACL extended permit tcp any any eq www access-list FWACL extended permit tcp any any eq https access-group FWACL in interface outside timeout uauth 0:05:00 absolute aaa-server TacacsServers protocol tacacs+ reactivation-mode depletion deadtime 2 aaa-server TacacsServers host 100.136.0.3 timeout 22 key secretpassword aaa authentication match FWACL outside TacacsServers aaa accounting match FWACL outside TacacsServers aaa authentication secure-http-client auth-prompt prompt (JCPIX249) Login: auth-prompt accept (JCPIX249) Login Accepted! auth-prompt reject (JCPIX249) Login Rejected! The access-list series of commands defines which protocols are allowed through the FWSM. Only those shown in the example and SSH are supported for cut-through-proxy authentication. The timeout uauth command allows the FWSM to re-request authorization for all those protocols in five minutes. The aaa authentication command is cut-through-proxy authentication. Executing this command matches the protocols in the access list, and intercepts and prompts users for authentication. The auth-prompt series of commands changes the prompt that users see, so you know that the FWSM is making the request.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.