Shawn,
Move the CA from the key server. In this scenario you are going to need 4 routers. One key server. One CA and the two group members. Or at least that will work for you as I am stating here. I have been unable to figure out a way to get the CA to install a certificate chain besides the root CA certificate which will not be used for key negotiation in my experience. Regards, Tyson Scott - CCIE #13513 R&S and Security Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Cell: +1.248.504.7309 Fax: +1.810.454.0130 Mailto: [email protected] Join our free online support and peer group communities: <http://www.IPexpert.com/communities> http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. From: [email protected] [mailto:[email protected]] On Behalf Of Shawn H Mesiatowsky Sent: Thursday, August 06, 2009 11:42 AM To: [email protected] Subject: [OSL | CCIE_Security] GetVPN and using digital certs I have to routers acting as GDOI members and I have on router acting as a key server. The routing acting as a key server is also a CA Here is my configs: key server and CA: crypto pki server IOSCA issuer-name c=CA,cn=iosca.digitalcortex.local,l=calgary grant auto database url flash: ! crypto pki trustpoint IOSCA revocation-check crl rsakeypair IOSCA !crypto isakmp policy 1 encr 3des group 2 ! ! crypto ipsec transform-set trans1 esp-3des esp-sha-hmac ! crypto ipsec profile get1 set transform-set trans1 ! crypto gdoi group group1 identity number 1 server local ! Incomplete unicast rekey configuration ! Rekey authentication is not configured rekey retransmit 10 number 2 rekey transport unicast sa ipsec 1 profile get1 match address ipv4 101 replay counter window-size 64 address ipv4 172.16.113.2 ! access-list 101 permit ip 0.0.0.0 255.255.255.0 0.0.0.0 255.255.255.0 GDOI members: crypto pki trustpoint IOSCA enrollment url http://172.16.113.2:80 revocation-check crl crypto isakmp policy 1 encr 3des group 2 ! crypto gdoi group group1 identity number 1 server address ipv4 172.16.113.2 ! ! crypto map mymap 10 gdoi set group group1 ! interface Serial0/0 ip address 172.16.2.2 255.255.255.0 encapsulation frame-relay frame-relay lmi-type cisco crypto map mymap The clocks are all syned with ntp and I was able to get certificates from the CA on the GDOI members. I think the issue I am having is due to the fact that the CA is on the same router as the key server. I would like to get this working. Is there something I must do to make the key server recognze the fact that the trustpoint is the router itself? Here is an expert from the logs on the key server. It seems the key server does not like the certificate supplied by the member router Aug 6 13:41:54.505: ISAKMP:(0): processing KE payload. message ID = 0 Aug 6 13:41:54.649: ISAKMP:(0): processing NONCE payload. message ID = 0 Aug 6 13:41:54.653: ISAKMP:(1004): processing CERT_REQ payload. message ID = 0 Aug 6 13:41:54.653: ISAKMP:(1004): peer wants a CT_X509_SIGNATURE cert Aug 6 13:41:54.653: ISAKMP:(1004): peer wants cert issued by c=CA,cn=iosca.digitalcortex.local,l=calgary Aug 6 13:41:54.653: ISAKMP:(1004): issuer name is not a trusted root. Aug 6 13:41:54.653: ISAKMP:(1004): processing vendor id payload Aug 6 13:41:54.653: ISAKMP:(1004): vendor ID is Unity Aug 6 13:41:54.657: ISAKMP:(1004): processing vendor id payload Aug 6 13:41:54.657: ISAKMP:(1004): vendor ID is DPD Aug 6 13:41:54.657: ISAKMP:(1004): processing vendor id payload Aug 6 13:41:54.657: ISAKMP:(1004): speaking to another IOS box! Aug 6 13:41:54.657: ISAKMP:received payload type 20 Aug 6 13:41:54.657: ISAKMP:received payload type 20 Aug 6 13:41:54.657: ISAKMP:(1004):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE Aug 6 13:41:54.657: ISAKMP:(1004):Old State = IKE_R_MM3 New State = IKE_R_MM3 Aug 6 13:41:54.661: ISAKMP (0:1004): constructing CERT_REQ for issuer c=CA,cn=iosca.digitalcortex.local,l=calgary Aug 6 13:41:54.665: ISAKMP:(1004): sending packet to 172.16.2.2 my_port 848 peer_port 848 (R) MM_KEY_EXCH Aug 6 13:41:54.665: ISAKMP:(1004):Sending an IKE IPv4 Packet. Aug 6 13:41:54.665: ISAKMP:(1004):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE Aug 6 13:41:54.665: ISAKMP:(1004):Old State = IKE_R_MM3 New State = IKE_R_MM4 Aug 6 13:41:55.150: ISAKMP (0:1004): received packet from 172.16.2.2 dport 848 sport 848 Global (R) MM_KEY_EXCH Aug 6 13:41:55.154: ISAKMP:(1004):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH Aug 6 13:41:55.154: ISAKMP:(1004):Old State = IKE_R_MM4 New State = IKE_R_MM5 Aug 6 13:41:55.154: ISAKMP:(1004): processing ID payload. message ID = 0 Aug 6 13:41:55.154: ISAKMP (0:1004): ID payload next-payload : 6 type : 2 FQDN name : 2651-b.digitalcortex.local protocol : 17 port : 848 length : 34 Aug 6 13:41:55.158: ISAKMP:(0):: peer matches *none* of the profiles Aug 6 13:41:55.158: ISAKMP:(1004): processing CERT payload. message ID = 0 Aug 6 13:41:55.158: ISAKMP:(1004): processing a CT_X509_SIGNATURE cert Aug 6 13:41:55.162: ISAKMP:(1004): peer's pubkey isn't cached Aug 6 13:41:55.166: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 172.16.2.2 is bad: CA request failed!
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
