安全与 VPN : 互联网安全协会和密钥管理协议 (ISAKMP)

IOS IKEv1和IKEv2配置文件的信息包交换进程与多份证书

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 23 日) | 反馈

简介

本文描述互联网密钥交换版本1 (IKEv1)和互联网密钥交换版本2 (IKEv2)信息包交换进程,当使用证书验证和也许发生的可能的问题时。

这是在本文描述主题的列表:

  • Internet Key Exchange (IKE)发起者和IKE响应方的证书选择标准
  • IKE配置文件匹配标准,当多IKE配置文件匹配(重叠和非重叠方案)
  • 默认设置和行为,当托拉斯点没有使用在IKE配置文件下
  • 在IKEv1和IKEv2之间的区别关于配置文件和证书选择标准

注意:关于如何排除故障一特定问题的详情,参考正确部分。并且,简要总结提供在本文结束时。


贡献用米哈拉Garcarz, Cisco TAC工程师。

先决条件


要求

Cisco 建议您了解以下主题:

  • Cisco IOS VPN配置
  • IKEv1和IKEv2协议(信息包交换)

使用的组件

本文档中的信息根据Cisco IOS Version15.3T。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。


背景信息

在本文描述的问题出现,当使用时多个托拉斯点和多IKE配置文件。

在本文使用的最初的示例有一个IKEv1 LAN-to-LAN隧道用在每个路由器的两个托拉斯点。起初,也许看起来配置正确。然而, VPN通道可以从连接的一端仅被发起由于ca trust-point命令使用互联网安全协会和密钥管理协议(ISAKMP)配置文件行为和被登记的证书定货在本地存储的方法。

当路由器是ISAKMP发起者时,一种不同的行为用ISAKMP简档的ca trust-point命令配置。问题也许发生,因为ISAKMP发起者从开始知道ISAKMP简档,因此为配置文件配置的ca trust-point命令能影响证书请求的有效负载在主模式数据包3 (MM3)。然而,当路由器是ISAKMP响应方时,它绑定入站数据流对一特定ISAKMP简档,在收到主模式数据包5 (MM5)后,包括IKE ID是必要为了创建捆绑。这就是为什么为主模式数据包4 (MM4)是不可能的数据包实施所有ca trust-point命令,因为配置文件没有在MM5前确定。

证书requestpayload和影响协商进程的顺序在MM3和MM4的在本文,以及原因总体上解释只允许从VPN通道的一端将设立的连接。

这是IKEv1发起者和响应方行为的摘要:


 IKEv1发起者IKEv1响应方
发送请求发送仅特定请求配置在配置文件下的托拉斯点的 所有的发送请求可用的托拉斯点
验证请求验证配置在配置文件下的特定托拉斯点验证配置在配置文件下的特定托拉斯点


思科建议您不使用ca trust-point命令有多ISAKMP配置文件并且使用全局配置的托拉斯点的ISAKMP响应方。对于与多ISAKMP配置文件的ISAKMP创始者, Cisco建议您缩小与ca trust-point in命令的证书选择过程每配置文件。

IKEv2协议有问题和IKEv1协议一样,但是pki trustpoint命令帮助的另外行为防止问题的出现。这是因为pki trustpoint命令对于IKEv2发起者是必需的,而ca trust-point命令对于IKEv1发起者是可选的。在一些情况(多个托拉斯点下在一配置文件以下),以前描述的问题也许发生。为此,思科建议您使用对称托拉斯点配置连接(同样托拉斯点的两边配置在两个IKEv2配置文件下)。


拓扑

这是使用所有示例在本文的一通用的拓扑。


注意:路由器1 (R1)和Router2 (R2)使用虚拟隧道接口(VTIs)为了访问环回。这些VTIs由IPSec保护。


对于此IKEv1示例,每个路由器有每Certificate Authority (CA)的两个托拉斯点,并且其中每一个的证书托拉斯点被登记。

当R1是ISAKMP发起者时,通道正确地协商,并且流量保护。这是预料之中的现象。当R2是ISAKMP发起者时,阶段1协商发生故障。


注意:对于在本文的IKEv2示例,拓扑和编址是显示IKEv1示例的相同的象。


信息包交换进程

此部分描述使用信息包交换进程的IKEv1和IKEv2配置变化和也许出现的可能的问题。


与多份证书的IKEv1

这是R1网络和VPN配置IKEv1的与多份证书:


crypto isakmp policy 10
 encr 3des
 hash md5
 group 2

