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

[Tobias Brunner]

Hi Harri,

>>> Even on
>>> "ipsec rereadcrls" the new CRL was ignored.
>>
>> This reads CRLs from /etc/ipsec.d/crls, nothing else.  To flush the
>> in-memory cache use `ipsec purgecrls` (CRLs cached on disk have to be
>> deleted manually from the directory above, note that that requires a
>> restart).
>>
> 
> this is hard to anticipate. Running rereadcrls, why should I want to
> prefer the cached CRLs over the CRLs to be found in the net? To avoid
> a DNS lookup and a single web access?

You'd only run `rereadcrls` if you actually stored CRLs in that 
directory, in which case you probably updated them once you run that 
command.  On the other hand, if you generally fetch CRLs, there is no 
need to ever run that command, just run `purgecrls`.

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

Regards,
Tobias

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