Configure CA Support Tasks

Configure CA Support Tasks

Configuring for RSA signatures consists of five major tasks, each requiring multiple steps. This chapter covers the CA configuration tasks and steps in detail, but those tasks and steps identical to those covered in Chapter 10 for preshared keys aren’t repeated. Refer to Chapter 10 for a detailed explanation of these steps.

The five major tasks Cisco uses and which you can expect on the exam to configure CA support are as follows. The major difference is the insertion of a new Task 2 specifically for configuring CA support.

  • Task 1 Prepare for IKE and IPSec

  • Task 2 Configure CA support

  • Task 3 Configure IKE

  • Task 4 Configure IPSec

  • Task 5 Test and verify IPSec

A summary task list showing the five tasks broken down to their individual steps and key commands is included in the Summary. As in Chapter 10, the steps are numbered to include the task number, as well as to help keep them straight.

Figure 11-4 shows the example networks from Chapter 10. These networks provide an example scenario used throughout this chapter. The goal is to create a secure VPN tunnel between Rtr1 company main office and Rtr2 at one of almost 100 branch offices in North America, Europe, and Africa. The assumption is this: the main office has reserved networks192.168.0.0 through for itself and will use one class C for each branch in the remaining to addresses.

Click To expand
Figure 11-4: Chapter scenario VPN session to be configured

Because not all configuration steps are repeated in this chapter, using the same scenario as Chapter 10 means a person performing the configurations along with the text can refer to Chapter 10 for assistance.

Task 1—Prepare for IKE and IPSec

Successful implementation of an IPSec network requires testing of the existing network and advance planning before any configuration begins. Insufficient testing and planning can lead to troubleshooting problems or configuration errors. Some preparation and planning steps include the following:

Step 1–1 and Step 1–2 are covered in detail in this chapter. The other steps are presented for review purposes, but aren’t covered in this chapter. Chapter 10 has detailed coverage of Steps 1–3 through 1–6.

  • Step 1–1 Plan for CA support

  • Step 1–2 Determine the IKE (IKE phase one) policies

  • Step 1–3 Determine the IPSec (IKE phase two) policies

  • Step 1–4 Check the current configuration

    show running-configuration

    show isakmp [policy]

    show crypto map

  • Step 1–5 Ensure the network works without encryption


  • Step 1–6 Ensure access control lists are compatible with IPSec

    show access-lists

The order of these steps could be varied based on personal preferences and implementation circumstances.

Step 1–1 Plan for CA support

Configuring CA is a complicated process, but having a detailed plan reduces the chances of improper configuration. Some basic information to be decided or collected includes the following items:

  • Determine which CA server is being used. The organizations providing CA services vary in capabilities, requirements, and the resulting configuration. Once the service provider is selected, the requirements could include the RSA key type required, CRL capabilities, and support for RA mode.

  • Identify the CA server IP address, host name, and URL. Information to use Lightweight Directory Protocol (LDAP).

  • Identify the CA server administrator contact information. This arranges for the certificates to be validated if the process isn’t automatic.

The actual information required for all CA features varies with the organization providing the CA support and can change over time with a specific organization. A good idea is always to check the CA supplier and Cisco documentation. Figure 11-5 shows the information that would be useful in configuring VeriSign CA support.

Click To expand
Figure 11-5: Configuration parameters for VeriSign CA support

Step 1–2 Determine the IKE (IKE phase one) policies

The objective here is to develop one or more IKE security policies, based on the overall company security policy. Each policy is going to require decisions about five security options: authentication method, encryption algorithm, hashing algorithm, Diffie–Hellman group, and SA lifetime.

Defining the IKE phase one policies is basically the same as with preshared keys except the authentication method will use RSA Signatures. Cisco IOS software supports preshared keys, RSA encrypted nonces, or RSA signatures to authenticate IPSec peers.

To complete the IKE planning process, what would make sense is to create a table of the preferred combination of security features, plus one or more fallback options for those devices or locations that can’t support the preferred package. The resulting table might look like the following:


Preferred (stronger)

2nd Choice

3rd Choice

Encryption algorithm




Hash algorithm




Authentication method




DH key exchange group




IKE SA lifetime





You can’t use SHA together with DES encryption on Cisco’s VPN software client version 3.6. Part of the problem with determining a set of preferences is being aware of the different platform limitations.