crypto isakmp profile prof1
   self-identity fqdn
   ca trust-point IOSCA1
   match identity host R2.cisco.com
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile prof1
 set transform-set TS
 set isakmp-profile prof1         
!
interface Loopback0
 description Simulate LAN
 ip address 192.168.100.1 255.255.255.0
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile prof1
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0

ip route 192.168.200.0 255.255.255.0 10.0.0.2

这是R2网络和VPN配置IKEv1的与多份证书:


crypto isakmp policy 10
 encr 3des
 hash md5
 group 2

crypto isakmp profile prof1
   self-identity fqdn
   match identity host R1.cisco.com
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile prof1
 set transform-set TS
 set isakmp-profile prof1
!
interface Loopback0
 ip address 192.168.200.1 255.255.255.0
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile prof1
!
interface Ethernet0/0
 ip address 192.168.0.2 255.255.255.0

ip route 192.168.100.0 255.255.255.0 10.0.0.1

在本例中, R1有两个托拉斯点:一使用IOSCA1和第二用途IOSCA2


crypto pki trustpoint IOSCA1
 enrollment url http://192.168.0.3:80
 serial-number
 fqdn R1.cisco.com
 ip-address 192.168.0.1
 subject-name CN=R1,OU=IT,O=cisco,O=com
 revocation-check crl
!
crypto pki trustpoint IOSCA2
 enrollment url http://192.168.0.4:80
 serial-number
 fqdn R1.cisco.com
 ip-address 192.168.0.1
 subject-name CN=R1,OU=IT,O=cisco,O=com
 revocation-check crl

在本例中, R2也有两个托拉斯点:一使用IOSCA1和第二用途IOSCA2


crypto pki trustpoint IOSCA1
 enrollment url http://192.168.0.3:80
 serial-number
 fqdn R2.cisco.com
 ip-address 192.168.0.2
 subject-name CN=R2,OU=IT,O=cisco,O=com
 revocation-check crl
!
crypto pki trustpoint IOSCA2
 enrollment url http://192.168.0.4:80
 serial-number
 fqdn R2.cisco.com
 ip-address 192.168.0.2
 subject-name CN=R2,OU=IT,O=cisco,O=com
 revocation-check crl

注意单个差异在这些配置方面是重要的:R1 ISAKMP简档使用ca trust-point命令IOSCA1托拉斯点,表明R1委托由该特定托拉斯点验证仅的证书。相反, R2委托由所有全局定义的托拉斯点验证的所有证书。


R1作为IKEv1发起者

这是R1和R2的调试指令:

  • R1- debug crypto isakmp
  • R1- debug crypto ipsec
  • R1- debug crypto pki验证

这里, R1发起通道并且发送证书requestin MM3 :


*Jun 20 13:00:37.609: ISAKMP:(0): SA request profile is prof1
*Jun 20 13:00:37.610: ISAKMP (0): constructing CERT_REQ for issuer
 cn=CA1,o=cisco,o=com

*Jun 20 13:00:37.610: ISAKMP:(0): sending packet to 192.168.0.2
 my_port 500 peer_port 500 (I) MM_SA_SETUP
*Jun 20 13:00:37.610: ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3

注意是重要的数据包只包含一证书请求,仅是为IOSCA1托拉斯点。这是与ISAKMP简档(CN=CA1的当前配置的预料之中的行为, O=cisco, O=com)。其他证书请求没有发送,您能验证与嵌入式数据包捕获功能:



当R2收到数据包时,开始处理证书请求,创建匹配确定托拉斯点和相关的证书使用验证在MM5。进程顺序是相同的象在ISAKMP信息包的证书请求有效负载。这意味着使用第一匹配。在此方案中,只有一匹配,因为R1用一个特定托拉斯点只配置并且发送用托拉斯点关联的一证书请求。


*Jun 20 13:00:37.617: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.617: ISAKMP:(1010): peer wants cert issued
 by cn=CA1,o=cisco,o=com
*Jun 20 13:00:37.617:  Choosing trustpoint IOSCA1 as issuer

之后, R2准备MM4。这是包含所有的证书请求委托托拉斯点的数据包。因为R2是ISAKMP响应方,所有全局定义的托拉斯点是委托(ca trust-point配置没有被检查)。两托拉斯点手工定义(IOSCA1IOSCA2),并且其余预定义。


*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=CA1,o=cisco,o=com
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=CA2,o=cisco,o=com
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer ou=Class 3 Public Primary Certification Authority,
 o=VeriSign, Inc.,c=US

