<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>