Using our scenario for this chapter, the Preferred column represents our configuration preferences for all North American branches and would be the only options configured. The 2nd Choice column would be for those overseas branches that can support the Preferred configuration, except for the export restriction on triple DES. Assuming they don’t form VPN sessions with anyone else, this would be the only choice configured on those devices. The 3rd Choice column might represent small branches using small routers with limited resources and options or telecommuters using Cisco’s VPN software. This would also represent the lowest level of parameter options that the main office will accept for a VPN connection. The only device that will have all three choices configured will be the main office router.

Task 2—Configure CA Support

Configuring Cisco IOS CA support can be quite complicated and requires ten steps to complete. The planning steps performed in Task 1 and the first three commands in this section ensure the actual router CA support configuration goes smoothly. The process necessary to configure CA support on Cisco routers includes the following steps:

  • Step 2–1 Manage the NVRAM memory usage (optional)

  • Step 2–2 Set the router time and date

  • Step 2–3 Configure the router host name and domain name

  • Step 2–4 Generate an RSA key pair

  • Step 2–5 Declare a CA

  • Step 2–6 Authenticate the CA

  • Step 2–7 Request your own certificate

  • Step 2–8 Save the configuration

  • Step 2–9 Monitor and maintain CA interoperability (optional)

    Request a CRL. Delete your router’s RSA keys.

    Delete both public and private certificates from the configuration.

    Delete peer’s public keys.

  • Step 2–10 Verify the CA support configuration

Step 2–1 Manage the NVRAM Memory Usage (Optional)

Certificates and CRLs are stored in NVRAM on the router, and each certificate and CRL requires a moderate amount of memory. The types of certificates stored locally on the router include the following:

  • The router’s own certificate

  • The CA’s root certificate

  • Two RA certificates if the CA supports RAs

If the CA doesn’t support an RA, there will be one CRL stored on the router. Otherwise, there will be multiple CRLs.

Depending on the router model, the NVRAM available, and whether the CA supports RAs, storing certificates and CRLs locally shouldn’t be a problem. But memory might become an issue with smaller routers, limited NVRAM, and a CA that supports RAs. If the CA supports an RA and a large number of CRLs end up being stored on the router, it can consume a large amount of NVRAM space.

To preserve limited NVRAM, you can specify that certificates and CRLs won’t be stored locally, but can be retrieved from the CA as needed. While this method can save NVRAM, it could cause a slight performance reduction and puts additional traffic out on the network.

The crypto ca certificate query Command

Use the global configuration mode crypto ca certificate query command to specify that certificates and CRLs shouldn’t be stored locally but, instead, retrieved from the CA as needed. This command puts the router into Query mode. To cause certificates and CRLs to be stored locally (the default), use the no form of this command. The command syntax is as follows:

Rtr1(config)#crypto ca certificate query

Rtr1(config)#no crypto ca certificate query


Remember, this command should only be used if NVRAM resources are inadequate to service the CA support locally.

Step 2–2 Set the Router Time and Date

For CA support to function properly, the router must have an accurate time and date to enroll with a CA server. The clock must be set accurately before generating RSA key pairs and enrolling with the CA server because the keys and certificates are time-sensitive.

Like many time-dependent processes, CA support features use the router software clock. The software clock runs from when the system powers up or a reload command is used and keeps track of the current date and time. The software clock can be set from a number of sources and, in turn, can be used to distribute the current time through various mechanisms to other systems. If no other system or process initializes the clock, it uses a date in the past as the seed value. (My lab 1720 uses 16:00:00 PST Sun Feb 28 1993).

If a router has a built-in hardware clock, the software clock is initially set at power up or reload, based on the time in the hardware clock. The software clock can then be updated from the following time sources:

  • Network Time Protocol (NTP)

  • Simple Network Time Protocol (SNTP)—some models

  • Manual configuration

Because the software clock can be dynamically updated, it has the potential to be more accurate than the hardware clock. In fact, updating the hardware clock from the software clock after synchronization is common.

The software clock can provide time to the following services:

  • CA support features

  • Access lists

  • Logging and debugging messages

  • User show commands

  • NTP

  • The hardware clock