*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco SSCA2,o=Cisco Systems
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco Manufacturing CA,o=Cisco Systems
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco Root CA 2048,o=Cisco Systems
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco Root CA M1,o=Cisco
*Jun 20 13:00:37.617: ISAKMP:(1010): sending packet to
 192.168.0.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Jun 20 13:00:37.617: ISAKMP:(1010):Sending an IKE IPv4 Packet.
*Jun 20 13:00:37.617: ISAKMP:(1010):Input = IKE_MESG_INTERNAL,
 IKE_PROCESS_COMPLETE
*Jun 20 13:00:37.617: ISAKMP:(1010):Old State = IKE_R_MM3
 New State = IKE_R_MM4

您能验证有Wireshark的数据包。从R2的MM4数据包包含七个证书请求条目:



然后, R1接收从R2的MM4与多份证书请求字段:


*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=CA1,o=cisco,o=com

*Jun 20 13:00:37.623: ISAKMP: Examining profile list for trustpoint IOSCA1
*Jun 20 13:00:37.623: ISAKMP: Found matching profile for IOSCA1
*Jun 20 13:00:37.623:  Choosing trustpoint IOSCA1 as issuer
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=CA2,o=cisco,o=com
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by ou=Class 3
 Public Primary Certification Authority,o=VeriSign, Inc.,c=US

*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco SSCA2,o=Cisco Systems
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco Manufacturing CA,o=Cisco Systems
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco Root CA 2048,o=Cisco Systems
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco Root CA M1,o=Cisco

在R1的第一个匹配条件规则匹配第一证书请求用IOSCA1托拉斯点。这确定R1使用用验证的托拉斯点IOSCA1关联在MM5的证书。完全合格的域名(FQDN)使用作为IKE ID。这归结于在ISAKMP简档的赛弗标识fqdn配置:


*Jun 20 13:00:37.624: ISAKMP (1010): constructing CERT payload for serialNumber=
 100+ipaddress=192.168.0.1+hostname=R1.cisco.com,cn=R1,ou=IT,o=cisco,o=com
*Jun 20 13:00:37.624: ISAKMP:(1010): using the IOSCA1 trustpoint's
 keypair to sign

MM5由R2接收并且处理。已接收IKE ID (R1.cisco.com)匹配ISAKMP简档prof1。已接收证书然后验证,并且验证是成功的:


*Jun 20 13:00:37.625: ISAKMP:(1010): processing ID payload. message ID = 0
*Jun 20 13:00:37.625: ISAKMP (1010): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R1.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
*Jun 20 13:00:37.625: ISAKMP:(0):: peer matches prof1 profile
..........
*Jun 20 13:00:37.626: CRYPTO_PKI: (A0013) Certificate validation succeeded
..........
*Jun 20 13:00:37.626: ISAKMP:(1010):SA authentication status:
        authenticated

然后, R2准备与关联与IOSCA1的证书的MM6 :


*Jun 20 13:00:37.627: ISAKMP (1010): constructing CERT payload for serialNumber=
 101+ipaddress=192.168.0.2+hostname=R2.cisco.com,cn=R2,ou=IT,o=cisco,o=com
*Jun 20 13:00:37.627: ISAKMP:(1010): using the IOSCA1 trustpoint's keypair to sign
*Jun 20 13:00:37.632: ISAKMP:(1010): sending packet to 192.168.0.1
 my_port 500 peer_port 500 (R) MM_KEY_EXCH

数据包由R1接收,并且R1验证证书和验证:


*Jun 20 13:00:37.632: ISAKMP (1010): received packet from 192.168.0.2
 dport 500 sport 500 Global (I) MM_KEY_EXCH
*Jun 20 13:00:37.632: ISAKMP:(1010): processing ID payload. message ID = 0
*Jun 20 13:00:37.632: ISAKMP (1010): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R2.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
....
*Jun 20 13:00:37.632: ISAKMP:(0): Creating CERT validation list: IOSCA1
....
*Jun 20 13:00:37.633: CRYPTO_PKI: (80013) Certificate validation succeeded
....
*Jun 20 13:00:37.637: ISAKMP:(1010):SA authentication status:
        authenticated
*Jun 20 13:00:37.637: ISAKMP:(1010):Old State = IKE_I_MM6
 New State = IKE_P1_COMPLETE

这完成相位1.第2阶段照常协商。通道成功设立,并且流量保护。


R2作为IKEv1发起者

