Configuring Certification Authority Interoperability

For background and configuration information for IPSec, see the "Configuring IPSec Network Security" chapter.

For a complete description of the commands used in this chapter, refer to the "Certification Authority Interoperability Commands" chapter in the Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

• IPSec---IP Security Protocol. IPSec is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses IKE to handle negotiation of protocols and algorithms based on local policy, and to generate the encryption and authentication keys to be used by IPSec. IPSec can be used to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

For more information on IPSec, see the "Configuring IPSec Network Security" chapter.

• Internet Key Exchange (IKE)---A hybrid protocol which implements Oakley and Skeme key exchanges inside the ISAKMP framework. While IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec keys, and negotiates IPSec security associations.

For more information on IKE, see the "Configuring Internet Key Exchange Security Protocol" chapter.

CAs simplify the administration of IPSec network devices. You can use a CA with a network containing multiple IPSec-compliant devices such as routers.

Digital signatures, enabled by public key cryptography, provide a means to digitally authenticate devices and individual 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 user's private key. The receiver verifies the signature by decrypting the message with the sender's public key. The fact that the message could be decrypted using the sender's public key indicates that the holder of the private key, the sender, must have created the message. This process relies on the receiver having a copy of the sender's public key and knowing with a high degree of certainty that it really does belong to the sender, and not to someone pretending to be the sender.

Digital certificates provide this link. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department or IP address. It also contains a copy of the entity's public key. The certificate is itself signed by a Certificate Authority (CA) a third party that is explicitly trusted by the receiver to validate identities and to create digital certificates.

In order to validate the CA's signature, the receiver must first know the CA's public key. Normally this is handled out-of-band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default. The Internet Key Exchange (IKE), a key component of IPSec, can use digital signatures to scaleably authenticate peer devices before setting up security associations.

Without digital signatures, one must either manually exchange public keys or secrets between each pair of devices that use IPSec to protect communications between them. Without certificates, every new device added to the network requires a configuration change on every other device it securely communicates with. However, by using digital certificates, each device is enrolled with a certificate authority. When two devices wish to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new device is added to the network, one simply enrolls that device with a CA, and none of the other devices need modification. When the new device attempts an IPSec connection, certificates are automatically exchanged and the device can be authenticated.

• At each router, enter the other router's RSA public key, or

• At each router, specify a shared key to be used between the routers.

To add a new IPSec router to the network, you only need to configure that new router to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPSec routers.

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

Some of the configuration tasks described in this document differ slightly depending on whether your CA supports an RA or not.

In some cases, storing these certificates and CRLs locally will not present a problem. However, in other cases, memory might become an issue---particularly if your CA supports an RA and a large number of CRLs end up being stored on your router.

If you do not turn on query mode at this time, but later decide that you should, you can turn on query mode at that time even if certificates and CRLs have already been stored on your router. In this case, when you turn on query mode, the stored certificates and CRLs will be deleted from the router after you save your configuration. (If you copy your configuration to a TFTP site prior to turning on query mode, you will save any stored certificates and CRLs at the TFTP site.)

To configure the router's host name and IP domain name, use the following commands in global configuration mode:

Step	Command	Purpose
1 .	hostname name	Configure the router's host name.
2 .	ip domain-name name	Configure the router's IP domain name.

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

Command	Purpose
crypto key generate rsa [usage-keys]	Generate an RSA key pair. Use the usage-keys keyword to specify special usage keys instead of general purpose keys. See the command description for an explanation of special usage vs. general purpose keys.

To declare a CA, use the following commands starting in global configuration mode:

Step	Command	Purpose
1 .	crypto ca identity name	Declare a CA. The name should be the CA's domain name. This command puts you into the ca-identity configuration mode.
2 .	enrollment url url	Specify the URL of the CA. (The URL should include any non-standard cgi-bin script location.)
3 .	enrollment mode ra	If your CA system provides a Registration Authority (RA), specify RA mode.
4 .	query url url	If your CA system provides an RA and supports the LDAP protocol, specify the location of the LDAP server.
5 .	enrollment retry-period minutes	(Optional) Specify a retry period. After requesting a certificate, the router waits to receive a certificate from the CA. If the router does not receive a certificate within a period of time (the retry period) the router will send another certificate request. You can change the retry period from the default of 1  minute.
6 .	enrollment retry-count count	(Optional) Specify how many times the router will continue to send unsuccessful certificate requests before giving up. By default, the router will never give up trying.
7 .	crl optional	(Optional) Specify that other peers' certificates can still be accepted by your router even if the appropriate CRL is not accessible to your router.
8 .	exit	Exit ca-identity configuration mode.

To request signed certificates from the CA, use the following command in global configuration mode:

Command

Purpose

crypto ca enroll name

Request certificates for all of your RSA key pairs. This command causes your router to request as many certificates as there are RSA key pairs, so you only need to perform this command once, even if you have special usage RSA key pairs. Note This command requires you to create a challenge password that is not saved with the configuration. This password is required in the event your certificate needs to be revoked, so remember this password.

A CRL can be reused with subsequent certificates until the CRL expires if query mode is off. If your router receives a peer's certificate after the applicable CRL has expired, the router will download the new CRL.

If your router has a CRL which has not yet expired, but you suspect that the CRL's contents are out of date, you can request that the latest CRL be immediately downloaded to replace the old CRL.

To delete all of your router's RSA keys, use the following command in global configuration mode:

Command	Purpose
crypto key zeroize rsa	Delete all of your router's RSA keys.

After you delete a router's RSA keys, you should also complete these two additional tasks:

To delete a peer's RSA public key, use the following commands starting in global configuration mode:

Step	Command	Purpose
1 .	crypto key pubkey-chain rsa	Enter public key configuration mode.
2 .	no named-key key-name [encryption | signature] or no addressed-key key-address [encryption | signature]	Delete a remote peer's RSA public key. Specify the peer's fully qualified domain name or the remote peer's IP address.
3 .	exit	Return to global configuration mode.

To delete the CA's certificate, you must remove the entire CA identity, which also removes all certificates associated with the CA---your router's certificate, the CA certificate, and any RA certificates.

In this example general purpose RSA keys were generated, but you will notice that the keys are not saved or displayed in the configuration.

Comments are included within the configuration to explain various commands.