The software clock stores time internally based on Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT). The next sections look at configuring information about the local time zone and summer time (daylight saving time), so the time is always displayed correctly relative to the local time zone.

Network Time Protocol (NTP)

NTP is an industry protocol developed to facilitate time synchronization of network devices. NTP Version 3 uses UDP transport and is documented in RFC 1305.

A specified device in a NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then periodically distributes this time across the network. NTP is an extremely efficient protocol, requiring no more than one packet per minute to synchronize two machines to the accuracy of within a millisecond of one another.

NTP uses the concept of a stratum to describe how many NTP “hops” a device is away from an authoritative time source. A stratum 1 time server typically has an authoritative time source directly attached, a stratum 2 time server receives its time via NTP from a stratum 1 time server, and so on.

Devices in a Cisco network can be configured to be a NTP server, master, or peer. The Cisco implementation of NTP doesn’t support stratum 1 service, recommending instead that time service be synchronized with a public NTP server available in the IP Internet. Note, it’s important to recognize that not all Cisco devices support NTP fully. PIX firewalls just added NTP support with v6.2 of the PIX OS, while IOS devices added support with IOS 10.0.

NTP devices avoid synchronizing to a device with inaccurate time in two ways. First, NTP will never synchronize to a device that isn’t synchronized itself. Second, NTP will compare the time reported by several devices and won’t synchronize to a device with a time significantly different than the others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers.

NTP devices are usually statically configured to create associations; each device is given the IP address of any devices with which it should form associations. In a LAN environment, configuring NTP to use IP broadcasts is often advantageous. This implementation reduces configuration complexity because each device is configured to send or receive broadcast messages.

Use the global configuration ntp peer command to configure the software clock to synchronize a peer or to be synchronized by a peer. To disable the feature, use the no form of this command. The syntax is as follows:

Rtr1(config)#ntp peer ip-address [version ver-num] [key keyid] [source interface] [prefer]

Rtr1(config)#no ntp peer ip-address


IP address of the peer providing, or being provided, the clock synchronization


NTP version number (1 to 3)* (Optional)


Authentication key to use when sending packets to this peer (Optional)


Names the interface (Optional)


Name of the interface from which to pick the IP source address (Optional)


Makes this peer the preferred peer that provides synchronization (Optional)

*If the default version (3) doesn’t result in NTP synchronization, try NTP version 2 (NTPv2).

The following example allows a router to synchronize its software clock with the peer at IP address using the default settings over the FastEthernet 0 interface.

Rtr1(config)#ntp peer source fastethernet 0

Use the interface configuration ntp broadcast client command to receive NTP broadcast packets on a specified interface. To disable this capability, use the no form of this command.

Rtr1(config-if)#ntp broadcast client

Rtr1(config-if)no ntp broadcast client

Simple Network Time Protocol (SNTP)

SNTP is a simplified, client-only version of NTP supported on smaller Cisco routers, such as the 1000, 1600, and 1700 platforms. SNTP devices can only receive the time from NTP servers. They can’t be used to provide time services to other systems.

While SNTP is simple to implement, it’s more vulnerable to a misbehaving server than an NTP client and should be used only when strong authentication isn’t required for the following reasons:

  • Accuracy to within 100 milliseconds versus 2 milliseconds for NTP

  • Doesn’t provide complex filtering and statistical mechanisms of NTP

  • Doesn’t authenticate traffic, although extended ACLs can be configured

SNTP clients can be configured to request and accept packets from NTP servers or to accept NTP broadcast packets from any source.

Use the global configuration sntp broadcast client command to use the SNTP to accept NTP traffic from any broadcast server. To prevent the router from accepting broadcast traffic, use the no form of this command.

Rtr1(config)#sntp broadcast client

Rtr1(config)#no sntp broadcast client

The following example demonstrates using the sntp broadcast client command and the show sntp command to display the results.

Router(config)#sntp broadcast client
Router#show sntp
SNTP server ???Stratum ??Version ??Last Receive ???????4 ????????3 ???????00:00:21 ??Synced ??Bcast
Broadcast client mode is enabled.
The clock timezone Command

To specify the router time zone, use the configuration mode clock timezone command. The command sets the time zone and an offset from UTC, displayed by the router. The command syntax is as follows:

Rtr1(config)#clock timezone zone hour-offset [minute-offset]


