But the new CRL is not getting checked even if the SA is being brought down and being re-established.
The old CRL, however does seems to be getting checked and since the peer cert is not revoked in it the cert status is classified as good: May 27 01:14:42 localhost charon: 05[CFG] checking certificate status of "C=RV, ST=zzzzzzzzzzz, L=zzzzzzzzzzz, O=zzzzzzzzzzz, OU=zzzzzzzzzzz, CN=1.1.1.1, CN=0047092009000003, CN=00000000, CN=rsa-key, CN=zzzzzzzzzzzzzzz, CN=zzzzzzzzzzzz" May 27 01:14:42 localhost charon: 05[CFG] using trusted certificate "C=IN, CN=ACMRootCA, O=Aricent" May 27 01:14:42 localhost charon: 05[CFG] crl correctly signed by "C=IN, CN=ACMRootCA, O=Aricent" May 27 01:14:42 localhost charon: 05[CFG] crl is valid: until Jul 25 01:43:55 2015 May 27 01:14:42 localhost charon: 05[CFG] using cached crl May 27 01:14:42 localhost charon: 05[CFG] certificate status is good BR Sajal On Tue, May 26, 2015 at 9:14 PM, Noel Kuntze <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, > > strongswan checks crls and other certificate status stuff only when the > peer initially > connects or when it reauthenticates. > > Mit freundlichen Grüßen/Kind Regards, > Noel Kuntze > > GPG Key ID: 0x63EC6658 > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > > Am 26.05.2015 um 17:42 schrieb Sajal Malhotra: > > Hi Noel, > > > > Sorry for incorrect update. I think the CRLs are being read into the > cache with the command. However while the SA is established only the Old > CRL is being referred to and not the new one (which has the Peer's cert > revoked) > > > > Attached are logs for your reference. > > > > BR > > Sajal > > > > On Tue, May 26, 2015 at 5:02 PM, Sajal Malhotra <[email protected] > <mailto:[email protected]>> wrote: > > > > Hi Noel, > > > > Thanks for a quick reply. > > "ipsec rereadcrls" and "ipsec stroke rereadcrls" both don't have any > effect. > > I guess both are same commands only. > > > > PS: We tried it on v5.2.2 > > > > BR > > Sajal > > > > > > On Tue, May 26, 2015 at 4:11 PM, Noel Kuntze <[email protected] > <mailto:[email protected]>> wrote: > > > > > > Hello, > > > > Did you try using "ipsec stroke rereadcrls"? > > > > Mit freundlichen Grüßen/Kind Regards, > > Noel Kuntze > > > > GPG Key ID: 0x63EC6658 > > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > > > > Am 26.05.2015 um 12:39 schrieb Sajal Malhotra: > > > Dear Strongswan team, > > > > > We are facing similar problem as reported by Shobhit here. > > > 1. We had a CRL say "abc.pem" that was present in /etc/ipsec.d/crls. > This was loaded correctly by Strongswan stack > > > 2. However before the Nextupdate time expired, we got an updated CRL > with certificate of peer revoked in it > > > 3. Placed this updated CRL with same name "abc.pem" in same directory > /etc/ipsec.d/crls and then executed "ipsec rereadcrls". > > > > > However it is noticed that Strongswan does not loads this CRL > immediately. It only does that only after NextUpdate time of old CRL has > expired. > > > Is there any way to force strongswan to reload the CRL file with same > name but updated contents? > > > > > I mean this could be very much possible that a CA issues a new CRL > before its NextUpdate time and then different Nodes should be able to take > this CRL into use. Isn't it? > > > > > BR > > > Sajal > > > > > > > > > > > On Mon, Jan 27, 2014 at 8:10 PM, shobhit shingla < > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>> wrote: > > > > > > > Hi, > > > > > Here is the scenario > > > > > IPSEC CRL is present in /etc/ipsec.d/crls for revoked certificate > of other side. > > > IPSEC tunnel is not established since certificate is revoked. > > > > > Now remove CRL file from /etc/ipsec.d/crls/ and run these commands > > > > > ipsec purgecrls > > > ipsec rereadcrls > > > > > Expected behaviour - > > > IPSEC CRL cache should be flushed after purgecrls > > > > > Now when ipsec rereadcrls is invoked, as now there are no crls in > /etc/ipsec.d/crls, there should be no CRLs in the ipsec and hence ipsec > listcrls should be empty. > > > > > Also IPSEC tunnel should now get established without restarting > ipsec. > > > > > > > Actual behaviour > > > ipsec purgecrls command does not flush the CRL cache. This we have > verified using ipsec listcrls commands after flushing. > > > > > ipsec tunnel is not established after crl is removed without > restart. > > > > > > > > > > > Thanks and regards, > > > Shobhit > > > > > _______________________________________________ > > > Users mailing list > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > https://lists.strongswan.org/mailman/listinfo/users > > > > > > > > > > > _______________________________________________ > > > Users mailing list > > > [email protected] <mailto:[email protected]> > > > https://lists.strongswan.org/mailman/listinfo/users > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJVZJTIAAoJEDg5KY9j7GZYsrAP+wQSGSgpb58qqN+tm2Sp1y21 > bmWClQv5xcEBgLA25TYwlZMZ4T6Qzww2WzlfVps3BAV2TLk4okRdIZjjDXLuY53H > c2ynXKAjU2j+tHzRSc0ZYcOU2ErkRLvHtgC2z5mceA2PkB7hqyUXUZZuPK3+c0ij > XvhSaY8yespgrPPy6YJVswtIyolbdbs+z7+U1SJWA0rbUntdowgzyhmVAGuQ7X/f > 4qkUsOPyr4QImbXN02lHQb7F9jqjocwHmlmn80HKwThQ4ERkojTTelDk4mM3OE9B > kHWR6+Upbn0XYS69mOVY4hxkHLm6m3KRf94rcX8AtYiwncvqBVxqv8y3Gg43IryO > cVX1NQOHTxKfBJQsOEOB2EFr/huULoopHzew9hUMGVBF84Wr1jKxoP3MkFP34LsC > a4emhdH+WBiZYNfBMfu0201ZJprVrlqmsh770KiezarShQYivE2mxuKx1/YyGCJX > DyjPuELjKmSxiP2UGNB8/tVa6M1BU23EjcF4421gap538cCZSmlHoLB+lXfevbcf > 0L9uYJDUARDe1MOLi9OagNUaMrVMkRlJA1zrffvsFPYVljapPLUu8GgH35WgC1b3 > MndyfhD8B/sVr2Rm13pEJ8zNGK3ropXKMkjz6XjXvj8aRb8vrIbj4IALm5A9itNg > JTNVPJHJH1xczRFYNM0l > =ccZa > -----END PGP SIGNATURE----- > >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
