<div dir="ltr">Hi Noel,<div><br></div><div>Thanks for a quick reply.</div><div>"ipsec rereadcrls" and "ipsec stroke rereadcrls" both don't have any effect.</div><div>I guess both are same commands only.</div><div><br></div><div>PS: We tried it on v5.2.2</div><div><br></div><div>BR</div><div>Sajal</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 4:11 PM, Noel Kuntze <span dir="ltr"><<a href="mailto:noel@familie-kuntze.de" target="_blank">noel@familie-kuntze.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hello,<br>
<br>
Did you try using "ipsec stroke rereadcrls"?<br>
<br>
Mit freundlichen Grüßen/Kind Regards,<br>
Noel Kuntze<br>
<br>
GPG Key ID: 0x63EC6658<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<span class=""><br>
Am 26.05.2015 um 12:39 schrieb Sajal Malhotra:<br>
> Dear Strongswan team,<br>
><br>
> We are facing similar problem as reported by Shobhit here.<br>
> 1. We had a CRL say "abc.pem" that was present in /etc/ipsec.d/crls. This was loaded correctly by Strongswan stack<br>
> 2. However before the Nextupdate time expired, we got an updated CRL with certificate of peer revoked in it<br>
> 3. Placed this updated CRL with same name "abc.pem" in same directory /etc/ipsec.d/crls and then executed "ipsec rereadcrls".<br>
><br>
> 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.<br>
> Is there any way to force strongswan to reload the CRL file with same name but updated contents?<br>
><br>
> 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>
><br>
> BR<br>
> Sajal<br>
><br>
><br>
><br>
><br>
</span><span class="">> On Mon, Jan 27, 2014 at 8:10 PM, shobhit shingla <<a href="mailto:coolshobhit7@gmail.com">coolshobhit7@gmail.com</a> <mailto:<a href="mailto:coolshobhit7@gmail.com">coolshobhit7@gmail.com</a>>> wrote:<br>
><br>
><br>
> Hi,<br>
><br>
> Here is the scenario<br>
><br>
> IPSEC CRL is present in /etc/ipsec.d/crls for revoked certificate of other side.<br>
> IPSEC tunnel is not established since certificate is revoked.<br>
><br>
> Now remove CRL file from /etc/ipsec.d/crls/ and run these commands<br>
><br>
> ipsec purgecrls<br>
> ipsec rereadcrls<br>
><br>
> Expected behaviour -<br>
> IPSEC CRL cache should be flushed after purgecrls<br>
><br>
> 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.<br>
><br>
> Also IPSEC tunnel should now get established without restarting ipsec.<br>
><br>
><br>
> Actual behaviour<br>
> ipsec purgecrls command does not flush the CRL cache. This we have verified using ipsec listcrls commands after flushing.<br>
><br>
> ipsec tunnel is not established after crl is removed without restart.<br>
><br>
><br>
><br>
><br>
> Thanks and regards,<br>
> Shobhit<br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
</span>> <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a> <mailto:<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a>><br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
<span class="">><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
<br>
</span>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQIcBAEBCAAGBQJVZE3MAAoJEDg5KY9j7GZYUpcP/R99eNMG5g1jkBmN9WTzmNLo<br>
4/E7VXjGB7kDTGnR7W0d+UNbq/uz1SY9KQEytzj24MuKB5YOzML/DBTGZPLJdVQ5<br>
k9MKblHP/9ZUxbf88yBnEaEV++rUhi9bbYiFccL6y41DRSj4WjsOiVlAczl9/cX2<br>
pyOzUsjpYm7iL/I2O0fTMMQIZGCl4Mcr6aUxSonSTeyQBepRx8dSnTCehw8ipHnG<br>
7BJNL53iV9o0pGTgQSvOkUojHUD/B7Td/vFFNWl4EKBOiRtDg00xCkhLhr6A7lQR<br>
BmuZ7furSFHWkliSrZuyk/PJXSeJP7c2XZ0LLpiqT56uekYK7bbVItCV6Rg14TrD<br>
T8aZxmPIFPhDWHG89lkGQ0uz1ZeIKr/1pKWp30brX3h/5Cpu1FcAiuJr1FaBbK0B<br>
gcu/HpDRg9tO7z0uJeKp8aqnSdQUARuLbT/Hi9mx9oj7gnVtK9ie+5X67w3EIvHK<br>
hZM2LB7s1UOfTZquMjLZOkPExbcdrgQNs9JU7YahWYC/gIy7HIJxv7fFt0fUAZZ9<br>
qlqN2AGAxItRRAhQjIGiQ6KWlZsFzlXxGcrPZS+A40m579WtqBrGpICfFIFnKQCf<br>
h8zPc8ttzPEWjeM20BXvV12BuGzdXhMLUMsHEKsbl+maBEQGuYjg0MzrnLQ2FfQb<br>
bse3V3hk0xKE87S35DM/<br>
=cvIJ<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br></div>