Name of the time zone to be displayed (typically a standard acronym).


Hours offset from UTC.


Minutes offset from UTC. (Optional). This argument is for those cases where a local time zone is a percentage of an hour different from UTC/GMT.

The following example demonstrates setting the time zone to Central Standard Time (CST) in the United States. The -6 indicates CST is 6 hours behind UTC.

Rtr1(config)#clock timezone CST -6 

The zone entry isn’t a keyword. What you type is what you’ll get, including case usage. Spaces aren’t allowed. The following example demonstrates creating a custom entry. The show clock command displays the current settings. Notice the date and time setting is old, indicating the router hasn’t had the software clock set. This is covered in the next section, “The clock set Command.”

Rtr1(config)#clock timezone Pacific.Standard.Time -8
Rtr1#show clock
*17:51:09.799 Pacific.Standard.Time Sun Feb 28 1993

For more information on UTC, time zones, and common time zone abbreviations, go to

The clock set Command

If the system time is synchronized by a valid outside timing mechanism, such as a Network Time Protocol (NTP), or if it can be set using the router hardware clock, it shouldn’t be necessary to set the software clock. Use this command if no other time sources are available.

To set the router’s time and date manually, use the privileged EXEC clock set command. This command isn’t available in Configuration mode. The time specified in this command is relative to the configured time zone. The command syntax is either of the following:

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

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


Current time in hours, minutes, and seconds (24-hour format)


Current day of the month


Current month (by name)


Current year (4-digit format)

There are no defaults and all elements are required, even the seconds. The following example sets the time to 6:15 P.M. on December 15, 2004. While the full month can be typed out, it’s only necessary to type the first three letters. The output is the same, regardless of whether the entry is abbreviated or the case of the entry.

Rtr1#clock set 18:15:00 15 december 2004 
Rtr1#show clock
18:15:28.279 PST Wed Dec 15 2004
Setting the Software Clock from the Hardware Clock

If the router has a hardware-based clock, it’s possible to set the software clock to the new hardware clock setting by using the following privilege EXEC mode command. If the router doesn’t have a hardware clock, the command is rejected.

Rtr1#clock read-calendar
Setting the Hardware Clock

To update the hardware clock with the current software clock setting, use the following privilege EXEC mode command. If the router doesn’t have a hardware clock, the command is rejected.

Rtr1#clock update-calendar

You can periodically update the hardware clock (calendar) from a NTP time source, using the global configuration ntp update-calendar command. To disable the periodic updates, use the no form of this command.

Rtr1(config)#ntp update-calendar
Rtr1(config)#no ntp update-calendar
Configuring Daylight Saving Time

To configure daylight saving time (summer time) in areas where it starts and ends on a particular day of the week each year, use the following global configuration mode command. To avoid automatically switching to summer time, use the no form of this command.

Rtr1(config)#clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]


Time zone name, such as PDT for Pacific Daylight Time, to be displayed when summer time is in effect


Summer time starts and ends on the corresponding specified days every year


Week of the month, 1 to 5 or last (Optional)


Day of the week (Sunday, Monday, and so on) (Optional)


Month (January, February, and so on) (Optional)


Number of minutes to add during summer time (default is 60) (Optional)

The first week day month hh:mm is when daylight saving time starts, while the last one represents when it ends.

The following example specifies that summer time starts on the first Sunday in April at 2 A.M. and ends on the last Sunday in October at 2 A.M.:

Rtr1(config)# clock summer-time PDT recurring 1 Sunday April 2:00 last Sunday October 2:00

For those areas that have a varying daylight saving time, it’s possible to configure the exact date and time of the next summer time event by using either of the following global configuration mode commands. To avoid automatically switching to summer time, use the no form of this command.

Rtr1(config)#clock summer-time zone date month date year hh:mm month date year hh:mm [offset]

Rtr1(config)#no clock summer-time zone date month date year hh:mm month date year hh:mm [offset]

Rtr1(config)#clock summer-time zone date date month year hh:mm date month year hh:mm [offset]

Rtr1(config)#no clock summer-time zone date date month year hh:mm date month year hh:mm [offset]


Summer time starts on the first specific date listed in the command and ends on the second specific date in the command


Date of the month (1 to 31)


Text month (January, February, and so on) (Optional)


Four-digit year (1993 to 2035)


