[strongSwan] CRL caching
Andreas Steffen
andreas.steffen at strongswan.org
Sat Apr 6 12:41:26 CEST 2013
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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4468 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130406/79d12840/attachment.bin>
More information about the Users
mailing list