Thank you for the thorough reply. I have 2 followup questions for the group
"When hostname is used as identity, the ASA and VPN client tries to compare the IKE ID with the Alt Subject name which is present in the x.590v3's extesion field" "Now the ASA and VPN client, expects the IKE ID to be subset of the subject name present in the cert" So, depending on what the content of the IKE ID is, the ASA compares it against EITHER the subject alternative name OR the subject name? Regarding peer-id-validate -- Of course I read the command reference on it. The problem is "cert: if supported by certificate" doesn't tell you anything about it. It seems like if you add the command "peer-id-validate cert" it gets around the strict cert checking so I'm not sure how that relates to the command reference description of "if supported" On Thu, Mar 8, 2012 at 6:11 AM, Kingsley Charles <[email protected]> wrote: > When hostname is used as identity, the ASA and VPN client tries to compare > the IKE ID with the Alt Subject name which is present in the x.590v3's > extesion field. For some reason, IOS CA server doesn't add it while you can > see MS CA server doing it. Since, it is not present, ASA and VPN client > rejects the cert from IOS peers which by default sends hostname as identity > when certs are used for authentication. Remember, both ASA and VPN client > sends dn as the identity by default and also IOS doesn't do a strict > validation like ASA or VPN client. > > Now when type dn is used on the IOS peer router, though we configured > nothing in the subject name, the IOS router adds a unstructed hostname in > certificate request and thus the dn will have this unstructed name. > > Now the ASA and VPN client, expects the IKE ID to be subset of the subject > name present in the cert which is what in reality and this validation > passes. Even, if you add some structured x.509 names like cn, o, ou the > result will be same as the dn will be always equal to IKE ID. > > > > Regarding, the followinf snippet will answer your question > > Snippet from > http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/p.html#wp1914829 > > > peer-id-validate > > To specify whether to validate the identity of the peer using the peer's > certificate, use the peer-id-validate command in tunnel-group > ipsec-attributes mode. To return to the default value, use the no form of > this command. > > peer-id-validate option > > no peer-id-validate > Syntax Description > > option > > > Specifies one of the following options: > > •req: required > > •cert: if supported by certificate > > •nocheck: do not check > > > With regards > Kings > > On Thu, Mar 8, 2012 at 1:08 PM, Joe Astorino <[email protected]> > wrote: >> I think I have read every possible thing I can about this on the >> internet but am still confused. Forgive me if this has been discussed >> to death previously. >> >> When we build L2L IPSEC between a router and ASA with RSA signature >> authentication it will often fail because the ASA cannot validate the >> IKE ID sent by the IOS router against the subject alternative name >> field in the IOS router digital cert. This is often because the >> subject alternate name field is not inserted into a cert issued by IOS >> CA and thus does not exist. >> >> One way to get around this is to change the IKE ID sent by the IOS >> router to the cert DN using "crypto isakmp identity dn" >> >> I get that...so we are sending the DN as the IKE ID instead of the >> default hostname. How does that effect what field in the cert the ASA >> checks though? I mean regardless of what I send in the IKE ID it seems >> the ASA is still going to compare whatever is sent with the subject >> alternative name in the certificate which STILL doesn't exist. Nothing >> I put in the IKE ID should change the fact that the subject alt name >> field is still empty. >> >> That is not what happens though as changing the IKE ID to DN solves the >> problem. >> >> I can only conclude that when we send DN as the IKE ID the ASA either >> does not check the subject alternate name field against the IKE ID but >> instead checks something else like the DN. When we set the IKE ID to >> DN does the ASA magically compare that to some other field in the >> certificate instead of subject alt name? >> >> I get that this fixes the problem I just don't fully get why. >> >> The other fix is to disable "peer-id-validate" on the ASA or set it to >> "peer-id-validate cert" as opposed to the default "req" option. The >> first option makes sense -- disable the check. The second doesn't. >> From what I understand the cert option uses digital certificates if >> available and if not allows the tunnel group to fall back to PSK >> (Richard Deal). I don't get at all how that makes the ASA either not >> check the subject alt name at all or check some other field in the >> certificate instead against the IKE ID from the router >> >> Any help is appreciated guys >> >> >> >> -- >> Sent from my mobile device >> >> Regards, >> >> Joe Astorino >> CCIE #24347 >> http://astorinonetworks.com >> >> "He not busy being born is busy dying" - Dylan >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com > -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
