[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