[strongSwan] How does strongswan handle renewed or expired CRLs?
tobias at strongswan.org
Fri Apr 8 10:41:38 CEST 2022
>>> 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
> 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 ). 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.
More information about the Users