[strongSwan] CRL caching

[yordanos beyene]

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> 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"  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' 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"
>   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"
>   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 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' 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/20130405/25c95fe0/attachment.html>