example4 -18 Router_B的RSA签名配置(图4 - 5）
Router_B #显示加密证书证书状态:Available证书序列号:02证书用途:通用颁发者:cn=IOS_CAROOT主题:名称:router_b.s cisco.com IP地址:192.168.2.1序列号:46DDB4F1 serialNumber=46DDB4F1+ipaddress=192.168.2.1+hostname= router_b.s cisco.com有效期:开始日期:10:12:14 UTC Feb 24 2005结束日期: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 2008IOS_CAROOT Router_B #显示加密密钥mypubkey rsa%密钥对生成时间:10:11:24 UTC Feb 24 2005密钥名称:Router_B.cisco.com用途:通用密钥密钥不可导出。关键数据:30819f30 0d06092a 864886f7 0d01010105000381 8d0d00308f 3da673ff c68454e4 68cf0e46 c798ba58 03599ab0 aff59a8c 7bacff5b c995e5 8f74a7f70a2df07 32961389 47cba640 20bc3680 8a4530d 775e333 f491738d 345b4faa2086 bce01e7b 0bf8337b ceb74ff0 8464ac03 161ad3d18b1720 a24ac357 df990577 c170bb0f 652da98a49e165c445020301 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#显示加密密钥pubkey-chain rsa代码使用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
验证CA和获取CA证书
在Cisco IOS VPN终端进行CA认证时，VPN终端管理员通过可视化的方式检查CA证书指纹，并手动接受对应的CA证书。除了人为错误的验收CA指纹和证书上面所描述的那样,观察到在这个过程中最常见的一个错误是由于矛盾之间的时钟设置端点和CA, CA的证书有与之关联的一生。当公钥基础设施(PKI)端点在身份验证过程中接收到CA证书并且时钟设置不正确时，CA证书可能看起来是无效的。考虑示例4-19，其中Router_B试图注册到CA RSA_CAROOT。Router_B的时钟设置不正确，导致路由器认为CA证书已经超出了适当的有效期。
例4-19时钟设置不一致导致CA认证失败
Router_B #sh时钟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 valid or is expired - start date: 14:40:58 UTC Feb 17 2005 end date: 14:40:58 UTC Feb 17 2008
一旦Router_B的时钟已经与PKI(以及随后的CA)同步，Router_B就可以通过验证CA证书的拇指指纹来验证PKI中的CA，如示例4-20，第3-5行所示。示例4-20的第10行和第11行输出，验证Router_B已经收到了CA证书。我们可以通过。来进一步确认在Router_B上存在一个CA证书显示示例4-20中执行的命令，第13行，以及示例4-20中产生的诊断输出，第14-25行。
例4-20认证和获取CA证书
# 1 Router_B(配置)crypto pki authenticate IOS_CAROOT2证书具有以下属性:3指纹:743A3CD1 14293369 3CB5D70C BDB96C7F 4 %您接受此证书吗?[yes/no]: yes 5接受信任点CA证书。6 7 IOS_CAROOT #调试加密pki服务器8 !9 !10 Feb 22 10:54:12.715: CRYPTO_CS: received a SCEP GetCACert request显示加密pki证书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
现在我们已经验证了CA的证书，我们可以继续在PKI中注册VPN端点。
登记PKI
为了登记PKI, VPN端点必须成功地对它要登记的CA进行身份验证。另外，订阅PKI的VPN端点在注册后必须成功地从CA处获得CA的签名证书。为了成功地完成这一任务，必须做到两件事。首先，CA必须从VPN端点接收适当的请求。这要求VPN端点使用在CA上配置的所需通信方法。考虑下面的情况，Router_A想要注册到IOS_CAROOT中图4 - 5．我们可以通过例4-21中IOS CA上的PKI服务器操作调试输出来确认，确实收到了Router_A的注册请求。
例4-21验证CA是否收到注册请求
IOS_CAROOT #调试加密pki服务器！！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:未注册和未绑定的服务SCEP_READ_DB_26 Feb 22 10:41:06.199: CRYPTO_CS:收到注册请求
在PKI注册中必须完成的第二个任务是验证路由器确实收到了CA的证书。请记住，在注册PKI时，CA管理员必须将其证书授予VPN端点，然后才能将其颁发给VPN端点。因此，很可能成功地对CA进行身份验证，而不成功地注册。在CA的IOS命令行界面(CLI)的第4行输出如下诊断信息，确认CA已经授予证书并将其证书发送给了请求者(Router_A)。示例4-22中第7行提供的输出确认了Router_A确实收到了来自CA的签名证书。
例4-22 Router_A的证书由CA签名、CA发送、Router_A接收
1 IOS_CAROOT #调试加密pki服务器2 !3 !6 Router_A# 7 *Feb 22 10:56:12.299: %CRYPTO-6-CERTRET:从证书颁发机构收到的证书
当一个加密端点通过身份验证并注册PKI后，两个加密端点之间仍然需要进行IKE SA协商才能建立IPsec VPN隧道。因此，在对等体通过身份验证并加入PKI后，必须使用本章介绍的验证方法验证ISAKMP SA的建立，以确保IKE SA协商的剩余机制已经成功执行。在进行PKI认证和注册后，检查证书的有效性同样重要，以避免RSA签名的IKE认证错误。一旦每个VPN端点接收到证书，就应该检查它们的一致性。再次考虑Router_A和Router_B之间的IKE认证交换图4 - 5．我们可以在Router_A和Router_B上确认签名证书的存在，如示例4-23所示。
例4-23验证IOS PKI VPN端点是否存在证书
Router_A #显示加密证书证书状态:Available证书序列号:07证书用途:通用颁发者:cn=IOS_CAROOT主题:Name: router_a.c cisco.com IP地址:202.0.0.1序列号:01C2F27F serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname= router_a.c cisco.com有效期:起始日期:15:21:49 UTC Feb 22 2005结束日期:15:21:49 UTC Feb 22 2006 renew date: 00:00:00 UTC Jan 1 1970关联信任点:IOS_CAROOT Router_B#显示加密证书证书状态:Available证书序列号:06证书用途:通用颁发者:cn=IOS_CAROOT主题:Name: Router_B.cisco.com IP地址:202.0.0.2 Serial Number: 46DDB4F1 serialNumber=46DDB4F1+ipaddress=202.0.0.2+hostname=Router_B.cisco.com有效期:起始日期:15:20:38 UTC Feb 22 2005结束日期:15:20:38 UTC Feb 22 2006 renew date: 00:00:00 UTC Jan 1 1970关联信任点:IOS_CAROOT
最后，上面显示的证书用于在Phase1协商过程中验证IKE通道。示例4-24的诊断和调试信息显示，IKE认证确实使用了RSA签名，并且使用RSA签名方式认证的ISAKMP SA已经成功建立。
例4-24 Router_A验证使用RSA签名建立ISAKMP SA
Router_A #调试加密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):构造certpayload for serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com！*Feb 22 15:22:52.987: ISAKMP(0:1):处理SIG负载。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# . message ID = 0 *Feb 22 15:22:52.991: ISAKMP (0:1): SA has been authenticated with 200.0.0.2 Router_A# . message ID = 0 *Feb 22 15:22:52.991: ISAKMP (0:1): SA authentication status: authenticated显示crypto isakmp sadst src state conn-id slot 200.0.0.2 200.0.0.1 QM_IDLE 1 0 router_a# . dst src state conn-id slot 200.0.0.2显示激活的加密引擎连接ID接口ip地址状态算法加密解密1 FastEthernet0/0 200.0.0.1 set HMAC_SHA+3DES_56_C 00 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 200
IPsec SA提议不匹配
回想一下我们在第2章中对IPsec的概述，在存在ISAKMP SA之前，IPsec SA是不能建立的(除非使用了手动密钥)。到目前为止，我们已经讨论了调试阶段1协商错误的常见故障排除策略。现在，我们假设已经建立了ISAKMP SA，并探讨一些常见问题，以便在IPsec SA的第二阶段协商中排除故障。
为了让两个对等体成功协商出一个IPsec SA，它们必须在阶段2中特定的三件事上达成一致:
IPsec隧道终止时使用的IP地址
在协商好IPsec SA后，对称IPsec转换为用于加密保护的流量
加密交换路径中受保护流量的范围
注意:crypto路径中的其他项可以在阶段2协商期间进行协商，即使它们不匹配。IPsec SA的这些元素包括SA生存期和PFS (perfect forward secrecy)组模量。
现在路由器进来了图4 - 5如果能够使用RSA签名相互验证，并且能够建立ISAKMP SA，我们将在加密映射中插入一个错误，阻止我们协商IPsec SA。在Router_B上，我们将把对等地址改为指向Router_C，而不是Router_A。在例4-25中，我们故意在Router_B上插入了一个错误的对等体，以说明例4-26中IOS CLI上的对等体不匹配诊断输出。
例4-25 Router_B插入对等体错误
Router_B #参看t输入配置命令，每行一个。结尾CNTL / Z。Router_B(配置)#加密地图pki4Router_B (config-crypto-map) #设置对等200.0.0.10Router_B (config-crypto-map) #结束Router_B #
正如预期的那样，Router_A和Router_B可以建立ISAKMP SA，但是由于example4 -25中引入的对等体不一致，导致Router_B无法完成阶段2的协商。我们可以使用。调试阶段2协商过程来确认不一致性调试加密IPsec命令。例4-26提供的诊断输出表明Router_B上的对等端地址不一致，导致IPsec SA协商失败。
例4-26识别IPsec安全提议不匹配的问题
Router_A #调试加密IPsecRouter_A# Feb 24 11:52:30.196: IPSEC(sa_request):， (key eng。味精)。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 #调试加密IPsecRouter_B# Feb 24 11:52:30.627: IPSEC(key_engine): got a queue event with 1 kei messages味精)。入站本地= 200.0.0.2远程= 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),协议= ESP,变换= esp-aes esp-sha-hmac(隧道),lifedur = 0和0 kb, spi = 0 x0 (0), conn_id = 0, keysize = 128,生成标志= 0×2月24 11:52:30.791:加密mapdb: proxy_match src addr:202.2.2.0 dst addr: 202.1.1.0协议:0 src端口:0 dst端口:0 2月24 11:52:30.791:IPSEC (validate_transform_proposal):对等解决200.0.0.1没有找到2月24 11:52:30.795:% CRYPTO-6-IKMP_MODE_FAILURE:快速模式失败的处理与同伴200.0.0.1 2月24 11:53:00.315:IPSEC (validate_proposal_request):建议部分# 1,(关键eng。味精)。入站本地= 200.0.0.2远程= 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),协议= ESP,变换= esp-aes esp-sha-hmac(隧道),lifedur = 0和0 kb, spi = 0 x0 (0), conn_id = 0, keysize = 128,生成标志= 0×2月24 11:53:00.315:加密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 .日志含义
现在让我们插入另一个导致阶段2协商失败的错误。在例4-27中，我们将纠正例4-25中介绍的和例4-26中诊断的对等问题。我们还将在转换集“pki4”中重新配置加密转换，引入与Router_A不匹配的转换集(Router_A使用esp-aes esp-sha-hmac进行转换)。