<div dir="ltr">But the new CRL is not getting checked even if the SA is being brought down and being re-established.<div><br></div><div>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:</div><div><br><div class="gmail_extra">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"<div class="gmail_extra">May 27 01:14:42 localhost charon: 05[CFG] using trusted certificate "C=IN, CN=ACMRootCA, O=Aricent"</div><div class="gmail_extra">May 27 01:14:42 localhost charon: 05[CFG] crl correctly signed by "C=IN, CN=ACMRootCA, O=Aricent"</div><div class="gmail_extra">May 27 01:14:42 localhost charon: 05[CFG] crl is valid: until Jul 25 01:43:55 2015</div><div class="gmail_extra">May 27 01:14:42 localhost charon: 05[CFG] using cached crl</div><div class="gmail_extra">May 27 01:14:42 localhost charon: 05[CFG] certificate status is good</div><div class="gmail_extra"><br></div><div class="gmail_extra">BR</div><div class="gmail_extra">Sajal</div><div class="gmail_quote">On Tue, May 26, 2015 at 9:14 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Hello,<br>
<br>
</span>strongswan checks crls and other certificate status stuff only when the peer initially<br>
connects or when it reauthenticates.<br>
<span class=""><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>
<br>
</span><span class="">Am 26.05.2015 um 17:42 schrieb Sajal Malhotra:<br>
> Hi Noel,<br>
><br>
> 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)<br>
><br>
> Attached are logs for your reference.<br>
><br>
> BR<br>
> Sajal<br>
><br>
</span><span class="">> On Tue, May 26, 2015 at 5:02 PM, Sajal Malhotra <<a href="mailto:sajalmalhotra@gmail.com">sajalmalhotra@gmail.com</a> <mailto:<a href="mailto:sajalmalhotra@gmail.com">sajalmalhotra@gmail.com</a>>> wrote:<br>
><br>
> Hi Noel,<br>
><br>
> Thanks for a quick reply.<br>
> "ipsec rereadcrls" and "ipsec stroke rereadcrls" both don't have any effect.<br>
> I guess both are same commands only.<br>
><br>
> PS: We tried it on v5.2.2<br>
><br>
> BR<br>
> Sajal<br>
><br>
><br>
</span><span class="">> On Tue, May 26, 2015 at 4:11 PM, Noel Kuntze <<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a> <mailto:<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a>>> wrote:<br>
><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>
><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>> <mailto:<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>> <mailto:<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>
<span class="">> > <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
><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>
<span class="">> > <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
><br>
><br>
><br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
</span>iQIcBAEBCAAGBQJVZJTIAAoJEDg5KY9j7GZYsrAP+wQSGSgpb58qqN+tm2Sp1y21<br>
bmWClQv5xcEBgLA25TYwlZMZ4T6Qzww2WzlfVps3BAV2TLk4okRdIZjjDXLuY53H<br>
c2ynXKAjU2j+tHzRSc0ZYcOU2ErkRLvHtgC2z5mceA2PkB7hqyUXUZZuPK3+c0ij<br>
XvhSaY8yespgrPPy6YJVswtIyolbdbs+z7+U1SJWA0rbUntdowgzyhmVAGuQ7X/f<br>
4qkUsOPyr4QImbXN02lHQb7F9jqjocwHmlmn80HKwThQ4ERkojTTelDk4mM3OE9B<br>
kHWR6+Upbn0XYS69mOVY4hxkHLm6m3KRf94rcX8AtYiwncvqBVxqv8y3Gg43IryO<br>
cVX1NQOHTxKfBJQsOEOB2EFr/huULoopHzew9hUMGVBF84Wr1jKxoP3MkFP34LsC<br>
a4emhdH+WBiZYNfBMfu0201ZJprVrlqmsh770KiezarShQYivE2mxuKx1/YyGCJX<br>
DyjPuELjKmSxiP2UGNB8/tVa6M1BU23EjcF4421gap538cCZSmlHoLB+lXfevbcf<br>
0L9uYJDUARDe1MOLi9OagNUaMrVMkRlJA1zrffvsFPYVljapPLUu8GgH35WgC1b3<br>
MndyfhD8B/sVr2Rm13pEJ8zNGK3ropXKMkjz6XjXvj8aRb8vrIbj4IALm5A9itNg<br>
JTNVPJHJH1xczRFYNM0l<br>
=ccZa<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br></div></div></div>