此示例描述进程,当R2发起同一个IKEv1通道并且解释时为什么没有设立。


注意:日志的部分删除为了仅着重差异关于在前面部分提交的示例。


R2发送与七证书请求有效载荷的MM3,因为R2没有一个托拉斯点关联与ISAKMP简档(所有托拉斯点委托) :


*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=CA1,o=cisco,o=com

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=CA2,o=cisco,o=com

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer ou=Class 3 Public Primary Certification Authority,
 o=VeriSign, Inc.,c=US

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco Root CA M1,o=Cisco

*Jun 17 18:08:44.321: ISAKMP (0): sending packet to 192.168.0.1
 my_port 500 peer_port 500 (I) MM_SA_SETUP

当R1收到从R2时的数据包,处理证书请求并且匹配IOSCA1托拉斯点,确定证书在MM6发送:


*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=CA1,o=cisco,o=com

*Jun 17 18:08:14.321:  Choosing trustpoint IOSCA1 as issuer
*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=CA2,o=cisco,o=com

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 ou=Class 3 Public Primary Certification Authority,o=VeriSign, Inc.,c=US

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco Root CA M1,o=Cisco

之后, R1准备有证书请求有效负载的MM4数据包。现在有多份证书请求有效载荷:


*Jun 17 18:08:14.321: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=CA2,o=cisco,o=com

*Jun 17 18:08:14.321: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=CA1,o=cisco,o=com

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 ou=Class 3 Public Primary Certification Authority,
 o=VeriSign, Inc.,c=US

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco Root CA M1,o=Cisco

*Jun 17 18:08:14.322: ISAKMP:(1099): sending packet to 192.168.0.2
 my_port 500 peer_port 500 (R) MM_KEY_EXCH

验证与嵌入式数据包捕获(EPC)和Wireshark的日志:



即使R1为一个托拉斯点(IOSCA1)配置在ISAKMP简档,有发送的多份证书请求。这发生,因为ca trust-point in命令ISAKMP简档确定证书请求有效负载,但是,只有当路由器是ISAKMP会话的发起者时。如果路由器是响应方,有多份证书所有的请求有效载荷全局定义的托拉斯点,因为使用IKE会话的R1不认识ISAKMP简档。

入站IKE会话被限制对一特定ISAKMP简档在MM5的接收以后,之后包括IKE ID,特定配置文件的匹配标识命令绑定IKE会话对配置文件。然而,路由器不能直到现在确定此。也许有多ISAKMP配置文件用为每配置文件配置的不同的ca trust-point命令。

为此, R1必须发送所有的证书请求全局配置的托拉斯点。

参考ca trust-point命令的命令参考

路由器启动IKE的和响应对IKE请求的路由器应该有对称信任点配置。例如,一个响应的路由器(在IKE主模式)执行RSA签名加密和验证也许使用在全局配置里定义,当发送CERT-REQ有效载荷时的信任点。然而,路由器也许使用在证书验证的ISAKMP简档定义信任点的一限制列表。如果对等体(IKE发起者)配置使用信任点在响应的路由器全局列表,但是不在响应的路由器的ISAKMP简档的证书,证书拒绝。(然而,如果启动的路由器在响应的路由器的全局配置里不知道关于信任点,证书可能仍然验证。)

现在请验证MM4信息包详细信息为了发现第一证书请求有效负载:



从R1发送的MM4数据包在第一证书请求有效负载包括IOSCA2托拉斯点由于证书安装的命令;第一个由IOSCA2托拉斯点签字:


R1#sh crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 03
  Certificate Usage: General Purpose
  Issuer:
    cn=CA2
    o=cisco
    o=com
  Subject:
    Name: R1.cisco.com
    IP Address: 192.168.0.1
    Serial Number: 100
    serialNumber=100+ipaddress=192.168.0.1+hostname=R1.cisco.com
    cn=R1
    ou=IT
    o=cisco
    o=com
  Validity Date:
    start date: 13:25:01 CET Jun 17 2013
    end   date: 13:25:01 CET Jun 17 2014
  Associated Trustpoints: IOSCA2
...
<output omitted, 1 more R1 cert signed by CA1, 2 more CA certs>

做一个比较跟从R2发送的MM3数据包,当IOSCA1托拉斯点在第一证书请求有效负载时包括:


