[strongSwan] How does strongswan handle renewed or expired CRLs?

[Manfred]

Hi all,

On 4/8/2022 10:41 AM, Tobias Brunner wrote:
> Hi Harri,
> 
[...]
> 
>> Typically the PKIs create a CRL for lets say 30 days. In case of 
>> emergency
>> a new CRL might be issued on the next day. How is strongswan supposed
>> to be notified about this emergency? There is no flow of information 
>> here.
> 
> I guess that's just how CRLs work (see [1]).  If you want quicker 
> revocation, use OCSP, delta CRLs that are released more often, or clear 
> the cache manually to load the updated CRL if you know this happened.
> 
>> I would suggest to invest into the web access at least once per day,
>> regardless when the CRL is supposed to expire. If the remote site is not
>> reachable, then we can fall back to the cached version.
> 
> We currently don't have the information when a CRL was fetched or cached 
> (as mentioned, there are multiple caches/credential sets that can 
> provide CRLs), so that's tricky to implement.  But I guess you could 
> cron `purgecrls` daily (there is no fallback to a previous CRL then, 
> though).  Regularly fetching the CRL manually and storing it in 
> /etc/ipsec.d/crls, followed by `rereadcrls` and `purgecrls`, might also 
> be an option.

FWIW, libreswan has a config parameter in ipsec.conf: 'crlcheckinterval' 
which sets the CRL fetch period from distribution points (see man 
ipsec.conf for details)
When doing so, it updates the local NSS database with any updated CRL, 
even if the ones already stored in the database are not expired yet.

FWIW (again) I agree with Harri's point, and I think something like 
crlcheckinterval could be a suggestion worth considering.


> 
> Regards,
> Tobias
> 
> [1] https://datatracker.ietf.org/doc/html/rfc5280#section-6.3.3