[strongSwan] CRL check: how to fail over to local CRL if fetch fails
uid000 at gmail.com
Fri Apr 21 19:32:04 CEST 2017
I'm not sure why the CRL loaded from from /etc/ipsec.d/crls isn't
being checked during authentication. It's definitely cached in memory
according to 'ipsec listcrls'
However, I've added a ca section to ipsec.conf, listing the exact same
crl, but with a file:/// url:
crluri = file:///etc/ssl/mydomain.org/ca2.mydomain.org.crl.pem
I turned up logging, and I see an attempt to fetch that CRL during
each authentication attempt:
Apr 21 09:55:10 geonosis ipsec: 09[CFG] fetching crl from
Apr 21 09:55:10 geonosis ipsec: 09[LIB] sending http request
Apr 21 09:55:10 geonosis ipsec: 09[CFG] crl fetching failed
I've verified the file is world readable. I can cat it, and I can curl the uri.
I've also tried converting it to der format.
So, it seems there are two questions:
Why is the CRL loaded from /etc/ipsec.d/crls/, but not consulted?
Why is the curl plugin unable to fetch the local CRL from the file:/// uri?
On Fri, Apr 21, 2017 at 9:25 AM, Zach Cutlip <uid000 at gmail.com> wrote:
> Anything in particular I should be looking for in the logs? I
> definitely see the CRL getting loaded from disk when I start the
> service. I also see in the logs the remote CRL fetch failing. Nothing
> is mentioned in the logs about the local CRL.
> On Fri, Apr 21, 2017 at 12:20 AM, Tobias Brunner <tobias at strongswan.org> wrote:
>> Hi Zach,
>>> Alternatively, is there a way to just ignore embedded CRL distribution
>>> points, and always use the local CRL?
>> If the revocation plugin finds a cached CRL (either previously fetched
>> or loaded manually) that's still valid it will use that and not fetch
>> any remote CRLs. Check the log for details on what's going on.
More information about the Users