Number of minutes to add during summer time (default is 60) (Optional)

In the following example, daylight saving time (summer time) for Pacific Daylight Time is configured to start on April 26, 1997 at 2 A.M. and end on October 12, 1997at 2 A.M. The show clock command with the Detail option displays the current settings:

Rtr1(config)#clock summer-time PDT date 26 Apr 2004 2:00 12 Oct 2004 2:00
Rtr1#show clock detail
18:23:40.399 PST Thu Apr 15 2004
Time source is user configuration
Summer time starts 02:00:00 PST Mon Apr 26 2004
Summer time ends 02:00:00 PDT Tue Oct 12 2004
Monitoring Time and Calendar Services

To monitor clock, calendar, and NTP EXEC services, use the following commands in EXEC mode, as needed:

Rtr1#show calendar

Displays the current hardware clock time.

Rtr1#show clock [detail]

Displays the current software clock time.

Rtr1#show ntp associations [detail]

Displays the status of NTP associations.

Rtr1#show ntp status

Displays the status of NTP.

Step 2–3 Configure the Router Host Name and Domain Name

If the router’s host name and domain name haven’t been configured, it’s necessary to configure them for CA support to work correctly. The host name is used in prompts and default configuration file names. The domain name is used to define a default domain name, which the Cisco IOS software uses to complete unqualified host names.

Use the global configuration hostname command to specify or modify the host name for the network server. The command syntax is as follows:

Rtr1(config)#hostname host-name

Use the global configuration ip domain-name command to define a default domain name that the Cisco IOS software uses to complete unqualified host names (names without a dotted-decimal domain name). To disable the default domain name, use the no form of this command. The command syntax is as follows:

Rtr1(config)#ip domain-name dom-name

The following example shows configuring a host name and default domain name:

Router(config)#hostname Rtr1
Rtr1(config)#ip domain-name
Name Resolution Alternative

In a system without a DNS server, using the global configuration ip host command to define a static host name-to-address mapping is possible. Each host name can be associated with up to eight IP addresses separated by spaces. To remove the name-to-address mapping, use the no form of the command. The command syntax is as follows:

Rtr1(config)#ip host name address1 [address2...address8]

The following example shows creating an IP Host entry to resolve the CA server name because it can’t be resolved using DNS features:

Rtr1(config)#ip host ca-server

Step 2–4 Generate a RSA Key Pair

RSA signatures support two mutually exclusive types of RSA key pairs.

  • General-purpose keys

  • Special-usage keys

When generating RSA key pairs, you can indicate whether to generate general-purpose keys or special-usage keys. If the usage-keys keyword isn’t specified in the crypto key generate rsa command, the general-purpose keys are generated.

General Purpose Keys

With general purpose keys, only one pair of RSA keys is generated. The generated pair is used for any IKE policies specifying either RSA signatures or RSA-encrypted nonces. Therefore, a general purpose key pair might get used more frequently than a special usage-key pair, increasing the chances of compromise.

Special-Usage Keys

If the usage-keys option is specified, two separate pairs of RSA keys are generated for signing and encryption. One pair is used with any IKE policy that includes RSA signatures as the authentication method. The other pair is used with any IKE policy that specifies RSA encrypted nonces as the authentication method. RSA encrypted nonces are covered in the “RSA Encrypted Nonces Overview” section.

If the security policy specifies to have both types of RSA authentication methods in the IKE policies, it would be best to generate special-usage keys. By using the special-usage keys, each key isn’t unnecessarily exposed. Otherwise, the single key is used for both authentication methods, increasing that key’s exposure.

Modulus Length

The key generation process can be both a lengthy and resource- intensive process, depending on the router platform and the length of the key modulus specified. When generating RSA keys, the system will prompt for the number of bits to use in the modulus key. The default is 512 bits, with a range of choices from 360 to 2,048 bits. A longer modulus provides stronger security, but takes longer to generate and use. A modulus of less than 512 bits is generally considered too vulnerable. Under some circumstances, a short modulus might not function properly with IKE policies. Cisco recommends using a minimum modulus of 1,024 bits.

The following table compares the processing time for generating general-purpose key pairs with various-length modulus values.


360 bits

512 bits

1,024 bits

2,048 bits

Cisco 2500

11 seconds