R2#sh crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 02
  Certificate Usage: General Purpose
  Issuer:
    cn=CA1
    o=cisco
    o=com
  Subject:
    Name: R2.cisco.com
    IP Address: 192.168.0.2
    Serial Number: 101
    serialNumber=101+ipaddress=192.168.0.2+hostname=R2.cisco.com
    cn=R2
    ou=IT
    o=cisco
    o=com
  Validity Date:
    start date: 13:23:49 CET Jun 17 2013
    end   date: 13:23:49 CET Jun 17 2014
  Associated Trustpoints: IOSCA1
  Storage: nvram:CA1#2.cer
...
<output omitted, 1 more R2 cert signed by CA2, 2 more CA certs>

现在R2收到从R1的MM4数据包并且开始处理证书请求。第一证书请求有效负载匹配IOSCA2托拉斯点:


*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=CA2,o=cisco,o=com

*Jun 17 18:08:44.335:  Choosing trustpoint IOSCA2 as issuer
*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=CA1,o=cisco,o=com

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 ou=Class 3 Public Primary Certification Authority,o=VeriSign, Inc.,c=US

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco Root CA M1,o=Cisco

当R2准备MM5数据包时,使用用IOSCA2托拉斯点关联的证书:


*Jun 17 18:08:44.335: ISAKMP:(1100):SA is doing RSA signature authentication
 using id type ID_FQDN
*Jun 17 18:08:44.335: ISAKMP (1100): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R2.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
*Jun 17 18:08:44.335: ISAKMP:(1100):Total payload length: 20
*Jun 17 18:08:44.335: ISAKMP:(1100): IKE->PKI Get CertificateChain to be sent
 to peer state (I) MM_KEY_EXCH (peer 192.168.0.1)
*Jun 17 18:08:44.335: ISAKMP:(1100): PKI->IKE Got CertificateChain to be sent
 to peer state (I) MM_KEY_EXCH (peer 192.168.0.1)
*Jun 17 18:08:44.336: ISAKMP (1100): constructing CERT payload for
 serialNumber=101+ipaddress=192.168.0.2+hostname=R2.cisco.com,cn=R2,
 ou=IT,o=cisco,o=com

R2#
*Jun 17 18:08:44.336: ISAKMP:(1100): using the IOSCA2 trustpoint's
 keypair to sign

*Jun 17 18:08:44.336: ISAKMP:(1100): sending packet to 192.168.0.1
 my_port 500 peer_port 500 (I) MM_KEY_EXCH
*Jun 17 18:08:44.336: ISAKMP:(1100):Sending an IKE IPv4 Packet.

MM5数据包由R1接收。由于R1委托仅IOSCA1托拉斯点(ISAKMP简档prof1),证书确认发生故障:


*Jun 17 18:08:44.337: ISAKMP (1100): received packet from 192.168.0.2
 dport 500 sport 500 Global (R) MM_KEY_EXCH
*Jun 17 18:08:44.337: ISAKMP:(1100):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 17 18:08:44.337: ISAKMP:(1100):Old State =IKE_R_MM4  New State = IKE_R_MM5

*Jun 17 18:08:44.337: ISAKMP:(1100): processing ID payload. message ID = 0
*Jun 17 18:08:44.337: ISAKMP (1100): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R2.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
*Jun 17 18:08:44.337: ISAKMP:(0):: peer matches prof1 profile
*Jun 17 18:08:44.337: ISAKMP:(1100): processing CERT payload. message ID = 0
*Jun 17 18:08:44.337: ISAKMP:(1100): processing a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.337: ISAKMP:(1100): IKE->PKI Add peer's certificate state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: CRYPTO_PKI: (900C5) Adding peer certificate
*Jun 17 18:08:44.337: ISAKMP:(1100): PKI->IKE Added peer's certificate state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: ISAKMP:(1100): IKE->PKI Get PeerCertificateChain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: ISAKMP:(1100): PKI->IKE Got PeerCertificateChain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: ISAKMP:(1100): peer's pubkey isn't cached
*Jun 17 18:08:44.337: ISAKMP:(1100):Profile has no keyring, aborting key search
*Jun 17 18:08:44.337: ISAKMP:(0): Creating CERT validation list: IOSCA1,
*Jun 17 18:08:44.337: ISAKMP:(1100): IKE->PKI Validate certificate chain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: CRYPTO_PKI:ip-ext-val:IP extension validation not required
*Jun 17 18:08:44.341: CRYPTO_PKI: (900C5) Check for identical certs
*Jun 17 18:08:44.341: CRYPTO_PKI: (900C5) Create a list of suitable trustpoints
*Jun 17 18:08:44.341: CRYPTO_PKI: (900C5) No suitable trustpoints found
*Jun 17 18:08:44.341: ISAKMP:(1100): PKI->IKE Validate certificate chain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.341: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from
 192.168.0.2 is bad: unknown error returned in certificate validation

