Noel, No, I don't seem to have the files plugin. I see that it is new as of strongswan 5.3.0. I'm running Debian Jessie which ships strongswan 5.2.1. I don't see any package providing this plugin.
Shouldn't fetching from file:/// work prior to 5.3.0? I see examples in google searches of CRLs being successfully loaded via file:///. In any case, the CRL is being loaded automatically at startup from /etc/ipsec.d/crls/. I wonder why it's not being consulted during authentication? Thanks, On Fri, Apr 21, 2017 at 10:36 AM, Noel Kuntze <[email protected]> wrote: > Hello Zach, > > Make sure you have the "files"[1] plugin. > > [1] https://wiki.strongswan.org/projects/strongswan/wiki/PluginList > > Kind regards, > Noel > > Am 21.04.2017 um 19:32 schrieb 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 <[email protected]> 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 <[email protected]> >>> 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! _______________________________________________ Users mailing list >> [email protected] >> https://lists.strongswan.org/mailman/listinfo/users >> > > > -- > > Mit freundlichen Grüßen/Kind Regards, > Noel Kuntze > > GPG Key ID: 0x63EC6658 > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > -- :wq! _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
