http://fengnet.com/book/vpnconf/ch16lev1sec3.html
Digital Certificates and Router Enrollment
Unlike symmetric or asymmetric (RSA encrypted nonces) pre-shared keys, digital certificate information is not pre-shared with other peers. Like RSA encrypted nonces, a private key is used to create authentication information (signature) and a public key is used to verify the signature; however, this information is located on a certificate and is not pre-shared with a peer. Thus, digital certificates scale better than either of the two pre-shared methods.
In this section I'll discuss the use of certificates on routers and how they're used for authentication. The first two sections will discuss how to obtain a certificate with SCEP (in-band) and manually (out-of-band). Following this, I'll discuss how to export and import certificate and keying information for backup and redundancy purposes.
Enrolling for a Certificate using SCEP
Between manual enrollment and the Simple Certificate Enrollment Protocol (SCEP), SCEP is used most often to set up certificate services on a router. To use SCEP, though, your router cannot use public keys greater than 2,048 bits and you must use ISAKMP/IKE and IPsec to set up the management and data connections dynamically.
No matter whether you're using SCEP or the manual approach, typically you'll go through the following steps to get certificates on a router:
Step 1. | Verify that certificates can fit into NVRAM (optional). |
Step 2. | Configure a host name and domain name (required). |
Step 3. | Generate an RSA key pair (required). |
Step 4. | Define a Certificate Authority or CA (required). |
Step 5. | Download and authenticate the CA's certificate (required). |
Step 6. | Request the router's identity certificate (required). |
Step 7. | Save the CA and identity certificates (required). |
Step 8. | Verify the certificate operation (optional). |
The following subsections will discuss each of these tasks.
Step 1: Verify that Certificates Can Fit into NVRAM
When using certificates for device authentication, the following information is, by default, stored in NVRAM of the router: the router's identity certificate, the router's private and public keys used to create and validate the signature on the router's PKCS #10 information, the CA's certificate, root certificates obtained from the CA, if any, two Registration Authority (RA) certificates, if the CA supports an RA, and one or more CRLs.
Note
Use the show running-config command to determine how much NVRAM your router is currently using.
Because this can represent a large amount of information, NVRAM might be too small to store this information, which is possible on smaller, older router models. If this is the case, you have the option of having the router download this information from the CA with the exception of the following information: the router's public and private keys and the signature on the CA certificatethis information will be stored locally in NVRAM and all other certificate information will be downloaded to the router when it boots up and will be stored in RAM. This process is called query mode. To turn on the query mode of the router, use this command:
Router(config)# crypto ca certificate query
To turn off query mode later, use the no crypto ca certificate query after the router has downloaded all certificate information and then execute copy running-config startup-config to save the downloaded certificate information to NVRAM. If you currently are not using query mode and want to enable it, use the above command to remove all certificate information stored in NVRAM and then save the router's configuration (copy running config startup-config).
Note
Using the query method affects the performance of the router because it must download the certificate information before the router can establish IPsec tunnels. Also, this means that if the CA is not reachable, the router will not be able to download the certificate information and thus will not be able to build IPsec tunnels.
Steps 2 and 3: Names and RSA Key Pairs
A private key is needed on the router to generate the signature for the router's identity information (PKCS #10) and a public key is necessary to validate the signature for the PKCS #10 information. I've already discussed this configuration in the "Generating RSA Encrypted Nonces (Key Pairs)" section, where you use the hostname command to assign a name to the router, the ip domain-name command to assign a domain name, and the crypto key generate rsa command to create the router's public/private keys. Remember that if you want to create a separate RSA key pair for this certificate compared to other certificates your router has, you'll need to add a key pair label to the end of the command (see the "Multiple RSA Key Pairs" section earlier).
Step 4: Define a CA
Once you have generated your RSA key pair, you can then define the CA your router will be using for IPsec device authentication. This is done with the commands shown in the following code listing:
Router(config)# crypto {ca | pki} trustpoint CA_name
Router(ca-trustpoint)# enrollment url CA_URL
Router(ca-trustpoint)# enrollment http-proxy proxy_IP_address
proxy_port_#
Router(ca-trustpoint)# enrollment mode ra
Router(ca-trustpoint)# enrollment retry period minutes
Router(ca-trustpoint)# enrollment retry count number
Router(ca-trustpoint)# crl {query URL | optional}
Router(ca-trustpoint)# ocsp url OCSP_server_URL
Router(ca-trustpoint)# revocation-check method1 [method2 [method3]]
Router(ca-trustpoint)# query certificate
Router(ca-trustpoint)# primary
Router(ca-trustpoint)# source interface name_and_number_of_interface
Router(ca-trustpoint)# default command
Router(ca-trustpoint)# exit
The crypto ca trustpoint specifies CA properties to use to interact with the CA: you can use either the ca or pki parameter to signify the configuration type. The CA_name you specify is typically the FQDN of the CAyour CA administrator will give you this value. When executing this command, you are taken into a subcommand mode where you can enter the properties for interacting with the CA.
The enrollment url command specifies the URL to interact with the CA when requesting certificates; again, your CA administrator will give you this information. These are the only two required commands to interact with the CA; the remaining commands are optional. If your CA is behind a web proxy, you'll need to configure your router to interact with the proxy with the enrollment http-proxy command, specifying the IP address (or FQDN) of the proxy and the port number to use when contacting the proxy.
The enrollment mode ra command specifies whether or not the CA provides for an RA(s); you don't need to configure this command because IOS routers will determine automatically whether the CA is using an RA(s) or not. If the router determines that RAs are being used, this command will appear automatically in the router's configuration.
The enrollment retry period command specifies the length of time that the router will wait for a certificate from the CA before requesting it again. The default is one minute. The enrollment retry count command specifies how many times the router will continue contacting the CA for a certificate request before giving up; the default configuration specifies that the router will try continually without ever giving up.
Note
If your CA is an IOS router CA, the URL you specify in the enrollment url command needs to be as follows: enrollment url http://IP_address_or_FQDN_of_router_CA; no CGI-BIN script or additional information is necessary. For more information on using a router as a CA, see the "Routers as Certificate Authorities" section later in the chapter.
The crl command specifies configuration options for using CRLs. The query parameter specifies an LDAP or HTTP server where the CRL is located and is in the format of "{ldap|http}://IP_address/other_URL_info." The optional parameter specifies that CRLs might or might not be used by your CA and thus your router will accept a peer's certificate if a CRL cannot be located. If you know that your CA uses CRLs, don't configure this command; otherwise you inadvertently might use a revoked certificate, because CRL checking is optional with this command enabled.
The Online Certificate Status Protocol (OCSP) allows devices to use this process, instead of CRLs, to check the status of certificates. This feature is new in IOS 12.3(2)T. OCSP has a few advantages over CRLs. First, it runs across HTTP instead of the possibility of LDAP; second, it provides more frequent updates to the edge devices than CRLs provide (CRLs do this only periodically); and third, OCSP allows you to configure a central OCSP server to collect and update CRLs from multiple CAs, simplifying and speeding up the CRL checking process by an edge device.
The ocsp url command specifies the OCSP's location of revoked certificates; if the CA's certificate has this location already on it and you configure the ocsp url command, the configured command overrides the information on the CA's certificate. The revocation-check command specifies the method or order of methods to use to check the revocation status of a certificate. There are three defined method parameters: crl, ocsp, and none. crl specifies that certificate checking is performed by a CRLthis is the default option; oscp specifies that checking is performed by an OCSP server; and none specifies that no certificate checking is performed (this command replaces the crl optional command in the latest IOS releases).
The query certificate command specifies that any certificate information for this particular trustpoint is not stored in NVRAMthe advantage of this command over the crypto ca certificate query command is that the latter is global and affects all CAs defined on the router, whereas the former affects only the current trustpoint's configuration. The primary command specifies that this particular trustpoint is assigned the primary CA role on the router; this command is necessary only if you have more than one CA configured and you want one to be the primary one. The source interface command, new in IOS 12.2(15)T, specifies the source interface to use for traffic to be sent to the CA. This command typically is used when the exit interface of the router has a private (or IP address, but the router does have another interface with a public address and wants this address to be used. If you omit this command, the router uses the interface chosen based on its routing table selection.
The default command, followed by another trustpoint command, sets the specified trustpoint command back to the default value. This is useful if you want to undo a trustpoint configuration command. Other optional commands can be configured under the trustpoint (in the trustpoint subcommand mode), however, I'll discuss these in later sections.
Note
In IOS versions before 12.2(8)T, the command to specify the CA is crypto ca identity; this has be supplanted by the crypto ca trustpoint command. This is also true of the crypto ca trusted-root, which allows you to specify a root CA in a hierarchical CA setup.
Step 5: Download and Authenticate the CA's Certificate
Once you have defined the interaction between the router and the CA, you are ready to download and authenticate the CA's self-signed certificate by using this command:
Router(config)# crypto {ca | pki} authenticate CA_name
You need to configure the same CA name that you configured in the crypto ca trustpoint command in the last section. Example 16-10 illustrates this process. The name of the CA is "caserver." Upon downloading the CA certificate, you'll be prompted to accept it; before accepting it, first validate the CA's signature on the self-signed certificate. It's important that you do this, because this is the weakest link in the security process of using certificates. At this point, a man-in-the-middle attack could be occurring and you could be receiving a hostile or invalid CA certificate.
Example 16-10. Downloading and Authenticating the CA's Certificate
r3640(config)# crypto ca authenticate caserver
Certificate has the following attributes:
Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47
Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Step 6: Request the Router's Identity Certificate
Before you can request the router's identity certificate, first you must have downloaded and verified the CA's certificate in Step 5. This is necessary so that the router can use the CA certificate to validate any certificate received (from the same CA's domain), including the router's own identity certificate. Likewise, you already must have generated an RSA key pair which is used to sign and verify the identity certificate request. When you have completed these steps, you are now ready to create the PKCS #10 information that will be sent to the CA, via SCEP, with this command:
Router(config)# crypto {ca | pki} enroll CA_name
The CA name you list must be the same name configured in the crypto ca authenticate and crypto ca trustpoint commands. First you'll be prompted for a challenge password. This password serves two purposes: it is used by the CA to control who can request a new certificate and by the CA administrator to revoke a valid certificate. You also have the option of including the router's serial number or IP address in the identity certificate. Once you answer yes to request a certificate, the router puts together the PKCS #10 information and sends this to the CA via HTTP. Once the request has been approved and the identity certificate generated, your router will download the identity certificate automatically. Example 16-11 illustrates how to use SCEP to request an identity certificate for your router.
Example 16-11. Obtaining the Router's Identity Certificate
r3640(config)# crypto ca enroll caserver
% 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: cisco123abc
Re-enter password: cisco123abc
% The fully-qualified domain name in the certificate will be:
r3640.cisco.com
% The subject name in the certificate will be: r3640.cisco.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto pki certificate' command will also show the
fingerprint.
05:32:29: CRYPTO_PKI: Certificate Request Fingerprint MD5:
F9A3574C 09BAC68D 491D0FDA 1EBCE0BC
05:32:29: CRYPTO_PKI: Certificate Request Fingerprint SHA1:
898BDC0B 69F74320 8EECF1FF FD86503F 3DC366BB
05:32:34: %PKI-6-CERTRET: Certificate received from Certificate
Authority
Step 7: Save the CA and Identity Certificates
Assuming you have enough NVRAM to store your router's certificate components, the last step is to save these components to NVRAM with the copy running-config startup-config command. If the router reboots before the requested identity certificate was installed and saved, you'll need to re-execute the crypto ca enroll command; the same is true for downloading and authenticating the CA certificate: crypto ca authenticate. Both of these commands are not saved in the router's NVRAM.
Step 8: Verify the Certificate Operation
Once you have an identity certificate on the router, the last step is to verify the certificate operation process. To view the CA or CAs you have configured on your router, use the show crypto {ca | pki} trustpoint. The output of this command, shown in Example 16-12, displays some of the information found on the CA certificate, in addition to how the trustpoint is configured on the router.
Example 16-12. The show cyrpto ca trustpoints Command
r3640# show crypto ca trustpoints
Trustpoint caserver:
Subject Name:
cn=caserver
c=US
Serial Number: 6EBD53BA55C2D29841E0A0D48E40CF96
Certificate configured.
SCEP URL: http://192.1.1.77:80/certsrv/mscep/mscep.dll
To view any certificates the router has, use the show crypto {ca | pki} certificates command, shown in Example 16-13. The first certificate is the router's identity certificate and the second one is the CA's.
Example 16-13. The show crypto ca certificates Command
r3640# show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 11320A3500010000001A
Certificate Usage: General Purpose
Issuer:
cn=caserver
c=US
Subject:
Name: r3640.cisco.com
hostname=r3640.cisco.com
CRL Distribution Points:
http://i7500/CertEnroll/caserver(1).crl
Validity Date:
start date: 03:41:05 UTC Feb 26 2005
end date: 03:51:05 UTC Feb 26 2006
Associated Trustpoints: caserver
CA Certificate
Status: Available
Certificate Serial Number: 6EBD53BA55C2D29841E0A0D48E40CF96
Certificate Usage: Signature
Issuer:
cn=caserver
c=US
Subject:
cn=caserver
c=USoutput omitted
Router(config)# crypto ca crl request CA_name
Be sure to use the name of the CA configured in the crypto ca trustpoint command when requesting the current CRL. This command typically is used if certificates have been revoked on the CA, but you suspect your router doesn't have the most up-to-date CRL. To view the status of the CRL, use the show crypto {ca | pki} crls command; an example of this is shown in Example 16-14.
Example 16-14. The show crypto ca crls Command
r3640# show crypto ca crls
CRL Issuer Name:
cn=caserver,c=US
LastUpdate: 01:18:27 UTC Feb 25 2005
NextUpdate: 13:38:27 UTC Mar 4 2005
Retrieved from CRL Distribution Point:
http://i7500/CertEnroll/caserver(1).crl
Tip
You can use the debug crypto pki command to troubleshoot problems related to the request and use of certificates.
Deleting Certificates
- You need to generate an RSA key pair with a longer (or shorter) modulus.
- Your current certificate has expired.
- Your private key has been compromised.
- You no longer are using the certificate for authentication functions.
To delete a certificate, such as your router's identity certificate, first view the certificate with the show crypto ca certificates command and look for the serial number of the certificate to be revoked. Then execute the following two commands:
Router(config)# crypto ca certificate chain CA_name
Router(config-cert-cha)# no certificate certificate-serial-number
With the first command, you must specify the name of the trustpoint configured in the crypto ca trustpoint command. This takes you into a subcommand mode where you remove the certificate by specifying the serial number of the certificate to be deleted with the no certificatecommand.
Once a certificate is deleted, you can remove its associated RSA key pair with the crypto key zeroize rsa command, discussed earlier in the "Removing RSA Keys" section. Also, if you no longer will be using certificates for authentication functions and wish to remove all certificate information on your router, use the following command:
Router(config)# no crypto ca trustpoint CA_name
This command allows you to remove not only the configuration of the trustpoint (the associated trustpoint commands), but the CA certificate, any RA certificates, any CRLs, and the router's identity certificate(s).
Enrolling for a Certificate Manually
If your CA doesn't support or use SCEP, you'll need to obtain certificates for your router using manual enrollment. Manual enrollment can be accomplished using TFTP or cut-and-paste if you're running IOS 12.2(13)T or later.
Note
Cisco doesn't recommend using SCEP to obtain one certificate and TFTP or cut-and-paste to obtain the other certificate when retrieving the CA and identity certificates; this might create problems when trying to retrieve the second certificate from the CA.
Configuring Manual Enrollment Using TFTP
Configuring manual enrollment using TFTP is very similar to configuring certificate enrollment using SCEP: you'll need to go through the same eight steps discussed in the "Enrolling for a Certificate using SCEP" section. However, there are obviously a few differences. Steps 13 are the same: verify NVRAM usage, configure the router's host and domain names, and generate the RSA keys.
Step 4, defining a CA, is slightly different. First, make sure the router can reach a TFTP server and has write access to the TFTP server's directory structure. Next, configure the trustpoint with the crypto ca trustpoint command. This command was discussed previously in the "Step 4: Define a CA" section. The main difference is the enrollment url command, which needs to specify a URL with a TFTP file type and the location of the TFTP server:
Router(config)# crypto ca trustpoint CA_name
Router(ca-trustpoint)# enrollment url
tftp://server_name_or_address/file_name
For example, you might enter something like enrollment url tftp://caserver/directory/cacert. In most cases, the TFTP server will be the same device that's the CA if you're setting up your own CA. Otherwise, you'll use a local TFTP server. The file specified is the CA's certificate and must be in a base-64 encoding scheme. Also, the router will append ".ca" as an extension to the file name; so in this example, the file on the tftp server is "cacert.ca." If you omit a file name, the name will default to the router's FQDN plus the ".ca" extension, like "r3640.cisco.com.ca." The other trustpoint commands discussed previously in the "Step 4: Define a CA" section also can be configured as necessary.
Next, perform Step 5 as discussed previously in the "Step 5: Download and Authenticate the CA's Certificate" section by executing the crypto ca authenticate command to download and authenticate the CA's certificate (from the TFTP server). You'll need to verify the CA's signature and accept it if valid.
Following this, request the router's certificate by executing the crypto ca enroll command, discussed previously in the "Step 6: Request the Router's Identity Certificate" section. In this case, the command creates the router's PKCS #10 information and sends it to the TFTP server, whichExample 16-15 illustrates. The name of the file on the TFTP server will be the file name listed in the enrollment url command followed by ".req" as an extension, as you can see from Example 16-15. Give this file to the CA administrator, which then will be used by the CA to create an identity certificate for your router.
Example 16-15. Sending the Router's PKCS #10 Information to the TFTP Server
r3640(config)# crypto ca enroll caserver
% Start certificate enrollment ..
% The fully-qualified domain name in the certificate will be:
r3640.cisco.com
% The subject name in the certificate will be: r3640.cisco.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Send Certificate Request to file system? [yes/no]: yes
% Certificate request sent to file system
% The certificate request fingerprint will be displayed.
% The 'show crypto pki certificate' command will also show the
fingerprint.
!Writing file to tftp://192.1.1.77/cacert.req!
09:20:42: CRYPTO_PKI: Certificate Request Fingerprint MD5: E5CC32D1
AB29F816 94BC76A8 ADC525EE
09:20:42: CRYPTO_PKI: Certificate Request Fingerprint SHA1: A5006A64
5E0BA531 97878ED0 A84AA3A8 8F6B9C82
Once the CA administrator has generated an identity certificate for your router, it needs to be saved with a ".crt" extension and with the same filename specified in the enrollment url command. This file must be stored in a base-64 encoding scheme (PKCS #10) as the CA certificate was previously, and placed in the same directory on the TFTP server as the CA's certificate. Then you can import the identity certificate with the crypto ca import command:
Router(config)# crypto ca import CA_name certificate
You must specify the name of the CA configured as a trustpoint with the crypto ca trustpoint command. Example 16-16 illustrates the use of this command. As you can see in this example, the router's identity certificate is named "cacert.crt" on the TFTP server.
Example 16-16. Importing the Router's Identity Certificate via TFTP
r3640(config)# crypto ca import caserver certificate
% The fully-qualified domain name in the certificate will be:
r3640.cisco.com
Retrieve Certificate from file system? [yes/no]: yes
% Request to retrieve Certificate queued
Reading file from tftp://192.1.1.77/cacert.crt
Loading cacert.crt from 192.1.1.77 (via Ethernet0/0): !
[OK - 1118 bytes]
09:31:07: %PKI-6-CERTRET: Certificate received from Certificate
Authority
Tip
Because of naming complications on multiple routers, I recommend that you have a separate certificate directory on the TFTP server for each router. This reduces the likelihood of another router pulling in your certificate, since there is no authentication or access control with TFTP. Plus, the same file name is used for the CA and identity certificate, like "caserver"; what's unique is the extension: ".ca" for the CA certificate and ".crt" for the identity certificate.
Finally, save your router's certificate information with the copy running-config startup-config command, view the trustpoint with the show crypto ca trustpoint command, and view your router's certificate information with the show crypto ca certificates command (steps 7 and 8).
Configuring Manual Enrollment Using Cut-and-Paste
If using SCEP and a TFTP server is not an option, you can use the old-fashioned copy-and-paste process with manual enrollment. Steps 13 are the same as the other two processes for obtaining a certificate. Step 4, defining a CA, is slightly different than the other two, however. As with the other two, configure the trustpoint with the crypto ca trustpoint command. This command was discussed previously in the "Step 4: Define a CA" section. The main difference is the enrollment terminal command, which specifies that cut-and-paste will be used to obtain the CA's certificate.
Router(config)# crypto ca trustpoint CA_name
Router(ca-trustpoint)# enrollment terminal
The other trustpoint commands discussed previously in the "Step 4: Define a CA" section can also be configured as necessary.
Once you have defined the CA, in Step 5 you'll execute the crypto ca authenticate command to obtain the CA's certificate. In the other two processes, this was achieved using SCEP or TFTP. With cut-and-paste, you'll need to open the file the CA administrator gave you containing the CA's certificate, copy the contents including the beginning and ending lines starting with the dashes ("-----"), and paste it into the router's configuration when prompted. Example 16-17 illustrates this process. Once you have pasted the CA certificate into the router, type in quit on a blank line to terminate the cut-and-paste process and to have the router import the CA's certificate.
Example 16-17. Importing the CA's Certificate with Cut-and-Paste
r3640(config)# crypto ca authenticate caserver
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIIChTCCAe6gAwIBAgIQbr1TulXC0phB4KDUjkDPljANBgkqhkiG9w0BAQUFADAg
MQswCQYDVQQGEwJVUzERMA8GA1UEAxMIY2FzZXJ2ZXIwHhcNMDQwMTE2MDc0MjAw
BX3p1Wxz+tSEQwrChIzbHcFAUP1Gq0dpBQ==
-----END CERTIFICATE-----
quit
Certificate has the following attributes:
Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47
Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
Next, you need to create your PKCS #10 information for your router's identity certificate with the crypto ca enroll command, as shown in Example 16-18. The execution of this command is similar to the other two processes; however, you have the option of displaying the PKCS #10 information to the router's terminal screen, which you want to answer yes. At the line that states Certificate Request follows, select the information here, copy it, store it in a file, and send it to the administrator of the CA, who will use it to create an identity certificate for your router.
Example 16-18. Creating the Router's PKCS #10 Information for the Cut-and-Paste Process
r3640(config)# crypto ca enroll caserver
% Start certificate enrollment ..
% The fully-qualified domain name in the certificate will be:
r3640.cisco.com
% The subject name in the certificate will be: r3640.cisco.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
MIH7MIGmAgEAMCAxHjAcBgkqhkiG9w0BCQIWD3IzNjQwLmNpc2NvLmNvbTBcMA0G
CSqGSIb3DQEBAQUAA0sAMEgCQQCobLU/S3ExRpMEJrkDLGMxHInlrwH33C7PpLli
hehmSFlWgTx1GSTTAxVkQdpYJ09NQ76CFGQ6Bpi7BDCI8hZrAgMBAAGgITAfBgkq
hkiG9w0BCQ4xEjAQMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQQFAANBACNW
JHzO5brezlfI4db5RdLjgh7Wd5zmv84gfQwxtL0GPXJ0SRzK4/1L6le15jefrEu2
Tkag3YiQUZURfJB1smA=
---End - This line not part of the certificate request---
Redisplay enrollment request? [yes/no]: no
r3640(config)#
Once the administrator has created a certificate for your router and sent this to you, you can then import the certificate into your router using the crypto ca import command discussed in the last section, which is shown in Example 16-19. After pasting in the certificate, on a blank line type in quit, signifying that this is the end of the cut-and-paste process. The router will validate the certificate and import it. And as with the other two certificate enrollment processes, be sure to save your router's certificate and configuration information to NVRAM and view your certificate information to validate it.
Example 16-19. Importing the Router's Identity Certificate Using Cut-and-Paste
r3640(config)# crypto ca import caserver certificate
% The fully-qualified domain name in the certificate will be:
r3640.cisco.com
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIIC/TCCAmagAwIBAgIKEgiafQABAAAAGzANBgkqhkiG9w0BAQUFADAgMQswCQYD
VQQGEwJVUzERMA8GA1UEAxMIY2FzZXJ2ZXIwHhcNMDUwMzE3MDAzNTIyWhcNMDYw
+vtDsziATo59EAjGmV8ofqr+oxpuOCM4cCN0BL3babe70dqtbMYLGyN+p6/K1jqA
-----END CERTIFICATE-----
quit
% Router Certificate successfully imported
Autoenrollment for Certificates
In IOS 12.2(8)T, Cisco introduced the certificate autoenrollment feature, which allows you to set up your router so that it will request a certificate from a CA using the parameters in your configuration, eliminating any type of administrator intervention on the router when requesting a certificate from a CA. This process is triggered when a trustpoint CA has been configured, but a corresponding CA certificate doesn't exist on the router; plus, when the router's certificate expires, the router automatically will request a new certificate as needed. Of course, the administrator of the CA still might need to approve your router's certificate request via autoenrollment; however, you don't have to do anything to initiate the process from the router side.
Autoenrollment Trustpoint Configuration
The configuration of autoenrollment is very similar to the configuration of enrollment for certificates using SCEP. As with SCEP, you need to verify your NVRAM usage, configure a name and domain name on the router, and generate an RSA key pair. Once you've done this, you now need to configure your trustpoint. The commands discussed in the "Enrolling for a Certificate using SCEP" section earlier apply to this configuration, because SCEP is being used; however, there are some additional commands you need to configure, shown here:
Router(config)# crypto ca trustpoint CA_name
Router(ca-trustpoint)# enrollment url CA_URL
Router(ca-trustpoint)# subject-name [x.500_name]
Router(ca-trustpoint)# ip-address
{interface_name_or_IP_address | none}
Router(ca-trustpoint)# serial-number [none]
Router(ca-trustpoint)# password password_value
Router(ca-trustpoint)# rsakeypair key_label [key_size
[encryption_key_size]]
Router(ca-trustpoint)# auto-enroll [regenerate]
The subject-name command specifies the X.500 field values that will appear on the certificate; if you omit this, it defaults to the FQDN of the router only for the Common Name. The ip-address command specifies the IP address or router interface name (which would include that interface's IP address) to be included on the certificate; specify the none parameter if you don't want an IP address on the identity certificate. The serial-number command specifies that the router's serial number should be included in the certificate request; use the none parameter to exclude this from the certificate request. The password command specifies the password to use for revoking passwords, called the challenge password.
The rsakeypair command specifies which RSA key pair to use for the certificate; the key_label parameter specifies the name of an existing key pair or of a new key pair, the key_size parameter specifies the modulus for the signature keys and the encryption_key_size specifies the modulus for the encryption keys. If you omit this command, the FQDN default key pair is used. If you specify the keying information, once autoenrollment starts, if the specified key label doesn't exist, autoenrollment will create the RSA key pair automatically; you can view the new key pair with the show crypto key mypubkey rsa command. For more information on multiple key pairs, see the "Multiple RSA Key Pairs" section earlier.
Note
One thing to note is that if you don't configure a specific value that typically is prompted for by the router, you'll still be prompted for these items; therefore, be sure that you configure all command values (even if you set it to none) so that autoenrollment occurs without any operator intervention.
The last step you need to perform in the trustpoint configuration is to enable autoenrollment with the auto-enroll command. The regenerate parameter specifies that a new RSA key pair should be created for the certificate even if a named key pair already exists. This ensures that when a router's certificate expires and it needs to request a new one, new keys are used instead of the ones from the old certificate.
Autoenrollment and the CA Certificate
When you're done with the trustpoint configuration with autoenrollment, within a few seconds the IOS will tell you that autoenrollment won't work until you obtain the CA's certificate and authenticate it. This can be done using one of the following two methods:
- Using SCEP to obtain the CA certificate
- Manually adding the CA certificate from the CLI
To use SCEP to obtain the CA's certificate, execute the crypto ca authenticate command with the name of the CA, discussed previously in the "Step 5: Download and Authenticate the CA's Certificate" section. The second option is to add the CA's certificate manually, using the crypto ca certificate chain and certificate ca commands. Because SCEP already is required to use autoenrollment, I won't discuss the latter approach.
Wait a few minutes for the autoenrollment process to start and obtain the router's identity certificate. If you're impatient, save your router's configuration and reboot it; upon rebooting, it will obtain its identity certificate.
Autoenrollment Example
Now that you understand the basic configuration for autoenrollment, I'll look at a simple configuration in Example 16-20 that illustrates how to set up autoenrollment. After the trustpoint configuration, the IOS warns you that you must next download and authenticate the CA certificate, which I did with the crypto ca authenticate command. Once this was done, about a minute later the autoenrollment process started with the information I configured under the trustpoint. At the end, the router automatically saved its certificates (and configuration) to NVRAM. Once done, you'll want to use the show crypto ca certificates and show crypto ca trustpoints command to verify that autoenroll did indeed acquire an identity certificate for your router.
Example 16-20. Sample Configuration Using Autoenrollment
r3640(config)# crypto ca trustpoint caserver
r3640(ca-trustpoint)# enrollment url
http://192.1.1.77/certsrv/mscep/mscep.dll
r3640(ca-trustpoint)# ip-address none
r3640(ca-trustpoint)# password dontrevokeme
r3640(ca-trustpoint)# rsakeypair caserver 512
r3640(ca-trustpoint)# auto-enroll regenerate
r3640(ca-trustpoint)# exit
% You must authenticate the Certificate Authority before
you can enroll with it.
r3640(config)# crypto ca authenticate caserver
Certificate has the following attributes:
Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47
Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Start certificate enrollment ..
% The subject name in the certificate will be: CN=r3640.cisco.com,
OU=corporate, O=cisco
% The fully-qualified domain name in the certificate will be:
r3640.cisco.com
% The subject name in the certificate will be: r3640.cisco.com
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto pki certificate' command will also show the
fingerprint.
05:23:29: %CRYPTO-6-AUTOGEN: Generated new 512 bit key pair
05:23:30: CRYPTO_PKI: Certificate Request Fingerprint MD5:
85D91350 640EA994 0645C9C9 5D86563E
05:23:30: CRYPTO_PKI: Certificate Request Fingerprint SHA1:
677272CE B3E44144 AF143210 025C8AA3 36C155E1
05:23:33: %PKI-6-CERTRET: Certificate received from Certificate
Authority
05:23:33: %PKI-6-AUTOSAVE: Running configuration saved to NVRAM
Certificate Attribute-Based Access Control
The certificate attribute-based access control (CABAC) feature, introduced in IOS 12.2(15)T, allows you to perform an additional step in authenticating a certificate. With CABAC, you can have the router look at specific certificate fields on a certificate and the values associated with them when determining whether or not you'll accept the certificate.
CABAC allows you to look at one or more fields on a certificate for an acceptable value(s). The kinds of tests you can perform are: equal to, not equal to, contains, doesn't contain, is less than, and is greater than or equal to, for the contents of a field. If you specify more than one test, all tests on all the specified fields must be true for a match to occur and an action to take place. Another nice feature is that you can specify a field multiple times within CABAC if you are looking for a number of permitted values.
For example, maybe you have a network with a router that handles site-to-site sessions with only a few remote access sessions for administrative functions, where the remote access authentication is handled by an AAA server such as Cisco Secure ACS (CSACS). You also have a VPN 3030 concentrator that handles user remote access IPsec sessions, where the 3030 also uses CSACS to authenticate the users. Both the router and 3030 use certificates for device authentication. However, you don't want the users to establish IPsec remote access sessions to the router, which they could, by default, because both the router and 3030 use certificates from the same CA for device authentication and the same source (CSACS) for user authentication (XAUTH). In this instance, you can use CABAC to match on the OU field that the network administrators belong to, in addition to the site-to-site connection devices, and thereby exclude all other remote access users.
Note
The memory and processing required to perform CABAC is minimal and adds very little overhead to the router and certificate verification process.
CABAC Configuration
Configuring CABAC is a two-step process:
1. | Creating the matching rules for certificates to be allowed |
2. | Applying the matching rules to a trustpoint |
To create your match rules, you need to create a certificate map with your rules embedded within the map:
Router(config)# crypto ca certificate map map_name sequence_#
Router(ca-certificate-map)# field_name operator match_value
The crypto ca certificate map command is similar to configuring a crypto map for IPsec (discussed in the next chapter). The map can have multiple entries in it, where each entry has a unique sequence number. Sequence numbers can range from 165,535, where entries are processed in numerical order. The entries are grouped together into a single map by specifying the same map_name for each statement. Normally, I use the name of the CA that this will be applied against, but you can use whatever map name you choose (just so it is unique among all certificate map names on the router).
After executing the crypto ca certificate map command, you are taken into a subcommand mode where you can enter your matching criteria. The first value you enter on a command line is the name of the field on the certificate you're going to match against: subject-name, issuer-name, unstructured-subject-name, alt-subject-name, name, valid-start, and expires-on. The second value you enter is the operator, which can be one of the following:
- eq equal to (valid for the name and date fields only)
- ne not equal to (valid for the name and date fields only)
- co contains the specified value (valid only for the name fields)
- nc does not contain the specified value (valid only for the name fields)
- lt less than (valid only for the date fields)
- ge greater than or equal to (valid only for the date fields)
The last parameter, match_value, specifies what value you are matching against.
Once you have created your certificate mappings, you need to apply them to the trustpoint CA that handles the certificate functions in question:
Router(config)# crypto ca trustpoint CA_name
Router(ca-trustpoint)# match certificate map_name
This is done by going into the trustpoint configuration with the crypto ca trustpoint command for the CA that you want to apply the map to. The match certificate command specifies the certificate map configuration you created with the crypto ca certificate map command. At this point, any new IPsec sessions brought up will first be validated using the certificate map.
Note
The entries in the certificate map are processed in numerical order. Matching on names (strings) is case-insensitive. As soon as a match is found for an entry, no further processing occurs. When a match occurs (all specific matchings in the entry must match), the peer's certificate will then be validated by checking the authenticity of it with the CA's signature, checking the validity date of the certificate, and checking the revocation status (the last is optional). If a match isn't found in the certificate map, the certificate is automatically considered invalid and device authentication fails.
CABAC Configuration Example
Now that you have a basic understanding of the commands used for CABAC, I'll look at an example that illustrates its use. I'll use the example I referred to earlier about limiting IPsec access to the router to just the site-to-site sessions and the remote access network administrators, all of which are using certificates for device authentication. Example 16-21 shows the configuration of the router. The first entry (10) allows only a certificate that was issued by "caserver" where the Common Name (CN) is "r3620a.cisco.com" and the Organizational Unit (OU) field is "corporate"; this matches on one of the two routers for L2L sessions. Entry 20 matches on the second L2L peer. Entry 30 only looks for matches on certificates issued by "caserver" where the OU field is "netadmins," which represents the group name of the network administrator group. As you can see in this example, if there is not a match on these three entries, the remote peer will fail device authentication with certificates.
Example 16-21. Sample CABAC Configuration
r3640(config)# crypto ca certificate map certsallowed 10
r3640(ca-certificate-map)# issuer-name co caserver
r3640(ca-certificate-map)# subject-name co cn=r3620a.cisco.com
r3640(ca-certificate-map)# subject-name co ou=corporate
r3640(ca-certificate-map)# exit
r3640(config)# crypto ca certificate map certsallowed 20
r3640(ca-certificate-map)# issuer-name co caserver
r3640(ca-certificate-map)# subject-name co cn=r3620b.cisco.com
r3640(ca-certificate-map)# subject-name co ou=corporate
r3640(config)# crypto ca certificate map certsallowed 30
r3640(ca-certificate-map)# issuer-name co caserver
r3640(ca-certificate-map)# subject-name co ou=netadmins
r3640(ca-certificate-map)# exit
r3640(config)# crypto ca trustpoint caserver
r3640(ca-trustpoint)# match certificate certsallowed
CRL and Expired Certificate Access Control Lists
Another way of controlling authentication with certificates is to use the CRL and expired certificate Access Control List (ACL) feature, new in IOS 12.3(4)T. If you are using CRLs and a peer's serial number is listed in the CRL, by default, your router will invalidate the peer's certificate, causing authentication to fail. Likewise, if your router's date is beyond the expiration date on a peer's certificate, your router will invalidate the peer's certificate, causing authentication to fail.
With the certificate ACL feature, you can create exceptions to these cases. This is useful, for instance, if your router's battery for its clock dies and always comes up with an incorrect date such as 1993 or 2002. Even using NTP, the router's NTP process only allows incremental changes in the time, so it might take a long time for the router to synchronize its time with the NTP server. In this situation, if a peer's certificate says the validation dates are from November 30, 2004 to November 30, 2006 and the current day is November 19, 2005, the certificate is obviously valid; however, when your router, with the bad clock battery, boots up, it might have a date of March 1, 2003. Obviously the router would think the peer's certificate is invalid, when in reality it is valid. The real remedy to this problem is to replace the router's clock battery. In the interim, though, you can use the certificate ACL feature to allow the router to accept the certificate based on an "invalid" date.
Certificate ACL Configuration
Configuring the certificate ACL feature is a two-step process similar to CABAC:
1. | Creating the matching rules for certificates to be allowed |
2. | Applying the matching rules to a trustpoint with the type of exception allowed |
To create your match rules, you need to create a certificate map with your rules embedded within the map using the crypto ca certificate map (discussed in the last section). Once you create your map and its corresponding entries, you must enable them, which is done under the corresponding trustpoint CA:
Router(config)# crypto ca trustpoint CA_name
Router(ca-trustpoint)# match certificate map_name
[allow expired-certificate |
skip revocation-check |
skip authorization-check]
The allow expired-certificate parameter causes the router to not invalidate a certificate match found in the certificate map based on its date. The skip revocation-check parameter causes the router to ignore a serial number found in a CRL for matching certificates found in the certificate map. The skip authorization-check parameter specifies that the AAA check of a certificate is skipped when certificates with an AAA server are configured.
Expired Certificate ACL Configuration
I'll now illustrate the usefulness of the certificate ACL feature. In this example, assume that the clock battery on a 3640 has died and you have ordered a replacement. In the meantime, every time you cold-boot your router, it comes up with the wrong time and you have to change the time of the router manually to something close to what the NTP server is advertising to speed up the time-synchronization process. This has become a hassle because this router (at a remote site) periodically loses power and reboots. Using an Uninterrupted Power Supply would help simplify the problem, but the budget at the remote office didn't allow for it. This whole process has created a headache for you, because to administer the router, typically you do it through an IPsec L2L session from the corporate office; but in this case, the remote office's 3640 is invalidating the corporate office's certificate because the 3640 router's time always states March 1, 2002 when it boots up.
As a temporary fix to this problem, you've decided to exempt the corporate office's 7200 router certificate from expiration (on the remote office's 3640 router). Example 16-22 shows an example of what the remote office's 3640 router configuration would look like. In this example, the 7200's certificate (r7200.cisco.com) will be exempted from the expiration check when the 3640 at the remote office validates the 7200's certificate. Of course, once you replace the clock battery on the 3640, I would remove this configuration on the router.
Example 16-22. Sample Expiry ACL Configuration
r3640(config)# crypto ca certificate map certsallowed 10
r3640(ca-certificate-map)# issuer-name co caserver
r3640(ca-certificate-map)# subject-name co cn=r7200.cisco.com
r3640(ca-certificate-map)# subject-name co ou=corporate
r3640(ca-certificate-map)# exit
r3640(config)# crypto ca trustpoint caserver
r3640(ca-trustpoint)# match certificate exemptcorprouter
allow expired-certificate
Importing and Exporting RSA Keys and Certificates
One of the issues with RSA keys, which are used to sign and validate certificates, is that, by default, they cannot be saved anywhere except for NVRAM. This can present problems if the router fails and must be replaced, or if you buy a newer model router to replace an old one: you can't use the same certificate because you can't copy the RSA private key to the new router. In this situation, you would have to generate a new RSA key pair on the new router and acquire a new certificate.
Cisco realizes that this can create problems in certain situations. For example, in a failover configuration, two routers should have the same certificate and keys, otherwise the failover won't be seamless. Likewise, if you accidentally remove the wrong RSA key pair on a router, you would have to revoke the router's current certificate and generate new keys and a certificate request to allow for certificate authentication to proceed. Therefore, Cisco has developed a way that allows you to export and import RSA keys in IOS 12.2(15)T, specifically the private keys. This process applies to authentication methods that use RSA encrypted nonces or RSA signatureanything that uses an RSA key pair.
Tip
SSH also uses RSA key pairs for encryption. You can use the method described in this section to place the same RSA key pair on all routers and then allow your management station(s) to use the same public key to encrypt traffic to the routers, simplifying the management of RSA key pairs. Generate an RSA key pair to one router and export it to all other routers; then take the public key and configure it on the SSH client.
Creating an Exportable RSA Key Pair
By default, when you use the crypto key generate rsa command, the RSA key pair(s) created are not exportable. Plus, once a key pair is created, you cannot change whether or not it can be exportable. The only way to make an RSA key pair exportable is to define this when you create the key pair with the exportable parameter:
Router(config)# crypto key generate rsa {general-keys | usage-keys}
[label RSA_key_label] exportable
You can verify whether or not an RSA key pair is exportable by executing the show crypto key mypubkey rsa command on your router. Example 16-23 shows an example of two key pairs: one exportable and one not.
Example 16-23. Nonexportable and Exportable RSA Key Pairs
r3640# show crypto key mypubkey rsa
% Key pair was generated at: 10:49:01 EDT Mar 15 2005
Key name: r3640.cisco.com
Usage: General Purpose Key
Key is not exportable.
Key Data:
305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00A86CB5
3F4B7131 46930426 B9032C63 311C89E5 AF01F7DC 2ECFA4B9 6285E866
48595681 3C751924 D3031564 41DA5827 4F4D43BE 8214643A 0698BB04
3088F216 6B020301 0001
% Key pair was generated at: 14:24:54 EDT Mar 17 2005
Key name: caservercert
Usage: General Purpose Key
Key is exportable.
Key Data:
305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00C158F6
72F69C0D D0A8064E EAA88CE8 38A852CA C3927EEA 00CC8C62 8D8C26C4
38634CBE 5DF98751 B6F1194F DE80D659 6D5D3ADA EF6A708D 2EC77F46
CBCDF7C1 35020301 0001
Using a Configured RSA Key Pair for a Certificate
To associate the key pair with a certificate you'll be creating for your router, you would configure the following, which I've discussed in various sections throughout this chapter:
Router(config)# crypto ca trustpoint CA_name
Router(ca-trustpoint)# enrollment url CA_URL
Router(ca-trustpoint)# rsakeypair RSA_key_label
Router(ca-trustpoint)# exit
Router(config)# crypto ca authenticate CA_name
Router(config)# crypto ca enroll CA_name
Router(config)# exit
Router# copy running-config startup-config
The important thing about this code is that you specify the exportable key pair label name in the CA trustpoint configuration before requesting your router's identity certificate.
Exporting the RSA Key Pair and Certificates
To back up your RSA key pair, in addition to the CA and identity certificates, use the following command on the router that has the exportable keys:
Router(config)# crypto {ca | pki} export CA_name pkcs12
destination_URL passphrase
You must specify the name of the CA trustpoint where you obtained your identity certificate. The destination_URL parameter specifies to where you want the keys exported. This can include the following locations: Flash memory, FTP, NVRAM, RCP, SCP, TFTP, XMODEM, and YMODEM. Thepassphrase parameter is used to encrypt the PKCS #12 file that will have the exported keys. You must use the same passphrase value when importing the keys so as to decrypt them. This process protects the keys from unauthorized access. The passphrase can be any combination of characters, numbers, and special characters with the exception of "?" (the question mark).
Note
Caution
When setting up exportable keys and certificates, anyone who has level 15 access on the router can export this information, which might create a security issue. If you are concerned about this, configure AAA on your router with accounting enabled for command execution; then you can determine who exported any keying material and when they did it. I discuss the use of AAA in my Cisco Router Firewall Security book with Cisco Press.
Importing the RSA Key Pair and Certificates
To import an RSA key pair, CA certificate, and identity certificate into a router, use the following command:
Router(config)# crypto {ca | pki} import CA_name pkcs12
source_URL passphrase
You'll need to use the same passphrase to decrypt the RSA key pair in the PKCS #12 file. Once you do this, you will still need to configure the router with the correct commands to interact with the CA, if necessary. You could easily copy the configuration of the original router and select and paste the correct router CA commands into the new router.
Backing up RSA Information Example
To help illustrate this process, I'll use a simple example shown in Examples 16-24 and 16-25. The first example shows the creation of the exportable keys, the process of acquiring certificates, and the exporting of the RSA information. In this example, I gave the RSA key pair label the name of the CA I'll use for certificates. You can use whatever key label you want; however, I typically use the name of the CA that the key pair will be associated with. The second example shows the import process on a second router. Of course, you'll need to complete the configuration on the second router to match that of the first, to use the imported RSA keys and certificates.
Example 16-24. RSA Key Pair Export Example
r3640A(config)# crypto key generate rsa general-keys label caserver
exportable
The name for the keys will be: caserver
Choose the size of the key modulus in the range of 360 to 2048 for
your General Purpose Keys. Choosing a key modulus greater than 512
may take a few minutes.
How many bits in the modulus [512]:
% Generating 512 bit RSA keys ...[OK]
r3640A(config)# crypto ca trustpoint caserver
r3640A(ca-trustpoint)# enrollment url
http://192.1.1.77/certsrv/mscep/mscep.dll
r3640A(ca-trustpoint)# rsakeypair caserver
r3640A(ca-trustpoint)# exit
r3640A(config)# crypto ca authenticate caserver
r3640A(config)# crypto ca enroll caserver
r3640A(config)# crypto ca export caserver pkcs12
tftp://192.1.1.77/r3640A.pkcs12 cisco123
!Writing pkcs12 file to tftp://192.1.1.77/r3640A.pkcs12
CRYPTO_PKI: Exported PKCS12 file successfully.
04:01:56: %PKI-6-PKCS12EXPORT_SUCCESS: PKCS #12 Successfully
Exported.
Example 16-25. RSA Key Pair Import Example
r3620B(config)# crypto ca import caserver pkcs12
tftp://192.1.1.77/r3640A.pkcs12 cisco123
Loading r3640.pkcs12 from 192.1.1.77 (via Ethernet0/0): !
[OK - 2307 bytes]
CRYPTO_PKI: Imported PKCS12 file successfully.
.Mar 18 19:37:58.987: %CRYPTO-6-PKCS12IMPORT_SUCCESS:
No comments:
Post a Comment