Example 4-18 RSA Signatures Configuration on Router_B (Figure 4-5)
Router_B#show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 02
Certificate Usage: General Purpose
Issuer:
cn=IOS_CAROOT
Subject:
Name: Router_B.cisco.com
IP Address: 192.168.2.1
Serial Number: 46DDB4F1
serialNumber=46DDB4F1+ipaddress=192.168.2.1+hostname=Router_B.cisco.com
Validity Date:
start date: 10:12:14 UTC Feb 24 2005
end date: 10:12:14 UTC Feb 24 2006
renew date: 00:00:00 UTC Jan 1 1970
Associated Trustpoints: IOS_CAROOT
CA Certificate
Status: Available
Certificate Serial Number: 01
Certificate Usage: Signature
Issuer:
cn=IOS_CAROOT
Subject:
cn=IOS_CAROOT
Validity Date:
start date: 09:06:11 UTC Feb 24 2005
end date: 09:06:11 UTC Feb 24 2008
Associated Trustpoints: IOS_CAROOT
Router_B#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:24 UTC Feb 24 2005
Key name: Router_B.cisco.com
Usage: General Purpose Key
Key is not exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00BED6DA
A5B2F28A 344B205F 3DA673FF C68454E4 68CF0E46 C798BA58 03599AB0 AFF59A8C
7BACFF5B C99549D5 8F74A7CE 70A2DF07 32961389 47CBA640 20BC3680 8A45309D
775E3233 F491738D 345B59EE 4FAA2086 BCE01E7B 0BF8337B CEB74FF0 8464AC03
161AD316 D18B1720 A24AC357 DF990577 C170BB0F 652DA98A 49E165C4 45020301 0001
% Key pair was generated at: 10:11:25 UTC Feb 24 2005
Key name: Router_B.cisco.com.server
Usage: Encryption Key
Key is not exportable.
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B0EF99 26A348E9
DCEEA144 54CA48F4 B396BBA6 E9973EC8 58B5A3D5 2B9339EC D3B26894 FBA3F6C5
50864ECD 4329EE58 4291FAE0 4E9C02EF C0FE117C 77E1E7E7 F871B74D 2012BF25
56C60BAF 33F7C29D 8B79FDCF D4ACE6E9 9DCD1DB6 92E62427 2B020301 0001
Router_B#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate
Code Usage IP-Address/VRF Keyring Name
C Signing default X.500 DN name:
cn=IOS_CAROOT
C Signing 192.168.1.1 default Router_A.cisco.com
Authenticating the CA and Obtaining the CA Certificate
During the process of CA authentication on a Cisco IOS VPN endpoint, the administrator of the VPN endpoint visually inspects the CA certificate fingerprint and manually accepts the corresponding CA certificate. Aside from human error in the inspection and acceptance of the CA fingerprint and certificate described above, one of the most common errors observed during this process is attributable to inconsistencies in clock settings between the endpoint and the CA. The CA's certificate has a lifetime associated with it. When a public-key infrastructure (PKI) endpoint receives the CA certificate during the authentication process and has an incorrect clock setting, the CA certificate could appear to be invalid. Consider Example 4-19 in which Router_B attempts to enroll with the CA, RSA_CAROOT. Router_B's clock is set incorrectly, which leads the router to believe that the CA certificate is outside of the appropriate period of validity.
Example 4-19 CA Authentication Failure Due to Inconsistent Clock Settings
Router_B#sh clock 09:55:30.262 UTC Wed Apr 26 2002 Router_B(config)#crypto pki authenticate IOS_CAROOT % Error in saving certificate: status = FAIL %CRYPTO_PKI: CA Cert not yet valid or is expired - start date: 14:40:58 UTC Feb 17 2005 end date: 14:40:58 UTC Feb 17 2008
Once Router_B's clock has been synchronized with the PKI (and subsequently the CA's), Router_B can then authenticate the CA in the PKI by verifying the CA certificate's thumbprint, as illustrated in Example 4-20, lines 3-5. The debugging output from Example 4-20, lines 10 and 11, verifies that a CA certificate has been received by Router_B. We can further confirm that a CA certificate exists on Router_B via the show command executed in Example 4-20, line 13, and the resulting diagnostic output in Example 4-20, lines 14-25.
Example 4-20 Authenticating and Obtaining the CA Certificate
1 Router_B(config)#crypto pki authenticate IOS_CAROOT 2 Certificate has the following attributes: 3 Fingerprint: 743A3CD1 14293369 3CB5D70C BDB96C7F 4 % Do you accept this certificate? [yes/no]: yes 5 Trustpoint CA certificate accepted. 6 7 IOS_CAROOT#debug crypto pki server 8 ! 9 ! 10 Feb 22 10:54:12.715: CRYPTO_CS: received a SCEP GetCACert request 11 Feb 22 10:54:12.715: CRYPTO_CS: CA certificate sent 12 13 Router_B#show crypto pki certificates 14 CA Certificate 15 Status: Available 16 Certificate Serial Number: 01 17 Certificate Usage: Signature 18 Issuer: 19 cn=IOS_CAROOT 20 Subject: 21 cn=IOS_CAROOT 22 Validity Date: 23 start date: 14:40:58 UTC Feb 17 2005 24 end date: 14:40:58 UTC Feb 17 2008 25 Associated Trustpoints: IOS_CAROOT
Now that we have verified that we have the CA's certificate, we can proceed to enroll the VPN endpoint in the PKI.
Enrolling in the PKI
In order to enroll in the PKI, the VPN endpoint must have successfully authenticated the CA to which it will enroll. Additionally, the VPN endpoint subscribing to the PKI must successfully obtain the CA's signing certificate from the CA after enrolling. In order to successfully accomplish this, two things must occur. First, the CA must receive the appropriate request from the VPN endpoint. This requires that the VPN endpoint use the required communication method configured on the CA. Consider the case below in which Router_A wants to enroll with IOS_CAROOT in Figure 4-5. We can confirm through the PKI server operation debugging output on the IOS CA provided in Example 4-21 that the requests for enrollment have indeed been received from Router_A.
Example 4-21 Verifying That Enrollment Requests Are Received by the CA
IOS_CAROOT#debug crypto pki server ! ! Feb 22 10:41:06.119: CRYPTO_CS: received a SCEP request Feb 22 10:41:06.119: CRYPTO_CS: read SCEP: registered and bound service SCEP_READ_DB_26 Feb 22 10:41:06.127: CRYPTO_CS: scep msg type - 19 Feb 22 10:41:06.127: CRYPTO_CS: trans id - A758860CFBEAC6B6720A8650A1046863 Feb 22 10:41:06.199: CRYPTO_CS: read SCEP: unregistered and unbound service SCEP_READ_DB_26 Feb 22 10:41:06.199: CRYPTO_CS: received an enrollment request
The second task that must be accomplished in PKI enrollment is verification that the router has indeed received the CA's certificate. Remember that, when enrolling in the PKI, the CA administrator must grant the VPN endpoint its certificate before it can be issued to the VPN endpoint. It is therefore quite possible to authenticate a CA successfully, while not enrolling successfully. The following diagnostic output on the IOS command-line interface (CLI) of the CA in line 4 confirms that the CA has granted and sent its certificate to a requestor (Router_A). The output provided in line 7 of Example 4-22 confirms that Router_A has indeed received its signed certificate from the CA.
Example 4-22 Router_A's Certificate Is Signed by the CA, Sent by the CA, and Received by Router_A
1 IOS_CAROOT#debug crypto pki server 2 ! 3 ! 4 Feb 22 10:41:13.871: CRYPTO_CS: Certificate generated and sent to requestor 5 6 Router_A# 7 *Feb 22 10:56:12.299: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority
After a crypto endpoint has successfully authenticated and enrolled with the PKI, IKE SA negotiation must still occur for two crypto endpoints to establish an IPsec VPN tunnel between each other. It is, therefore, important to verify ISAKMP SA establishment using the verification methods described earlier in this chapter after peers can successfully authenticate and enroll to the PKI to ensure that the remaining mechanics of IKE SA negotiation have been successfully executed. It is equally important to inspect the certificates for validity after PKI authentication and enrollment, in order to avoid IKE authentication errors with RSA signatures. Once certificates have been received by each VPN endpoint, they should be checked for consistency. Consider once again the IKE authentication exchange between Router_A and Router_B in Figure 4-5. We can confirm the existence of signed certificates on both Router_A and Router_B, as illustrated in Example 4-23.
Example 4-23 Verifying the Existence of Certificates on IOS PKI VPN Endpoints
Router_A#show crypto ca certificates Certificate Status: Available Certificate Serial Number: 07 Certificate Usage: General Purpose Issuer: cn=IOS_CAROOT Subject: Name: Router_A.cisco.com IP Address: 202.0.0.1 Serial Number: 01C2F27F serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com Validity Date: start date: 15:21:49 UTC Feb 22 2005 end date: 15:21:49 UTC Feb 22 2006 renew date: 00:00:00 UTC Jan 1 1970 Associated Trustpoints: IOS_CAROOT Router_B#show crypto ca certificates Certificate Status: Available Certificate Serial Number: 06 Certificate Usage: General Purpose Issuer: cn=IOS_CAROOT Subject: Name: Router_B.cisco.com IP Address: 202.0.0.2 Serial Number: 46DDB4F1 serialNumber=46DDB4F1+ipaddress=202.0.0.2+hostname=Router_B.cisco.com Validity Date: start date: 15:20:38 UTC Feb 22 2005 end date: 15:20:38 UTC Feb 22 2006 renew date: 00:00:00 UTC Jan 1 1970 Associated Trustpoints: IOS_CAROOT
Finally, the certificates displayed above are used to authenticate the IKE channel during Phase1 negotiation. Diagnostic and debugging output from Example 4-24 confirms that RSA Signatures are indeed used for IKE authentication, and that an ISAKMP SA has successfully been established using the RSA Signatures method of authentication.
Example 4-24 Verifying the Establishment of an ISAKMP SA Using RSA Signatures on Router_A
Router_A#debug crypto isakmp
!
!
*Feb 22 15:22:47.943: ISAKMP (0:1): SA is doing RSA signature authentication using id type ID_FQDN
!
!
*Feb 22 15:22:47.947: ISAKMP (0:1): constructing CERT payload for serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com
*Feb 22 15:22:47.947: ISAKMP (0:1): using the IOS_CAROOT trustpoint's keypair to sign
!
!
*Feb 22 15:22:52.987: ISAKMP (0:1): processing SIG payload. message ID = 0
*Feb 22 15:22:52.991: ISAKMP (0:1): SA authentication status:
authenticated
*Feb 22 15:22:52.991: ISAKMP (0:1): SA has been authenticated with 200.0.0.2
Router_A#show crypto isakmp sa
dst src state conn-id slot
200.0.0.2 200.0.0.1 QM_IDLE 1 0
Router_A#show crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
1 FastEthernet0/0 200.0.0.1 set HMAC_SHA+3DES_56_C 0 0
2000 FastEthernet0/0 200.0.0.1 set HMAC_SHA+AES_CBC 0 2
2001 FastEthernet0/0 200.0.0.1 set HMAC_SHA+AES_CBC 2 0
IPsec SA Proposal Mismatches
Recall from our IPsec overview in Chapter 2 that the IPsec SAs cannot be established until there is an ISAKMP SA (unless manual keying is used). Up until this point, we've discussed common troubleshooting tactics for debugging Phase 1 negotiation errors. Now we will assume that an ISAKMP SA has been established and explore some common issues to troubleshoot in Phase 2 negotiation of the IPsec SA.
In order for two peers to successfully negotiate an IPsec SA, they must agree on three things specific to Phase 2 negotiation:
The IP addresses used for IPsec tunnel termination
The symmetric IPsec transforms to use on crypto-protected traffic after an IPsec SA has been negotiated
The scope of protected traffic in the crypto switching path
Note - Other items in the crypto path can be negotiated during Phase 2 negotiation even if they are mismatched. Such elements of the IPsec SA include the SA lifetime and perfect forward secrecy (PFS) group modulus.
Now that the routers in Figure 4-5 have been able to authenticate one another using RSA Signatures, and can establish an ISAKMP SA, we will insert an error in to the crypto map that prevents us from negotiating an IPsec SA. On Router_B, we will change the peering address to point to Router_C instead of Router_A. In Example 4-25, we will intentionally insert an incorrect peer on Router_B in order to illustrate peer mismatch diagnostic output on the IOS CLI in Example 4-26.
Example 4-25 Inserting a Peering Error on Router_B
Router_B#conf t Enter configuration commands, one per line. End with CNTL/Z. Router_B(config)#crypto map pki4 10 Router_B(config-crypto-map)#set peer 200.0.0.10 Router_B(config-crypto-map)#end Router_B#
As expected, Router_A and Router_B can establish an ISAKMP SA, but are unable to complete Phase 2 negotiation due to the peering inconsistency introduced in Example 4-25. We can confirm the inconsistency by debugging the Phase 2 negotiation process using the debug crypto IPsec command. Example 4-26 provides diagnostic output indicating a peering address inconsistency on Router_B causing the IPsec SA negotiation to fail.
Example 4-26 Identifying IPsec Proposal Mismatch Issues
Router_A#debug crypto IPsec
Router_A#
Feb 24 11:52:30.196: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 200.0.0.1, remote= 200.0.0.2,
local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 5000s and 4608000kb,
spi= 0x59ABE066(1504436326), conn_id= 0, keysize= 128, flags= 0x400B.....
Router_B#debug crypto IPsec
Router_B#
Feb 24 11:52:30.627: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 11:52:30.791: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 11:52:30.791: Crypto mapdb : proxy_match
src addr : 202.2.2.0
dst addr : 202.1.1.0
protocol : 0
src port : 0
dst port : 0
Feb 24 11:52:30.791: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found
Feb 24 11:52:30.795: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 200.0.0.1
Feb 24 11:53:00.315: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 11:53:00.315: Crypto mapdb : proxy_match
src addr : 202.2.2.0
dst addr : 202.1.1.0
protocol : 0
src port : 0
dst port : 0
Feb 24 11:53:00.315: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found
Let us now insert another error that causes Phase 2 negotiation failure. In Example 4-27, we will remedy the peering issue introduced in Example 4-25 and diagnosed in Example 4-26. We will also reconfigure the crypto transform in transform set "pki4," introducing a transform set mismatch with Router_A (Router_A uses esp-aes esp-sha-hmac for its transform).