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 <tob...@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! _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users