<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi Andreas,<br><br></div>Thanks for explaining the options available.<br><br></div>I will consider OCSP for future but for now I would like to be able to control CRL lifetime.<br>
<br></div>How do I reduce the lifetime of CRL with SS 5.X?<br><br></div>Can I force CRL update with the following command?<br></div> ipsec rereadcrls<br></div> does it require re-starting SS engine or ipsec update is sufficient to load the new CRL.<br>
<br><br></div>I appreciate your help as always.<br><br><br></div>Thanks!<br><br></div>Jordan.<br><div><div><div><div><div><div><div><div><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 6, 2013 at 3:41 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jordan,<br>
<br>
strongSwan will not try to fetch a fresh CRL before the nextUpdate<br>
time in the cached CRL hasn't expired. If you want to react faster<br>
then you either have to reduce the lifetime of the CRL down to<br>
one or two days or use the Online Certificate Status Protocol (OCSP)<br>
which gets you the real-time status during each IKE re-authentication.<br>
<br>
Regards<br>
<br>
Andreas<br>
<div class="im"><br>
On 04/05/2013 07:26 PM, yordanos beyene wrote:<br>
> Thanks Andreas for explaining the IKEv1 CRL changes with SS 5.0.1. I<br>
> have a better understanding of the overall changes but I still need some<br>
> clarity on how strongswan determines CRL is stale or not. If a CA<br>
> revokes a certificate  immediately after successful CRL fetch, how long<br>
> does it take for Strongswan to make the Certificate stale . How can such<br>
> problems be avoided?<br>
><br>
> Thanks!<br>
><br>
> Jordan.<br>
><br>
><br>
> On Thu, Apr 4, 2013 at 9:08 PM, Andreas Steffen<br>
</div>> <<a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a> <mailto:<a href="mailto:andreas.steffen@strongswan.org">andreas.steffen@strongswan.org</a>>><br>
<div class="im">> wrote:<br>
><br>
>     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>
</div>>     CN=<a href="mailto:carol@strongswan.org">carol@strongswan.org</a> <mailto:<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>>"  fetching crl<br>
<div class="im">>     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<br>
>     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><br>
</div>>     <mailto:<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>>' with RSA signature successful<br>
<div class="im">>       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>
</div>>     CN=<a href="mailto:carol@strongswan.org">carol@strongswan.org</a> <mailto:<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>>"<br>
<div class="im">>       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>
</div>>     CN=<a href="mailto:carol@strongswan.org">carol@strongswan.org</a> <mailto:<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>>"<br>
<div class="im">>       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<br>
>     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><br>
</div>>     <<a href="http://ldap.strongswan.org/cn=strongSwan" target="_blank">http://ldap.strongswan.org/cn=strongSwan</a>> Root CA,<br>
<div class="im">>     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<br>
>     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><br>
</div>>     <mailto:<a href="mailto:carol@strongswan.org">carol@strongswan.org</a>>' with RSA signature successful<br>
<div><div class="h5">>       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>
><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>
>     > //cachecrls = yes/<br>
>     ><br>
>     > /But based on the Strongswan IPsec conf documentation, I came to<br>
>     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>
>     > So for how long is the CRL cache valid with SS 5.0.X? How often<br>
>     does SS<br>
>     > fetch CRLs.<br>
>     ><br>
>     > With **/*/strictcrlpolicy = yes./*/<br>
>     > / What happens if CRL URI is not reachable.<br>
>     ><br>
>     > /<br>
>     > I appreciate your help!<br>
>     ><br>
>     > Thanks!<br>
>     ><br>
>     > Jordan./<br>
>     > /<br>
<br>
<br>
<br>
</div></div>--<br>
<div class=""><div class="h5">======================================================================<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>
</div></div></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div>