[strongSwan] CRL caching

Andreas Steffen andreas.steffen at strongswan.org
Fri Apr 5 06:08:39 CEST 2013


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 --------------
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/20130405/cf725a68/attachment.bin>


More information about the Users mailing list