[Privoxy-users] [privoxy-3.0.33] Can't get https-inspection to work (PR_END_OF_FILE_ERROR)

[avoidr]

On Tue, Sep 27, 2022 at 10:53:50AM +0200, Fabian Keil wrote:
> avoidr <avoidr at posteo.de> wrote on 2022-09-24 at 14:54:24:
> 
> > On Fri, Sep 23, 2022 at 07:39:17AM +0000, avoidr wrote:
> > > I just noticed I can increase the debug level... I'll do that and see
> > > again.
> > 
> > Ok, I was able to resolve my issue.
> 
> Great. Thanks for letting us know.
> 
> > I set debug to 8192 ("Non-fatal errors") and that gave me the clue, that
> > my ca-cert-file is misplaced:
> > ```
> > 2022-09-24 15:09:51.478 7f7078acd640 Error: Error opening certificate
> > file ./CA/cacert.crt: No such file or directory 2022-09-24 15:09:51.478
> > 7f7078acd640 Error: Loading issuer certificate ./CA/cacert.crt failed
> > 2022-09-24 15:09:51.478 7f7078acd640 Error: generate_host_certificate
> > failed: -1 ```
> > 
> > After placing ca-cert-file, ca-key-file, and trusted-cas-file into
> > ca-directory, https-inspection started working correctly.
> > 
> > The issue with my configuration stemmed from my false assumption about
> > ca-directory's default setting; the documentation says the default value
> > is an empty string. However "./CA/" is not an empty string.
> 
> Indeed.
> 
> Thanks for the report. Fixed in:
> <https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=b53aa7f4f9240308cb6cb09b7a73dfdf7ddcf509>

Thanks.

> 
> > Later I also found that ./CA/ is not relative to confdir (which I had
> > assumed), but relative to the process' CWD (?).
> 
> That's correct.
> 
> > In other words, I had assumed that ca-directory is relative to confdir,
> > and that if ca-directory is unset, the default effective value would be
> > that of confdir, but it was /CA/ instead.
> > 
> > From my point of view, ca-directory should be relative to confdir,
> > unless an absolute path is given.
> > Then, the default value of ca-directory being "./CA/" seems sensible.
> 
> I'll have to think about this some more.
> 
> Changing the behaviour may break existing configurations on update
> so maybe we should simply make the documentation more obvious.

I believe I already saw for another setting, that this point was
clarified, so making the documentation change would also be consistent.

> 
> Fabian