20 seconds

4 minutes, 38 seconds

more than 1 hour

Cisco 4700

less than 1 second

1 second

4 seconds

50 seconds

The crypto key generate rsa command

The global configuration crypto key generate rsa command is used to generate RSA key pairs for a Cisco device, such as a router. If the router already has RSA keys, a warning is displayed, along with a prompt to replace the existing keys with new keys. The command syntax is as follows:

Rtr1(config)#crypto key generate rsa [usage-keys]


Specifies two RSA special-usage key pairs should be generated (that is, one encryption pair and one signature pair), instead of one general-purpose key pair. (Optional)


If the host name and the IP domain name weren’t created in Step 2–3, the crypto key generate rsa command will fail.

This command isn’t saved in the router configuration. The keys generated are saved in the private configuration in NVRAM, however, which is never displayed to the user or backed up to another device.

The following example shows generating a special-usage key pair followed by the show crypto key mypubkey rsa command demonstrating the result:

Rtr1(config)#crypto key generate rsa usage-keys
The name for the keys will be:
Choose the size of the key modulus in the range of 360 to 2048 for your
 ?Signature Keys. Choosing a key modulus greater than 512 may take
 ?a few minutes.

How many bits in the modulus [512]: 2048
Generating RSA keys ...

Rtr1#show crypto key mypubkey rsa
% Key pair was generated at: 00:21:00 PST Dec 16 2004
Key name:
 Usage: Signature Key
 Key Data:
 ?30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
 ?009407CE 65AF10C8 A8D0023F 4CF157FE C359B0BF B21D86C8 9415D8EB B62878AB
 ?C559AD80 B6B5FD2F F2D4DEAD B6181350 9F937A17 BD23F2C0 CA0759DF 2D51F12C
 ?B60B2E9F 4F0ECD86 4B3C2B7E 5E30A4E7 D1C47D22 6ADEF189 BB99197E BAA741FF
 ?6014E0D5 426F37A8 6722A920 93DCB02F 6D5D6670 D3E4DAD1 7ECC6DF2 02D52A45
 ?53B45062 BF1685BC DF042887 79349774 82BC82E6 CA276477 65645CF6 E78E350E
 ?0C259D9F 366FD38F B78D16E2 F48839D5 DBA0D138 99CD26C1 3333C03D 1BBBD5B4
 ?7509E413 38D25619 EB5C4138 4B539EDB B0080E40 5FC179BA B1A5A5EF 0CD1CC2C
 ?BB6D018A D3BA4CD9 8F502553 7FEFB1D0 070177C5 DBAC2EBE 19D9E1A2 052F2B44
 ?A5020301 0001
% Key pair was generated at: 00:25:16 PST Dec 16 2004
Key name:
 Usage: Encryption Key
 Key Data:
 ?30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101
 ?00C50963 248DD7E2 E21191E4 1AD6A0D7 2D8EF5E5 8952B071 1FF8C18E C6E5F53B
 ?37DBB9E2 52A3BD1B 9C02444B EABC0E85 96C9866B 164AE96F CD27F448 C1C93028
 ?5B8A024D 7939E533 66D0CC37 6F512BF9 1432E6EC 791DC05D 4059A552 17EF7326
 ?664DB438 847461E4 8ECBBEB0 622E0CA3 1EA97ECA DF9B5C8F 65A0D887 23CADB33
 ?6F3D3BA4 C1962E66 C7753335 A41D63AE 1DB69086 6A63AF1C F008B7FD 94F41240
 ?087150CA 1422730E 3D06F070 09F4C630 09F6B3A0 8838E2F7 9CEDC701 DCBB7D6E
 ?0178D788 5235DBE0 033681C8 23CF2134 2DDC4151 CF86152B 391F456A 74135B61
 ?EB15D797 CECE8493 FEC16D9C 47BE7410 D0EF2353 61A3C108 08325630 8519D89D
 ?07020301 0001
% Key pair was generated at: 00:25:22 PST Dec 16 2004
Key name:
 Usage: Encryption Key
 Key Data:
 ?307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B7ED8C E4C06C08
 ?C8DE36F5 DDEEEB78 A0F1FA0E 4C8CAC32 2B4AC0A4 B813F56F FEA8B7F7 5C372C66
 ?55A1189E 0A373898 846B0679 497F9474 29EB1088 E31ED19E 771C10C6 C35A98D0
 ?226AEDB3 FE42066A A81FD230 4FFCBCD0 0159D879 6F632FFA 1F020301 0001

