[strongSwan] Need help on "ipsec purgecrls"

[Sajal Malhotra]

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

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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>> 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>
> >     https://lists.strongswan.org/mailman/listinfo/users
> >
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org
> > https://lists.strongswan.org/mailman/listinfo/users
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVZE3MAAoJEDg5KY9j7GZYUpcP/R99eNMG5g1jkBmN9WTzmNLo
> 4/E7VXjGB7kDTGnR7W0d+UNbq/uz1SY9KQEytzj24MuKB5YOzML/DBTGZPLJdVQ5
> k9MKblHP/9ZUxbf88yBnEaEV++rUhi9bbYiFccL6y41DRSj4WjsOiVlAczl9/cX2
> pyOzUsjpYm7iL/I2O0fTMMQIZGCl4Mcr6aUxSonSTeyQBepRx8dSnTCehw8ipHnG
> 7BJNL53iV9o0pGTgQSvOkUojHUD/B7Td/vFFNWl4EKBOiRtDg00xCkhLhr6A7lQR
> BmuZ7furSFHWkliSrZuyk/PJXSeJP7c2XZ0LLpiqT56uekYK7bbVItCV6Rg14TrD
> T8aZxmPIFPhDWHG89lkGQ0uz1ZeIKr/1pKWp30brX3h/5Cpu1FcAiuJr1FaBbK0B
> gcu/HpDRg9tO7z0uJeKp8aqnSdQUARuLbT/Hi9mx9oj7gnVtK9ie+5X67w3EIvHK
> hZM2LB7s1UOfTZquMjLZOkPExbcdrgQNs9JU7YahWYC/gIy7HIJxv7fFt0fUAZZ9
> qlqN2AGAxItRRAhQjIGiQ6KWlZsFzlXxGcrPZS+A40m579WtqBrGpICfFIFnKQCf
> h8zPc8ttzPEWjeM20BXvV12BuGzdXhMLUMsHEKsbl+maBEQGuYjg0MzrnLQ2FfQb
> bse3V3hk0xKE87S35DM/
> =cvIJ
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150526/62e822e7/attachment.html>