R1#
*Jun 17 18:08:44.341: ISAKMP:(1100): Unknown error in cert validation, -1

此配置工作,如果证书登记的顺序在R1的不同的,因为第一显示的证书由IOSCA1托拉斯点签字。并且,在MM4的第一证书请求有效负载是IOSCA1托拉斯点,由R2在MM6的R1然后选择并且顺利地验证。


没有ca trust-point In命令的IKEv1配置文件

对于方案,因为没有ca trust-point命令配置,取决于的特定托拉斯点的验证用多配置文件和托拉斯点,但是没有在配置文件的一特定托拉斯点配置,没有问题。然而,选择过程也许不是显然的。从属在是发起者的路由器,另外证书为认证过程选择关于证书登记顺序。

有时证书只可以由连接的一端支持,例如在x509版本1,不是一个典型的散列函数使用为了签字。VPN通道也许从连接的一端仅设立。


IKEv1的RFC参考

这是从RFC4945的一截取:

3.2.7.1. 指定证书颁发机构

请求密钥材料时在波段之内交换,实施应该生成每个对等体信任锚点的CERTREQs在给的交换期间,本地策略明确地视为委托。

RFC不是确切。本地策略也许与在crypto isakmp profile配置的ca trust-point命令明确地关连。问题是那在进程的MM3和MM4阶段,您不能选择ISAKMP简档,除非使用一个IP地址标识和托拉斯点,因为在MM5的验证和进程的MM6阶段必须首先出现。为此,本地策略与在设备配置的所有托拉斯点明确地关连。


注意:此信息不CISCO专用,但是它是IKEv1-specific。


IKEv2配置文件选择以交迭的标识

在IKEv2的多份证书描述前,认识配置文件选择的方法是重要的,当使用时匹配标识,为所有配置文件是满足的。因为IKEv2协商的结果取决于多个要素,这不是一个推荐的方案。同样问题为IKEv1存在,当交迭时使用的配置文件。

这是示例IKEv2发起者配置:


crypto ikev2 proposal prop-1 
 encryption 3des
 integrity md5
 group 2
!
crypto ikev2 policy pol-1
 match fvrf any
 proposal prop-1
!
crypto ikev2 profile profile1
 match identity remote address 192.168.0.2 255.255.255.255
 identity local address 192.168.0.1
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1

crypto ipsec transform-set trans esp-3des esp-sha-hmac
 mode tunnel
!
crypto ipsec profile profile1
 set transform-set trans
 set ikev2-profile profile1
!
interface Loopback0
 ip address 192.168.100.1 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile profile1
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0

ip route 192.168.200.1 255.255.255.255 10.0.0.2

标识类型地址使用连接的两边。验证通过证书(可以也是预先共享密钥)对此示例不是重要。响应方有多配置文件该所有匹配入站IKEv2流量:


crypto ikev2 proposal prop-1 
 encryption 3des
 integrity md5
 group 2
!
crypto ikev2 policy pol-1
 match fvrf any
 proposal prop-1
!
crypto ikev2 profile profile1
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1
!
crypto ikev2 profile profile2
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1
!
crypto ikev2 profile profile3
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1

crypto ipsec transform-set trans esp-3des esp-sha-hmac
 mode tunnel
!
crypto ipsec profile profile1
 set transform-set trans
 set ikev2-profile profile1
!
interface Loopback0
 ip address 192.168.200.1 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile profile1
!
interface Ethernet0/0
 ip address 192.168.0.2 255.255.255.0

ip route 192.168.100.1 255.255.255.255 10.0.0.1

发起者发送第三IKEv2数据包,并且响应方必须选择根据接收的标识的配置文件。标识是IPv4地址(192.168.0.1) :


IKEv2:(SA ID = 1):Searching policy based on peer's identity '192.168.0.1' of
 type 'IPv4 address'

所有配置文件满足此标识由于配置的匹配标识命令。IOS选择最后一个在配置里,是在本例中的profile3


IKEv2:found matching IKEv2 profile 'profile3'

为了验证命令,请输入profile命令的显示crypto ikev2


