Configure CA Support Tasks

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

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

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

Rtr1(config)#ntp peer 192.168.1.45 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(config)#end
Router#show sntp
SNTP server ???Stratum ??Version ??Last Receive
10.0.115.2 ???????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]

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(config)#^Z
Rtr1#show clock
*17:51:09.799 Pacific.Standard.Time Sun Feb 28 1993
Rtr1#

For more information on UTC, time zones, and common time zone abbreviations, go to http://www.timeanddate.com/worldclock.

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

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
Rtr1#

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]]

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]

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(config)#^Z
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
Rtr1#

Monitoring Time and Calendar Services

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

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 192.168.1.100

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.

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]

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: Rtr1.ca-test.com
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 ...
[OK]

Rtr1(config)#^Z
Rtr1#show crypto key mypubkey rsa
% Key pair was generated at: 00:21:00 PST Dec 16 2004
Key name: Rtr1.ca-test.com
 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: Rtr1.ca-test.com
 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: Rtr1.ca-test.com.server
 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
Rtr1#

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: rtr1.ca-test.com
% 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.
Rtr1(config)#

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
Rtr1(config)#

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

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