[strongSwan] CRL caching
yordanos beyene
yordanosb at gmail.com
Mon Apr 8 22:41:04 CEST 2013
Hi Andreas,
Thanks for explaining the options available.
I will consider OCSP for future but for now I would like to be able to
control CRL lifetime.
How do I reduce the lifetime of CRL with SS 5.X?
Can I force CRL update with the following command?
ipsec rereadcrls
does it require re-starting SS engine or ipsec update is sufficient to
load the new CRL.
I appreciate your help as always.
Thanks!
Jordan.
On Sat, Apr 6, 2013 at 3:41 AM, Andreas Steffen <
andreas.steffen at strongswan.org> wrote:
> Hi Jordan,
>
> strongSwan will not try to fetch a fresh CRL before the nextUpdate
> time in the cached CRL hasn't expired. If you want to react faster
> then you either have to reduce the lifetime of the CRL down to
> one or two days or use the Online Certificate Status Protocol (OCSP)
> which gets you the real-time status during each IKE re-authentication.
>
> Regards
>
> Andreas
>
> On 04/05/2013 07:26 PM, yordanos beyene wrote:
> > Thanks Andreas for explaining the IKEv1 CRL changes with SS 5.0.1. I
> > have a better understanding of the overall changes but I still need some
> > clarity on how strongswan determines CRL is stale or not. If a CA
> > revokes a certificate immediately after successful CRL fetch, how long
> > does it take for Strongswan to make the Certificate stale . How can such
> > problems be avoided?
> >
> > Thanks!
> >
> > Jordan.
> >
> >
> > On Thu, Apr 4, 2013 at 9:08 PM, Andreas Steffen
> > <andreas.steffen at strongswan.org <mailto:andreas.steffen at strongswan.org>>
> > wrote:
> >
> > Hi Jordan,
> >
> > crlcheckinterval was needed by our old IKEv1 implementation because
> > the pluto daemon had only a single working thread for handling
> > connections which couldn't be put into a blocking state waiting
> > for http or ldap requests to complete. Therefore a second thread
> > was created which would asynchronously prefetch CRLs shortly before
> > they became stale.
> >
> > strongSwan 5.x is fully multi-threaded and usually has about 8
> > worker threads available for concurrently handling multiple
> > connections. The validity of a CRL is examined on the fly and
> > the corresponding thread blocks synchronously until a fresh CRL
> > has been fetched from one of the CDPs. This usually takes less
> > than 1-2 seconds so that no IKE packet retransmission occurs coming
> > from the [impatient] initiator.
> >
> > crlcache=yes causes any newly fetched CRLs to be stored in
> > /etc/ipsec.d/crls as the following example scenario shows:
> >
> > http://www.strongswan.org/uml/testresults/ikev2/crl-to-cache/
> >
> > Apr 4 19:22:43 moon charon: 04[CFG]
> > checking certificate status of "C=CH, O=Linux strongSwan,
> OU=Research,
> > CN=carol at strongswan.org <mailto:carol at strongswan.org>" fetching crl
> > from
> > 'http://crl.strongswan.org/strongswan.crl' ...
> > using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan
> > Root CA"
> > crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan
> > Root CA"
> > crl is valid: until May 04 19:01:42 2013
> > certificate status is good
> > reached self-signed root ca with a path length of 0
> > authentication of 'carol at strongswan.org
> > <mailto:carol at strongswan.org>' with RSA signature successful
> > written crl file
> > '/etc/ipsec.d/crls/5da7dd700651327ee7b66db3b5e5e060ea2e4def.crl'
> (1214
> > bytes)
> >
> > If the cached CRL has become stale, a fresh one is fetched on the fly
> > as the following example scenario shows
> >
> > http://www.strongswan.org/uml/testresults/ikev2/crl-ldap/
> >
> > Apr 4 19:22:26 moon charon: 00[CFG]
> > loaded crl from
> > '/etc/ipsec.d/crls/5da7dd700651327ee7b66db3b5e5e060ea2e4def.crl'
> >
> > Apr 4 19:22:28 moon charon: 02[CFG]
> > using certificate "C=CH, O=Linux strongSwan, OU=Research,
> > CN=carol at strongswan.org <mailto:carol at strongswan.org>"
> > using trusted ca certificate "C=CH, O=Linux strongSwan,
> CN=strongSwan
> > Root CA"
> > checking certificate status of "C=CH, O=Linux strongSwan,
> OU=Research,
> > CN=carol at strongswan.org <mailto:carol at strongswan.org>"
> > using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan
> > Root CA"
> > crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan
> > Root CA"
> > crl is stale: since Jul 20 21:40:37 2005
> > fetching crl from 'ldap://ldap.strongswan.org/cn=strongSwan
> > <http://ldap.strongswan.org/cn=strongSwan> Root CA,
> > o=Linux strongSwan, c=CH?certificateRevocationList' ...
> > using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan
> > Root CA"
> > crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan
> > Root CA"
> > crl from Apr 04 19:01:42 2013 is newer - existing crl from Jul 20
> > 20:40:37 2005 replaced
> > crl is valid: until May 04 19:01:42 2013
> > certificate status is good
> > reached self-signed root ca with a path length of 0
> > authentication of 'carol at strongswan.org
> > <mailto:carol at strongswan.org>' with RSA signature successful
> > crl from Apr 04 19:01:42 2013 is newer - existing crl from Jul 20
> > 20:40:37 2005 replaced
> > written crl file
> > '/etc/ipsec.d/crls/5da7dd700651327ee7b66db3b5e5e060ea2e4def.crl'
> (1214
> > bytes)
> >
> > I hope this helps
> >
> > On 04/05/2013 02:24 AM, yordanos beyene wrote:
> > >
> > > Hi SS team,
> > >
> > > I appreciate if some one can explain to me how CRL cache works
> with SS
> > > 5.0.X.
> > > I can no more use "crlcheckinterval" in my deployments.
> > >
> > > I have enabled CRL caching as follows:
> > > //cachecrls = yes/
> > >
> > > /But based on the Strongswan IPsec conf documentation, I came to
> > know I
> > > can no more use "crlcheckinterval " with SS 5.0.X/.
> > >
> > > crlcheckinterval = *600 sec
> > >
> > > */
> > > Is there any alternative command to determine caching time*/?/*/*
> > > */
> > > /*
> > > */
> > > So for how long is the CRL cache valid with SS 5.0.X? How often
> > does SS
> > > fetch CRLs.
> > >
> > > With **/*/strictcrlpolicy = yes./*/
> > > / What happens if CRL URI is not reachable.
> > >
> > > /
> > > I appreciate your help!
> > >
> > > Thanks!
> > >
> > > Jordan./
> > > /
>
>
>
> --
> ======================================================================
> Andreas Steffen andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130408/68dac7bf/attachment.html>
More information about the Users
mailing list