Configuring Cisco IOS IPSec Certificate Authority Support Site-to-Site

Managing the RSA Keys

To keep your system clean, it’s crucial to remove keys that are no longer valid. To spruce things up, get into public key chain configuration mode and issue the no form of either the addressedkey command or the named-key command.

It’s nice that those last three steps in this process are pretty much identical to those for configuring pre-shared keys, huh?

Configuring IKE Using RSA-Encrypted Nonces

You’re going to configure IKE almost exactly the same way as you did for pre-shared keys. The one exception is the authentication method. Instead of entering the authentication pre-shared command, you enter the authentication rsa-encr command. Verify that the IKE policy works the same way using the same commands you used earlier.

Configuring IPSec for RSA-Encrypted Nonces

IPSec for RSA-encrypted nonces is configured in the same exact way as IPSec utilizing preshared keys—no exceptions. For a refresher on configuring IPSec, refer back to the section titled “Configure IPSec” earlier in this chapter.

Testing and Verifying IPSec for RSA-Encrypted Nonces

And lastly, to verify IPSec for RSA-encrypted nonces, you use the same commands you used in the “Testing and Verifying IPSec” section earlier in this chapter, along with the show commands described in this section.

Configuring Cisco IOS IPSec Certificate

Authority Support Site-to-Site

IPSec for CA is the most scalable of all IPSec implementations because it allows a device to receive a digital certificate from a CA server that it uses to identify itself for IPSec peering.

This section describes all the steps you’ll need to learn how to configure IPSec for CA.

Configuring CA Support Tasks

To configuring IPSec for CA, you must complete these five tasks:

268 Chapter 8 Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support

When you find yourself at the end of this section, you’ll be able to implement site-to-site IPSec for CA. Did you notice that some of these tasks overlap with the ones described previously in IPSec for pre-shared keys? Well, sometimes the ball really does bounce your way—I’m only going to touch on the overlapping ones briefly.

Preparing for IKE and IPSec

Once again, you need to answer those questions back in the “Preparing for IKE and IPSec” section of this chapter, but this time, you get two additional questions to ponder:

Which CA server are you going to use? You need to determine that in order to assign your certificate.

Do you need to use trusted root CA servers? You need to configure them if you intend to peer with devices that aren’t using the same CA server as you are.

Configuring CA Support

Remember back a bit when I suggested taking that break? Did you take it? If so, you’re good to go. If not—ummmm…well, live and learn. This step is actually the greatest departure from the method used in configuring IPSec utilizing pre-shared keys; there’s lots of new stuff to learn in this section. If you want to configure CA support, you’ve got to successfully complete each of the following nine steps:

1.Manage NVRAM memory usage.

2.Configure the device’s hostname and domain name.

3.Generate the RSA public/private keys.

4.Declare a CA.

5.Configure a root CA (trusted root).

6.Authenticate the CA.

7.Request the device’s certificate.

8.Verify CA interoperability.

9.Save your configurations.

Managing NVRAM Memory Usage

Certificates are stored locally on a device—something that usually won’t give you any memoryrelated grief. But it can, so if you think your situation warrants it or if you just don’t want to take any chances, enter the following command in global configuration mode:

crypto ca certificate query

Doing this ensures that the device retrieves certificates from the CA server only when needed.

Some ugly issues can arise when retrieving certificates if the CA server is down, so be sure the certificate server is up and running before performing your query.

Configuring the Device’s Hostname and Domain Name for CA

I’m not going to go over this step again because you do it the exact same way as you did for RSA-encrypted nonces. If you need a review, refer to the section “Configuring the Device’s Hostname and Domain Name for RSA-Encrypted Nonces” earlier in this chapter.

Generating the RSA Public/Private Keys Manually for CA

This step is also accomplished the same way as it was for RSA-encrypted nonces, so refer back to the “Generating the RSA Public/Private Keys Manually for RSA-Encrypted Nonces” section earlier in this chapter if you need a review.

Declaring a CA

Okay, let’s move on. In order for CA to operate, you must first designate a CA server that you’ll request your certificates from. Let’s define a few terms before diving into configuration:

Simple Certificate Enrollment Protocol (SCEP) Simple Certificate Enrollment Protocol (SCEP) is a CA interoperability protocol that permits compliant IPSec peers and CAs to communicate so that the IPSec peer can obtain and use digital certificates from the CA.

Certificate revocation lists (CRL) Certificate revocation lists (CRL) are lists of certificates that have been revoked and are no longer valid. IPSec peers can obtain the CRL from the CA server and should check the CRL every time an IPSec peer attempts to establish a new IKE SA.

Registration authority (RA) A registration authority (RA) is a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.

Now that you’re clear on these terms, you ready to start configuring.

All people name their kids, most people name their dogs, and some people even name their cars. You will name your CA. This first step for declaring your CA is done by entering the following command in global configuration mode, where name is the name you will use to refer to the CA:

crypto ca identity name

