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