[strongSwan] Need help on "ipsec purgecrls"

Tue May 26 17:52:48 CEST 2015

But the new CRL is not getting checked even if the SA is being brought down
and being re-established.

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:

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"
May 27 01:14:42 localhost charon: 05[CFG]   using trusted certificate
"C=IN, CN=ACMRootCA, O=Aricent"
May 27 01:14:42 localhost charon: 05[CFG]   crl correctly signed by "C=IN,
CN=ACMRootCA, O=Aricent"
May 27 01:14:42 localhost charon: 05[CFG]   crl is valid: until Jul 25
01:43:55 2015
May 27 01:14:42 localhost charon: 05[CFG]   using cached crl
May 27 01:14:42 localhost charon: 05[CFG] certificate status is good

BR
Sajal
On Tue, May 26, 2015 at 9:14 PM, Noel Kuntze <noel at familie-kuntze.de> wrote:

>
> -----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-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150526/d387a3f0/attachment.html>