注意:既使当有一个通用的地址(0.0.0.0)在配置文件,仍然选择。IOS不尝试查找佳匹配;它设法查找第一匹配。然而,因为所有配置文件有配置的同样匹配标识remote command这只发生。对于有不同的匹配标识规则的IKEv1和IKEv2配置文件,总是使用多数特定一个。思科建议您没有配置文件配置以重叠匹配标识发出命令,因为预测选择的配置文件是很难的。 


在此方案中, profile3由响应方选择,但是profile1使用隧道接口。当代理ID协商时,这造成一个错误出现:


*Jul 17 09:23:48.187: map_db_check_isakmp_profile profile did not match
*Jul 17 09:23:48.187: map_db_find_best did not find matching map
*Jul 17 09:23:48.187: IPSEC(ipsec_process_proposal):
 proxy identities not supported
*Jul 17 09:23:48.187: IKEv2:(SA ID = 1):There was no
 IPSEC policy found for received TS
*Jul 17 09:23:48.187: IKEv2:(SA ID = 1):
*Jul 17 09:23:48.187: IKEv2:(SA ID = 1):Sending TS unacceptable notify

当使用时, IKEv2流证书

当证书用于IKEv2为了验证时,发起者不发送在第一数据包的证书请求有效负载:


IKEv2 IKE_SA_INIT Exchange REQUEST 
Payload contents:
 SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP)
 NOTIFY(NAT_DETECTION_DESTINATION_IP)

响应方应答与证书请求有效负载(第二数据包)和所有CA,因为响应方不了解应该在此阶段使用的配置文件。包含信息的数据包发送对发起者:


IKEv2 IKE_SA_INIT Exchange RESPONSE 
Payload contents:
 SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY
 (NAT_DETECTION_DESTINATION_IP) CERTREQ NOTIFY(HTTP_CERT_LOOKUP_SUPPORTED)

发起者处理数据包并且选择匹配报价的CA:的托拉斯点


IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s) from
 received certificate hash(es)
IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved trustpoint(s): 'TP1' 

发起者然后发送有证书请求和证书有效负载的第三数据包。此数据包用从Diffie-Hellman (DH)相位的密钥材料已经加密:


IKEv2:(SA ID = 1):Building packet for encryption.  
Payload contents:
 VID IDi CERT CERTREQ NOTIFY(HTTP_CERT_LOOKUP_SUPPORTED) AUTH CFG SA TSi
 TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT)
 NOTIFY(NON_FIRST_FRAGS)

第四数据包从响应方发送到发起者并且包含仅证书有效负载:


IKEv2 IKE_AUTH Exchange RESPONSE 
Payload contents:
 VID IDr CERT AUTH SA TSi TSr NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT)
NOTIFY(NON_FIRST_FRAGS)

描述的流此处类似于IKEv1流。响应方必须发送证书请求有效负载在最前面,不用应该使用,制造同样问题为IKEv1以前描述配置文件的知识(从协议方面)。然而,在IOS的实施为IKEv2是好比对于IKEv1。


IKEv2发起者的必须托拉斯点

这是示例,当IKEv2发起者尝试以证书验证使用配置文件并且没有托拉斯点配置在该配置文件下时:


crypto ikev2 profile profile1
 match identity remote address 192.168.0.2 255.255.255.255
 identity local address 192.168.0.1
 authentication remote rsa-sig
 authentication local rsa-sig

第一数据包发送,不用任何证书请求有效负载,如前所述。从响应方的答复包括在全局配置模式定义的所有的证书请求有效负载托拉斯点。这由发起者接收:


*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)

*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP1'   

*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: Trust-Point TP1 picked up
*Jul 17 17:40:43.183: CRYPTO_PKI: 1 matching trustpoints found
*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)

*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP2'   

*Jul 17 17:40:43.183: CRYPTO_PKI: Trust-Point TP2 picked up
*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: 1 matching trustpoints found
*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):Failed to build certificate payload

发起者不认识应该使用为了签字的托拉斯点。当IKEv2实施与IKEv1比较时,这是主要区别。IKEv2发起者必须有托拉斯点配置在IKEv2发起者配置文件下,但是为IKEv2响应方不是必要的。

以下摘自命令参考:

如果没有在IKEv2配置文件配置里定义的信任点,默认是验证证书使用在全局配置里定义的所有信任点

定义不同的托拉斯点是可能的;一为了签字和一另外一个为了验证。不幸地,配置在IKEv2配置文件下的必须托拉斯点不解决所有问题。


R2作为IKEv2发起者

在本例中, R2是IKEv2发起者:


crypto ikev2 profile profile1
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1
 pki trustpoint TP2

