This chapter describes how to configure Certification Authority (CA) interoperability, which is provided in support of the IP Security (IPSec) standard. CA interoperability permits Cisco IOS devices and CAs to communicate so that your Cisco IOS device can obtain and use digital certificates from the CA. Although IPSec can be implemented in your network without the use of a CA, using a CA provides manageability and scalability for IPSec.
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.
Without CA interoperability, Cisco IOS devices could not use CAs when deploying IPSec. CAs provide a manageable, scalable solution for IPSec networks. For details, see "Overview of Certificate Authorities."
Cisco supports the following standards with this feature:
This feature is useful and should be configured only when you also configure both IPSec and IKE in your network.
You need to have a Certification Authority (CA) available to your network before you configure this interoperability feature. The CA must support Cisco's PKI protocol, the certificate enrollment protocol (CEP).
This section provides background information about CAs, including the following:
CAs are responsible for managing certificate requests and issuing certificates to participating IPSec network devices. These services provide centralized key management for the participating devices.
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.
Without a CA, if you want to enable IPSec services (such as encryption) between two Cisco routers, you must first ensure that each router has the other router's key (such as an RSA public key or a shared key). This requires that you manually perform one of the following:
In Figure 24, each router uses the other router's key to authenticate the identity of the other router; this authentication always occurs whenever IPSec traffic is exchanged between the two routers.
If you have multiple Cisco routers in a mesh topology, and wish to exchange IPSec traffic passing between all of those routers, you must first configure shared keys or RSA public keys between all of those routers:
Every time a new router is added to the IPSec network, you must configure keys between the new router and each of the existing routers. (In Figure 25, four additional 2-part key configurations would be required to add a single encrypting router to the network).
Consequently, the more devices there are that require IPSec services, the more involved the key administration becomes. Obviously, this approach does not scale well for larger, more complex encrypting networks.
With a CA, you do not need to configure keys between all of the encrypting routers. Instead, you individually enroll each participating router with the CA, requesting a certificate for the router. When this has been accomplished, each participating router can dynamically authenticate all of the other participating routers. This is illustrated in Figure 26.
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.
When two IPSec routers want to exchange IPSec-protected traffic passing between them, they must first authenticate each other---otherwise, IPSec protection cannot occur. The authentication is done with IKE.
Without a CA, a router authenticates itself to the remote router using either RSA encrypted nonces or pre-shared keys. Both methods require that keys must have been previously configured between the two routers.
With a CA, a router authenticates itself to the remote router by sending a certificate to the remote router and performing some public key cryptography. Each router must send its own unique certificate which was issued and validated by the CA. This process works because each router's certificate encapsulates the router's public key, each certificate is authenticated by the CA, and all participating routers recognize the CA as an authenticating authority. This is called IKE with an RSA signature.
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.
CAs can also revoke certificates for devices that will no longer participate in IPSec. Revoked certificates are not recognized as valid by other IPSec devices. Revoked certificates are listed in a Certificate Revocation List (CRL), which each peer may check before accepting another peer's certificate.
Some CAs have a Registration Authority (RA) as part of their implementation. An RA is essentially a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.
Some of the configuration tasks described in this document differ slightly depending on whether your CA supports an RA or not.
To enable your Cisco device to interoperate with a CA, complete the tasks in the following sections. Some of the tasks are optional; the remaining are required.
For CA interoperability configuration examples, refer to the "CA Interoperability Configuration Examples" section located at the end of this chapter.
Certificates and Certificate Revocation Lists (CRLs) are used by your router when a CA is used. Normally certain of these certificates and all CRLs are stored locally in the router's NVRAM, and each certificate and CRL uses a moderate amount of memory.
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.
To save NVRAM space, you can specify that certificates and CRLs should not be stored locally, but should be retrieved from the CA when needed. This will save NVRAM space but could result in a slight performance impact.
To specify that certificates and CRLs should not be stored locally on your router, but should be retrieved when required, turn on query mode by using the following command in global configuration mode:
Turn on query mode, which causes certificates and CRLs to not be stored locally.
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.)
If you turn on query mode now, you can turn off query mode later if you wish. If you turn off query mode later, you could also perform the copy system:running-config nvram:startup-config command at that time to save all current certificates and CRLs to NVRAM (otherwise they could be lost during a reboot and would need to be retrieved the next time they were needed by your router).
You must configure the router's host name and IP domain name if this has not already been done. This is required because the router assigns a fully qualified domain name (FQDN) to the keys and certificates used by IPSec, and the FQDN is based on the host name and IP domain name you assign to the router. For example, a certificate is named "router20.domain.com" based on a router host name of "router20" and a router IP domain name of "domain.com."
To configure the router's host name and IP domain name, use the following commands in global configuration mode:
Configure the router's host name.
ip domain-name name
Configure the router's IP domain name.
RSA key pairs are used to sign and encrypt IKE key management messages and are required before you can obtain a certificate for your router.
To generate an RSA key pair, use the following command in global configuration mode:
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.
You should declare one Certification Authority (CA) to be used by your router.
To declare a CA, use the following commands starting in global configuration mode:
Declare a CA. The name should be the CA's domain name.
This command puts you into the ca-identity configuration mode.
enrollment url url
(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.
By default, the router will never give up trying.
Exit ca-identity configuration mode.
The trade-off between security and availability is determined by the query url and crl optional commands, as shown in Table 23.
|Query - Yes||Query - No|
|CRL Optional - Yes|
Sessions will go through even if the CA is not available, but the certificate might have been revoked.
Sessions will go through even if the CA is not available, but the certificate might have been revoked.
|CRL Optional - No|
Certificates will not be accepted if the CA is not available.
Sessions will go through, and will be verified against the CRL stored locally.
The router needs to authenticate the CA. It does this by obtaining the CA's self-signed certificate which contains the CA's public key. Because the CA's certificate is self-signed (the CA signs its own certificate) the CA's public key should be manually authenticated by contacting the CA administrator to compare the CA certificate's fingerprint when you perform this step.
To get the CA's public key, use the following command in global configuration mode:
Get the CA's public key. Use the same name that you used when declaring the CA with the crypto ca identity command.
You need to obtain a signed certificate from the CA for each of your router's RSA key pairs. If you generated general purpose RSA keys, your router only has one RSA key pair and needs only one certificate. If you previously generated special usage RSA keys, your router has two RSA key pairs and needs two certificates.
To request signed certificates from the CA, use the following command in global configuration mode:
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.
Always remember to save your work when you make configuration changes.
Perform the copy system:running-config nvram:startup-config command to save your configuration---this command includes saving RSA keys to private NVRAM. RSA keys are not saved with your configuration when you perform a copy system:running-config rcp: or copy system:running-config tftp: command.
The following tasks are optional, depending on your particular requirements:
You can request a Certificate Revocation List (CRL) only if your CA does not support a Registration Authority (RA). The following description and task applies only when the CA does not support an RA.
When your router receives a certificate from a peer, your router will download a CRL from the CA. Your router then checks the CRL to make sure the certificate the peer sent has not been revoked. (If the certificate appears on the CRL, your router will not accept the certificate and will not authenticate the peer.)
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 request immediate download of the latest CRL, use the following command in global configuration mode:
Request an updated CRL.
This command replaces the currently stored CRL at your router with the newest version of the CRL.
There might be circumstances where you would want to delete your router's RSA keys. For example, if you believe the RSA keys were compromised in some way and should no longer be used, you should delete the keys.
To delete all of your router's RSA keys, use the following command in global configuration mode:
Delete all of your router's RSA keys.
After you delete a router's RSA keys, you should also complete these two additional tasks:
There might be circumstances where you would want to delete other peer's RSA public keys from your router's configuration. For example, if you no longer trust the integrity of a peer's public key, you should delete the key.
To delete a peer's RSA public key, use the following commands starting in global configuration mode:
Delete a remote peer's RSA public key. Specify the peer's fully qualified domain name or the remote peer's IP address.
Return to global configuration mode.
If the need arises, you can delete certificates that are saved at your router. Your router saves its own certificate(s), the CA's certificate, and any RA certificates (unless you put the router into query mode per the "Manage NVRAM Memory Usage (Optional)" section).
To delete your router's certificate or RA certificates from your router's configuration, use the following commands in global configuration mode:
show crypto ca certificates
View the certificates stored on your router; note (or copy) the serial number of the certificate you wish to delete.
no certificate certificate-serial-number
Delete the certificate.
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.
To remove a CA identity, use the following command in global configuration mode:
Delete all identity information and certificates associated with the CA.
To view keys and certificates, use the following commands in EXEC mode:
View your router's RSA public keys.
View a list of all the RSA public keys stored on your router. These include the public keys of peers who have sent your router their certificates during peer authentication for IPSec.
show crypto key pubkey-chain rsa [name key-name | address key-address]
View details of a particular RSA public key stored on your router.
View information about your certificate, the CA's certificate, and any RA certificates.
After you are done configuring this feature, you should configure IKE and IPSec. IKE configuration is described in the "Configuring Internet Key Exchange Security Protocol" chapter. IPSec configuration is described in the "Configuring IPSec Network Security" chapter.
The following configuration is for a router named "myrouter." In this example IPSec is configured and the IKE protocol and CA interoperability are configured in support of IPSec.
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.
! version 11.3 no service password-encryption service udp-small-servers service tcp-small-servers ! ! CA interoperability requires you to configure your router's hostname: hostname myrouter ! enable secret 5 <removed> enable password <removed> ! ! CA interoperability requires you to configure your router's IP domain name: ip domain-name domain.com ip name-server 172.29.2.132 ip name-server 192.168.30.32 ! ! The following configures a transform set (part of IPSec configuration): crypto ipsec transform-set my-transformset esp-des esp-sha-hmac ! ! The following declares the CA. (In this example, the CA does not support an RA.) crypto ca identity domain.com enrollment url http://ca_server ! ! The following shows the certificates and CRLs stored at the router, including ! the CA certificate (shown first), the router's certificate (shown next) ! and a CRL (shown last). crypto ca certificate chain domain.com ! The following is the CA certificate ! received via the `crypto ca authenticate' command: certificate ca 3051DF7169BEE31B821DFE4B3A338E5F 30820182 3082012C A0030201 02021030 51DF7169 BEE31B82 1DFE4B3A 338E5F30 0D06092A 864886F7 0D010104 05003042 31163014 06035504 0A130D43 6973636F 20537973 74656D73 3110300E 06035504 0B130744 65767465 73743116 30140603 55040313 0D434953 434F4341 2D554C54 5241301E 170D3937 31323032 30313036 32385A17 0D393831 32303230 31303632 385A3042 31163014 06035504 0A130D43 6973636F 20537973 74656D73 3110300E 06035504 0B130744 65767465 73743116 30140603 55040313 0D434953 434F4341 2D554C54 5241305C 300D0609 2A864886 F70D0101 01050003 4B003048 024100C1 B69D7BF6 34E4EE28 A84E0DC6 FCA4DEA8 04D89E50 C5EBE862 39D51890 D0D4B732 678BDBF2 80801430 E5E56E7C C126E2DD DBE9695A DF8E5BA7 E67BAE87 29375302 03010001 300D0609 2A864886 F70D0101 04050003 410035AA 82B5A406 32489413 A7FF9A9A E349E5B4 74615E05 058BA3CE 7C5F00B4 019552A5 E892D2A3 86763A1F 2852297F C68EECE1 F41E9A7B 2F38D02A B1D2F817 3F7B quit ! The following is the router's certificate ! received via the `crypto ca enroll' command: certificate 7D28D4659D22C49134B3D1A0C2C9C8FC 308201A6 30820150 A0030201 0202107D 28D4659D 22C49134 B3D1A0C2 C9C8FC30 0D06092A 864886F7 0D010104 05003042 31163014 06035504 0A130D43 6973636F 20537973 74656D73 3110300E 06035504 0B130744 65767465 73743116 30140603 55040313 0D434953 434F4341 2D554C54 5241301E 170D3938 30343234 30303030 30305A17 0D393930 34323432 33353935 395A302F 311D301B 06092A86 4886F70D 01090216 0E73636F 742E6369 73636F2E 636F6D31 0E300C06 03550405 13053137 41464230 5C300D06 092A8648 86F70D01 01010500 034B0030 48024100 A207ED75 DE8A9BC4 980958B7 28ADF562 1371D043 1FC93C24 8E9F8384 4D1A2407 60CBD7EC B15BD782 A687CA49 883369BE B35A4219 8FE742B0 91CF76EE 07EC9E69 02030100 01A33530 33300B06 03551D0F 04040302 05A03019 0603551D 11041230 10820E73 636F742E 63697363 6F2E636F 6D300906 03551D13 04023000 300D0609 2A864886 F70D0101 04050003 410085F8 A5AFA907 B38731A5 0195D921 D8C45EFD B6082C28 04A88CEC E9EC6927 F24874E4 30C4D7E2 2686E0B5 77F197E4 F82A8BA2 1E03944D 286B661F 0305DF5F 3CE7 quit ! The following is a CRL received by the router (via the router's own action): crl 3081C530 71300D06 092A8648 86F70D01 01020500 30423116 30140603 55040A13 0D436973 636F2053 79737465 6D733110 300E0603 55040B13 07446576 74657374 31163014 06035504 03130D43 4953434F 43412D55 4C545241 170D3938 30333233 32333232 31305A17 0D393930 34323230 30303030 305A300D 06092A86 4886F70D 01010205 00034100 7AA83057 AC5E5C65 B9812549 37F11B7B 5CA4CAED 830B3955 A4DDD268 F567E29A E4B34691 C2162BD1 0540D7E6 5D6650D1 81DBBF1D 788F1DAC BBF761B2 81FCC0F1 quit ! ! The following is an IPSec crypto map (part of IPSec configuration): crypto map map-to-remotesite 10 ipsec-isakmp set peer 172.21.114.196 set transform-set my-transformset match address 124 ! ! interface Loopback0 ip address 10.0.0.1 255.0.0.0 ! interface Tunnel0 ip address 10.0.0.2 255.0.0.0 ip mtu 1490 no ip route-cache no ip mroute-cache tunnel source 10.10.0.1 tunnel destination 172.21.115.119 ! interface FastEthernet0/0 ip address 172.21.115.118 255.255.255.240 no ip mroute-cache loopback no keepalive shutdown media-type MII full-duplex ! ! The IPSec crypto map is applied to interface Ethernet1/0: interface Ethernet1/0 ip address 172.21.114.197 255.255.255.0 bandwidth 128 no keepalive no fair-queue no cdp enable crypto map map-to-remotesite ! crypto isakmp policy 15 encryption des hash md5 authentication rsa-sig group 2 lifetime 5000 crypto isakmp policy 20 authentication pre-share lifetime 10000 crypto isakmp key 1234567890 address 22.214.171.124