Step 2–5 Declare a CA

Use the global configuration crypto ca identity command to specify what CA the router will use. The CA might require a particular name, such as its domain name. Use the no form of this command to delete all identity information and certificates associated with the CA. The command syntax is as follows:

Rtr1(config)#crypto ca identity name

Rtr1(config)#no crypto ca identity name

If the CA has been previously declared and updating its characteristics is all that’s required, just specify the name previously created. Performing the crypto ca identity command initiates the ca-identity Configuration mode, where CA characteristics can be defined, as shown in the following output:

Rtr1(config)#crypto ca identity ca-ipsec
CA identity configuration commands:
 ?crl ????????CRL option
 ?default ????Set a command to its defaults
 ?enrollment ?Enrollment parameters
 ?exit ???????Exit from certificate authority identity entry mode
 ?no ?????????Negate a command or set its defaults
 ?query ??????Query parameters


Some of the more common CA characteristics that can be defined in ca-identity Configuration mode include the following. Use the no form of the commands to remove the feature.

enrollment url

URL of the CA—required

enrollment mode ra

RA mode—required if the CA system supports a registration authority (RA).

query url

URL of the Lightweight Directory Access Protocol (LDAP) server—required if the CA supports an RA and the LDAP protocol.

enrollment retry period

Minutes the router will wait between sending certificate request retries. Range 0 to 60 minutes. Default is one minute. (Optional)

enrollment retry count

Number of certificate request retries the router will send before giving up. Range 1 to 100. Default is 0, which allows an infinite number of retries. (Optional)

crl optional

Specify whether the router can accept other peers’ certificates if the certificate revocation list isn’t accessible. Without this command, CRL checking is mandatory. (Optional)

The following is an example of the identity options that might be used with Verisign as the CA service provider. The choices and options vary with provider.

Rtr1(config)#crypto ca identity ca-ipsec
Rtr1(ca-identity)#enrollment url
Rtr1(ca-identity)#query url ldap://
Rtr1(ca-identity)#crl optional
Rtr1(ca-identity)#enrollment mode ra
Rtr1(ca-identity)#enrollment retry count 10
Rtr1(ca-identity)#enrollment retry period 5

The crypto ca identity is only significant locally. It needn’t match the identity defined on any VPN peer.

Step 2–6 Authenticate the CA

The router needs to authenticate the validity of the CA by obtaining its self-signed certificate containing the CA’s public key. Because the CA’s certificate is self-signed, its public key should be manually authenticated by contacting the CA administrator.

If the CA support is using RA mode, the enrollment mode ra command in Step 2–5, then RA signing and encryption certificates will accompany the CA certificate.

To authenticate the certification authority (and RA, if appropriate), use the global configuration crypto ca authenticate command. Use the same name used to declare the CA with the crypto ca identity command:

Rtr1(config)#crypto ca authenticate name

If the CA doesn’t respond within the timeout period defined in the ca identity commands, the command will fail. If this happens, you must reenter the command. The following show a representation of a successful CA authentication:

Rtr1(config)#crypto ca authenticate ca-ipsec
Certificate has the following attributes:
Fingerprint: 9876 5432 1098 7654 3210
Do you accept this certificate? [yes/no]

While the command isn’t saved to the router configuration, the public keys embedded in the received CA (and RA) certificates are saved to the configuration as part of the RSA public key record called the “RSA public key chain.”

Step 2–7 Request Your Own Certificate

The next step requires the local router to obtain its certificate from the CA using the global configuration crypto ca enroll command. Use the same name as when you declared the CA using the crypto ca identity command. Use the no form of this command to delete a current enrollment request:

Rtr1(config)#crypto ca enroll name

Rtr1(config)#no crypto ca enroll name

The router needs a signed certificate from the CA for each of the router’s RSA key pairs. With a RSA general purpose key request in Step 2–4, this command will obtain one certificate corresponding to the general purpose RSA key pair. If the RSA key request was for special-usage keys, this command will return two certificates corresponding to each of the special-usage key pairs. This task is also known as enrolling with the CA.

