-----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

Reply via email to