在本例中, R1是IKEv2响应方:


crypto ikev2 profile profile1
 match identity remote address 192.168.0.2 255.255.255.255
 identity local address 192.168.0.1
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1

这里, R2发送第一数据包,不用任何证书请求。响应方回应所有的证书请求已配置的托拉斯点。有效载荷的定货类似于IKEv1并且取决于安装的证书:


R1#show crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 04
  Certificate Usage: General Purpose
  Issuer:
    cn=CA2
....
 Associated Trustpoints: TP2

在R1的第一已配置的证书用用TP2托拉斯点关联的TP2托拉斯点关联,因此第一证书请求有效负载是为CA。因此, R2为验证(第一个匹配规则)选择它:


R2#
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):Processing IKE_SA_INIT message
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP2'   
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Getting cert chain for
 the trustpoint TP2

*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[PKI -> IKEv2] Getting of cert chain
 for the trustpoint PASSED

然后, R2准备答复(关联与TP2有证明请求有效负载的数据包3)。因为为TP1托拉斯点的验证配置R1不能委托证书:


*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP1'   

*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Getting cert chain for
 the trustpoint TP1
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[PKI -> IKEv2] Getting of cert chain
 for the trustpoint PASSED
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):Get peer's authentication method
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):Peer's authentication method is 'RSA'
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Validating
 certificate chain
*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):[PKI -> IKEv2] Validation of certificate
 chain FAILED

*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):Verification of peer's authentication
 data FAILED

*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):Sending authentication failure notify
*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):Building packet for encryption.  
Payload contents:
 NOTIFY(AUTHENTICATION_FAILED)

如前所提及,思科建议您不使用多个托拉斯点在一IKEv2配置文件以下。当您使用多个托拉斯点时,保证是必要的两边委托同一个托拉斯点。例如, R1和R2有配置的TP1和TP2在他们的配置文件。


摘要

此部分提供在本文描述信息的摘要。

证书请求有效负载内容取决于配置。如果一个特定托拉斯点为ISAKMP简档配置,并且路由器是ISAKMP发起者,则在用托拉斯点关联的MM3的证书请求包含仅CA。然而,如果同一路由器是ISAKMP响应方,然后由路由器发送的MM4数据包包括多份证书所有的请求有效载荷全局定义的托拉斯点(当ca trust-point命令没有被考虑到)时。这发生,因为ISAKMP响应方能确定应该使用的ISAKMP简档,在收到MM5和在MM4包括的证书请求之后。

在MM3和MM4的证书请求有效负载是重要由于第一个匹配规则。第一个匹配规则确定使用证书选择,为在MM5和MM6的验证是需要的托拉斯点。

证书请求有效负载命令取决于大约安装的证书。在certificate命令显示crypto的pki输出中出现第一证书的发布者首先发送。此第一证书是登记的最后一个。

配置ISAKMP简档的多个托拉斯点是可能的。如果这执行,则所有上一个规则仍然适用。

在本文描述的所有问题和警告归结于IKEv1协议设计。认证阶段在MM5和MM6发生,而必须发送提议对于验证(证书请求)在早期(在最前面),不用应该使用ISAKMP简档的知识。这不是一CISCO专用的问题和与IKEv1协议设计的限制涉及。

IKEv2协议类似于IKEv1关于证书协商进程。然而,在IOS的实施强制使用发起者的特定托拉斯点。这不解决所有问题。当多个托拉斯点为单个配置文件时配置,并且一个托拉斯点在另一侧配置,遇到与验证的问题是可能的。思科建议您使用对称托拉斯点配置连接(为两个配置的同样托拉斯点的两边IKEv2配置文件)。

这是关于在本文描述的信息的一些重要提示:

  • 使用对等体IKEv1档案的不对称托拉斯点配置,通道只也许从通道的一端启动。IKEv1配置文件的托拉斯点配置可选。

  • 使用对等体IKEv2档案的不对称托拉斯点配置,通道只也许从通道的一端启动。IKEv2配置文件的托拉斯点配置对于发起者是必需的。

  • 证书请求有效负载命令取决于大约在certificate命令显示crypto的pki输出中出现的证书(第一匹配)。

  • 证书请求有效负载命令确定由响应方的证书(第一匹配)选择。

  • 当您使用多配置文件IKEv1和IKEv2并且安排同样匹配标识规则配置时,是很难的预测结果(介入的许多要素)。

  • 思科建议您使用对称托拉斯点配置IKEv1和IKEv2。

相关信息


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 117633