[strongSwan] Need help on "ipsec purgecrls"

[Noel Kuntze]

-----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 <sajalmalhotra at gmail.com <mailto:sajalmalhotra at gmail.com>> 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 <noel at familie-kuntze.de <mailto:noel at familie-kuntze.de>> 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 <coolshobhit7 at gmail.com <mailto:coolshobhit7 at gmail.com> <mailto:coolshobhit7 at gmail.com <mailto:coolshobhit7 at gmail.com>>> 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
> >     Users at lists.strongswan.org <mailto:Users at lists.strongswan.org> <mailto:Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>>
> >     https://lists.strongswan.org/mailman/listinfo/users
>
>
>
>
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> > 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-----