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
