<div dir="ltr"><div><div><div>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?<br>
<br></div></div></div><div>Thanks!<br><br></div><div>Jordan.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 9:08 PM, Andreas Steffen <span dir="ltr"><<a href="mailto:andreas.steffen@strongswan.org" target="_blank">andreas.steffen@strongswan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jordan,<br>
<br>
crlcheckinterval was needed by our old IKEv1 implementation because<br>
the pluto daemon had only a single working thread for handling<br>
connections which couldn't be put into a blocking state waiting<br>
for http or ldap requests to complete. Therefore a second thread<br>
was created which would asynchronously prefetch CRLs shortly before<br>
they became stale.<br>
<br>
strongSwan 5.x is fully multi-threaded and usually has about 8<br>
worker threads available for concurrently handling multiple<br>
connections. The validity of a CRL is examined on the fly and<br>
the corresponding thread blocks synchronously until a fresh CRL<br>
has been fetched from one of the CDPs. This usually takes less<br>
than 1-2 seconds so that no IKE packet retransmission occurs coming<br>
from the [impatient] initiator.<br>
<br>
crlcache=yes causes any newly fetched CRLs to be stored in<br>
/etc/ipsec.d/crls as the following example scenario shows:<br>
<br>
<a href="http://www.strongswan.org/uml/testresults/ikev2/crl-to-cache/" target="_blank">http://www.strongswan.org/uml/testresults/ikev2/crl-to-cache/</a><br>
<br>
Apr 4 19:22:43 moon charon: 04[CFG]<br>
checking certificate status of "C=CH, O=Linux strongSwan, OU=Research,<br>
CN=<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>" fetching crl from<br>
'<a href="http://crl.strongswan.org/strongswan.crl" target="_blank">http://crl.strongswan.org/strongswan.crl</a>' ...<br>
using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan<br>
Root CA"<br>
crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"<br>
crl is valid: until May 04 19:01:42 2013<br>
certificate status is good<br>
reached self-signed root ca with a path length of 0<br>
authentication of '<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>' with RSA signature successful<br>
written crl file<br>
'/etc/ipsec.d/crls/5da7dd700651327ee7b66db3b5e5e060ea2e4def.crl' (1214<br>
bytes)<br>
<br>
If the cached CRL has become stale, a fresh one is fetched on the fly<br>
as the following example scenario shows<br>
<br>
<a href="http://www.strongswan.org/uml/testresults/ikev2/crl-ldap/" target="_blank">http://www.strongswan.org/uml/testresults/ikev2/crl-ldap/</a><br>
<br>
Apr 4 19:22:26 moon charon: 00[CFG]<br>
loaded crl from<br>
'/etc/ipsec.d/crls/5da7dd700651327ee7b66db3b5e5e060ea2e4def.crl'<br>
<br>
Apr 4 19:22:28 moon charon: 02[CFG]<br>
using certificate "C=CH, O=Linux strongSwan, OU=Research,<br>
CN=<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>"<br>
using trusted ca certificate "C=CH, O=Linux strongSwan, CN=strongSwan<br>
Root CA"<br>
checking certificate status of "C=CH, O=Linux strongSwan, OU=Research,<br>
CN=<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>"<br>
using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan<br>
Root CA"<br>
crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"<br>
crl is stale: since Jul 20 21:40:37 2005<br>
fetching crl from 'ldap://<a href="http://ldap.strongswan.org/cn=strongSwan" target="_blank">ldap.strongswan.org/cn=strongSwan</a> Root CA,<br>
o=Linux strongSwan, c=CH?certificateRevocationList' ...<br>
using trusted certificate "C=CH, O=Linux strongSwan, CN=strongSwan<br>
Root CA"<br>
crl correctly signed by "C=CH, O=Linux strongSwan, CN=strongSwan Root CA"<br>
crl from Apr 04 19:01:42 2013 is newer - existing crl from Jul 20<br>
20:40:37 2005 replaced<br>
crl is valid: until May 04 19:01:42 2013<br>
certificate status is good<br>
reached self-signed root ca with a path length of 0<br>
authentication of '<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>' with RSA signature successful<br>
crl from Apr 04 19:01:42 2013 is newer - existing crl from Jul 20<br>
20:40:37 2005 replaced<br>
written crl file<br>
'/etc/ipsec.d/crls/5da7dd700651327ee7b66db3b5e5e060ea2e4def.crl' (1214<br>
bytes)<br>
<br>
I hope this helps<br>
<div class="im"><br>
On 04/05/2013 02:24 AM, yordanos beyene wrote:<br>
><br>
> Hi SS team,<br>
><br>
> I appreciate if some one can explain to me how CRL cache works with SS<br>
> 5.0.X.<br>
> I can no more use "crlcheckinterval" in my deployments.<br>
><br>
> I have enabled CRL caching as follows:<br>
</div>> //cachecrls = yes/<br>
><br>
> /But based on the Strongswan IPsec conf documentation, I came to know I<br>
> can no more use "crlcheckinterval " with SS 5.0.X/.<br>
><br>
> crlcheckinterval = *600 sec<br>
><br>
> */<br>
> Is there any alternative command to determine caching time*/?/*/*<br>
> */<br>
> /*<br>
> */<br>
<div class="im">> So for how long is the CRL cache valid with SS 5.0.X? How often does SS<br>
> fetch CRLs.<br>
><br>
</div>> With **/*/strictcrlpolicy = yes./*/<br>
> / What happens if CRL URI is not reachable.<br>
<div class="im">><br>
> /<br>
> I appreciate your help!<br>
><br>
> Thanks!<br>
><br>
</div>> Jordan./<br>
> /<br>
<br>
<br>
======================================================================<br>
Andreas Steffen <a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a><br>
strongSwan - the Linux VPN Solution! <a href="http://www.strongswan.org" target="_blank">www.strongswan.org</a><br>
Institute for Internet Technologies and Applications<br>
University of Applied Sciences Rapperswil<br>
CH-8640 Rapperswil (Switzerland)<br>
===========================================================[ITA-HSR]==<br>
<br>
</blockquote></div><br></div>