Thanks Paul for the response . Able to establish "authenticated OE" between peers using libreswan 3.20 . Looks like , flag "p" for certificates created the mess. There were two flags "p" & "P" where former is to Prohibit ( explicitly distrust ) and later to Trust the peer. With the "P" for Certificates ., authenticated OE worked fine.
1] I was going through other thread about libreswan 3.22 & the check for subjectAltName in certificates. Is there any way (either through configuration/tweak) available to disable this check !? 2] As 3.20 worked for authenticated OE, do you still suggest >=3.22 to look for ? Would request to please point me to bug list (fixed) / enhancements added (in the context of OE) for 3.22 over 3.20 !? 3] Considering the FIPS mode - any inputs !? -Regards, Kesav. -----Original Message----- From: Paul Wouters [mailto:[email protected]] Sent: Monday, December 04, 2017 9:34 PM To: Kesava Vunnava (kesriniv) <[email protected]> Cc: [email protected] Subject: RE: [Swan] authenticated Opportunistic Encryption ! On Mon, 4 Dec 2017, Kesava Vunnava (kesriniv) wrote: > Subject: RE: [Swan] authenticated Opportunistic Encryption ! > Got rid of error mentioned in below mail. A new error popped up . Though > peer's certificate (public key) was there in nss DB , log was saying "no RSA > public key known for 10.77.123.171". > PFA "oe-certificate.conf" file for both hosts (CENTOS-171, CENTOS-172) . > Included the same configuration file in /etc/ipsec.conf. > > Dec 4 00:38:10: "private-or-clear#10.77.123.0/24"[1] ...10.77.123.171 > #1: private-or-clear#10.77.123.0/24 ESP/AH proposals for initiator: > 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED > 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;ESN=DISABLED > 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=D > ISABLED > 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=D > ISABLED 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED > (default) Dec 4 00:38:10: "private-or-clear#10.77.123.0/24"[1] > ...10.77.123.171 #3: EXPECTATION FAILED: r != NULL (in > ikev2_decode_peer_id_and_certs at ikev2.c:1390) This expectation shows that you are not running 3.22. Can you use 3.22 ? > Dec 4 00:38:10: "private-or-clear#10.77.123.0/24"[1] ...10.77.123.171 #3: no > RSA public key known for '10.77.123.171' If that is the remote IP then it seems you might be missing rightrsasigkey=%fromcert or the remote is not sending a CERT payload? (maybe try leftsendcert=always on the remote?) If you are using intermediate certs, perhaps you need sendca=all to send the intermediate CA's over IKE as well. > O/P of "certutil -L -d sql:/etc/ipsec.d/" - This command was executed on > "CENTOS-172" . Can see that Certificate for "CENTOS-171" was lying in nss DB. > ############################################## > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > CENTOS-CA CTu,u,u > CENTOS-172 pu,pu,pu > CENTOS-171 p,p,p I've never seen the p flag set/used ? > Also, can you please confirm me the tested/stable build for "authenticated > opportunistic encryption" !? Reason: The same certs/keys were working fine > for host-host tunnel . It's unable to find the RSA public key after loading > configuration for "private-or-clear" . That's odd. We recommend using 3.22 or 3.23rc1. > Also, from below O/P it looks for 171->172 an unique SPI identifier got > generated but from 172->171 the same was NOT happening. It was 0X0 . > > [root@CENTOS-171 ipsec.d]# ip xfrm state src 10.77.123.171 dst > 10.77.123.172 > proto esp spi 0x66e5c871 reqid 16397 mode tunnel > replay-window 0 > sel src 10.77.123.171/32 dst 10.77.123.172/32 src 10.77.123.172 > dst 10.77.123.171 > proto esp spi 0x00000000 reqid 0 mode transport > replay-window 0 > sel src 10.77.123.172/32 dst 10.77.123.171/32 proto udp sport > 7946 dport 7946 dev ens32 That should never happen. Can you run with plutodebug=all and see what's going on? Paul _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
