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

[Zach Cutlip]

Tobias,

You tipped me off to the problem. When I generate CRLs,
authKeyIdentifier wasn't included. The [crl_ext] was commented out by
default from the CA section of my openssl config file. Other services
were fine with it though, so I never realized it was missing. The
local CRL now gets checked.

I do wish I could figure out the file:/// problem though.
/usr/bin/curl has no problem fetching the CRL via the file URI, so I
don't suspect libcurl is the problem. Besides it's a default Debian
installation. Debian's libcurl should be pretty typical. Is there a
way to coax more information out of the logs about why the fetch is
failing?

After seeing:
09[LIB]   sending http request to 'file:///...'
All I see is "crl fetching failed."

The http request to file:// seems weird, though.

On Fri, Apr 21, 2017 at 11:29 AM, Tobias Brunner <tobias at strongswan.org> wrote:
> Hi Zach,
>
>> Why is the CRL loaded from /etc/ipsec.d/crls/, but not consulted?
>
> It is either not valid or does not apply when verifying the validity of
> the peer's certificate.  The lookup for cached CRLs is based on the
> subjectKeyIdentifier in the issuer certificate - which must match the
> authKeyIdentifier of the CRL - and then the cRLIssuer fields of any CDPs
> in the certificate that's verified.
>
>> Why is the curl plugin unable to fetch the local CRL from the file:/// uri?
>
> You need a fetcher plugin that is capable of fetching such URIs.  As
> Noel mentioned, the file plugin can do so (without external
> dependencies), and the curl plugin can do so too, depending on whether
> your build of libcurl supports it or not.
>
> Regards,
> Tobias
>



-- 
:wq!