Entering this command places the device in ca-identity configuration mode where you can spell out the CA-specific information such as the enrollment URL.

270 Chapter 8 Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support

Which is what you’re going to do next: enter the URL of your CA. This is the address to which the router will send certificate requests. To configure the enrollment URL, enter the following command in ca-identity configuration mode, where url is the URL to which the certificate requests will be sent:

enrollment url url

If the CA server you are communicating with provides an RA, you need to enable enrollment RA support by entering the following command in ca-identity configuration mode:

enrollment mode ra

Each of the next four commands will also be entered in this mode.

If your CA server provides an RA and supports Lightweight Directory Access Protocol (LDAP), and your CA server supports both RA and LDAP, you’ll need to specify a URL to query. To specify a URL to query, enter the following command, where url is the LDAP URL to query for retrieving certificates:

query url url

By default, a device requires that an IPSec peer’s certificate be checked against the appropriate CRL before accepting the certificate. Sometimes a device won’t be able to obtain the CRL, and when that happens, it responds by rejecting the IPSec peer. To avoid this snag, use the following command:

crl optional

By default, devices send the CA server certificate requests every minute until they receive a valid certificate in return. You can change this default behavior with the following command, where minutes is a value between 1 and 60:

enrollment retry period minutes

Devices also send CA server certificate requests until they receive a valid certificate back— something you’d probably love some control over. Good news: You can limit the number of times a device will request the certificate via this command, where number is a value between 1 and 100:

enrollment retry count number

That’s all, folks—you’ve now successfully declared your CA server. But before moving on, let’s take a look at how this works.

In the following example, device Lab_A is configured to declare a CA that is creatively dubbed test_ca. The enrollment URL is http://ca_server. The CA doesn’t support RA or LDAP, and the device is configured to ignore the CRL if one can’t be found:

Lab_A#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Lab_A(config)#crypto ca identity test_ca

Lab_A(ca-identity)#enrollment url http://ca_server

Lab_A(ca-identity)#crl optional

Lab_A(ca-identity)#^Z

Lab_A#

Configuring a Root CA (Trusted Root)

A trusted root CA is the aptly named CA server that devices will trust certificates from even if those devices aren’t enrolled with that CA. This is important to point out because you need to know that an IPSec peer may be enrolled with a different CA server than your device.

Like I said, the first thing you need to do is come up with a name you’ll use to refer to your trusted root CA. Do this by entering the following command in global configuration mode, where name is the name you’ll use for the trusted root CA:

crypto ca trusted-root name

When you enter the preceding command, you put the device into trusted root configuration mode—the place from which you’ll specify the trusted root–specific information such as the URL that trusted root certificates will be received from.

Once your trusted root has its name squared away, you need to decide if the device will use the SCEP protocol or the TFTP protocol to query the trusted root CA. If the SCEP protocol is your winner, enter this command in trusted root configuration mode, where url is the URL of the trusted root CA:

root CEP url

The next three commands are all issued from within the trusted root configuration mode.

If you want to use the TFTP protocol, use the following command instead, where url is the URL of the trusted root CA:

root TFTP url

If the trusted root CA is utilizing an HTTP proxy server, you need to define the URL of the proxy server with the following command, where url is the URL of the trusted root CA proxy server:

root PROXY url

You also get an option to indicate the URL to query using LDAP for CRLs from the trusted root server. To make this your reality, use the following command, where ldap-url is the LDAP URL to use for querying:

crl query ldap-url

With your CA server declared and everything, including your trusted root servers configured so nicely, it’s time to move on to authentication.

272 Chapter 8 Cisco IOS IPSec Pre-Shared Keys and Certificate Authority Support

Authenticating the CA

You have finally arrived—Easy Street, baby! Yes, it’s true that you still have to authenticate those declared and trusted root CA servers, but doing that is a day at the beach! You need only one command to authenticate a CA server. From within global configuration mode, enter the following command, where name is the name you used for the CA server:

crypto ca authenticate name

Once your CA server is authenticated, it receives the public key of the CA server. After you’ve entered the preceding command, the device asks if you accept the certificate, to which you reply either yes or no. Here’s an example of authenticating the CA server declared on device Lab_A:

Lab_A#conf t

Enter configuration commands, one per line. End with CNTL/Z. Lab_A(config)#crypto ca authenticate test_ca

Certificate has the following attributes:

Fingerprint: 0123 4567 89AB CDEF 0123

Do you accept this certificate? [yes/no]#y

Lab_A(config)#

Requesting the Device’s Certificate

After authenticating the CA, a device needs to request its own certificate from the CA server. To request a certificate, enter the following command in global configuration mode, where name is the name you used for the CA server:

crypto ca enroll name

Entering the preceding command starts the inquisition—you’re then asked a number of questions, as you can see in the following output:

Lab_A#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Lab_A(config)#crypto ca enroll test_ca

%

%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: cisco

Re-enter password: cisco