If certificates already exist for each key pair, the command will fail and a prompt will appear, advising the existing certificates be removed first. Removing the existing certificates is accomplished with the no certificate command.

Responding to Prompts

During the enrolling process with the CA, several prompts appear. The actual prompts can vary with the CA provider and over time. The following example is included as representative of what you can expect.

First, you must create and verify a challenge password. This challenge password is important because it’s required if you ever need to revoke the router’s certificate(s). The password can be up to 80 characters in length. This password isn’t stored anywhere by the router, so you must remember it or secure it in a safe place. A lost password might not absolutely prevent revocation, but the CA administrator will undoubtedly require additional authentication of the router administrator identity.

Second, a prompt will ask for a subject name in the certificate. In the following example, the fully qualified domain name of the local device was used.

Third, a prompt will ask whether to include the router’s serial number in the certificate. This is an internal board serial number rather than the one on the case. While the serial number isn’t used by IPSec or the IKE process, it can be used by the CA to authenticate certificates or to associate a certificate with that particular router.

Fourth, a prompt will ask whether to include the router’s IP address. This might not be a good idea in some cases because the IP address binds the certificate more tightly to a specific entity. If the router is moved, requiring a new IP address, then requesting a new certificate would also be necessary. If including the IP address is selected, a prompt will ask for the interface of the IP address. The interface should correspond to the interface to which the crypto map is applied.

The following example shows an RSA general-purpose key pair request for a certificate from the CA. Ultimately, the router displays the certificate fingerprint, at which time the local administrator verifies the fingerprint by calling the CA administrator. If the fingerprint is correct, the router administrator accepts the certificate.

A delay might occur between when the certificate request is sent and when the certificate is received by the router. The length of any delay depends on the CA authorization process.

Rtr1(config)#crypto ca enroll ca-ipsec
% 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: ca-password
Re-enter password: ca-password
% The subject name in the certificate will be:
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: 01234567
% Include an IP address in the subject name [yes/no]? no
Interface: fastethernet 0
Request certificate from CA [yes/no]? yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.

At a later time, the router receives the certificate from the CA and displays a confirmation message, such as the following:

Rtr1(config)#Fingerprint: 1234 9876 5432 1098 7654
%CRYPTO-6-CERTRET: Certificate received from Certificate Authority

If the certificate request can’t be granted for any reason, a message like the following is displayed at the router instead:

%CRYPTO-6-CERTREJ: Certificate enrollment request was rejected by
 ?Certificate Authority

Step 2–8 Save the Configuration

After completing the router configuration for CA support, the configuration should be saved using the copy running-config startup-config command.

Step 2–9 Monitor and Maintain CA Interoperability (Optional)

The following housekeeping measures are optional and will vary, based on the CA server requirements and operational circumstances:

  • Request a CRL

  • Delete your router’s RSA keys

  • Delete both public and private certificates from the configuration

  • Delete peer’s public keys

Request a CRL

When the router receives a certificate from a peer, it will download a CRL from either the CA or from a CA-designated CRL distribution point. The router then looks for the certificate on the CRL to make sure it hasn’t been revoked. The router won’t accept the certificate and it won’t authenticate the peer if the certificate appears on the CRL. A CRL can continue to be reused with other certificates until the CRL expires. If the router receives a certificate after the CRL has expired, it will download the latest CRL.

If the CA system supports RAs, multiple CRLs can exist. The certificate in question will indicate which CRL applies and should be downloaded by the router for authentication. If the router doesn’t have or is unable to download the appropriate CRL, the certificate will normally be rejected. The exception to this would be if the router configuration contains the crl optional feature under the crypto ca identity command. With the crl optional command, the router will still try to get the required CRL, but failing that, it can accept the peer’s certificate anyway. The router will continue to try to get the CRL.

If the CA server requires a local CRL, use the global configuration crypto ca crl request command to request an immediate download of the latest CRL. Use the same name used to declare the CA with the crypto ca identity command:

Rtr1(config)#crypto ca crl request name

An example for the chapter scenario would look like the following:

Rtr1(config)#crypto ca crl request ca-ipsec
Delete Router’s RSA Keys

While this could seem like a harsh step, it might be necessary to delete a router’s RSA keys if you had reason to

Part III: Virtual Private Networks (VPNs)