[strongSwan] CRL check: how to fail over to local CRL if fetch fails

[Zach Cutlip]

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[3172]: 09[CFG]   fetching crl from
'file:///etc/ssl/mydomain.org/ca2.mydomain.org.crl.pem' ...
Apr 21 09:55:10 geonosis ipsec[3172]: 09[LIB]   sending http request
to 'file:///etc/ssl/mydomain.org/ca2.mydomain.org.crl.pem'...
Apr 21 09:55:10 geonosis ipsec[3172]: 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:
> Tobias,
>
> 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.
>
> Thanks
>
>
> 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.
>>
>> Regards,
>> Tobias
>>
>
>
>
> --
> :wq!



-- 
:wq!