[squid-users] cafile and capath not working as expected with SSL bump

[Amos Jeffries]

On 29/06/2016 10:01 p.m., Bruce Rosenberg wrote:
> Hi,
> 
> I'm using squid 3.5.19 on RHEL6 and have configured SSL bump, which for the
> most part is working great.
> The issue I have is I need to install some additional CA certs that are not
> provided by the ca-certificates-2015 RPM in the /etc/pki/tls/cert.pem file
> (symlinked to /etc/pki/tls/certs/ca-bundle.crt).
> I've tried adding both the cafile and capath options to the http_port entry
> but neither seems to have any affect.
> With the cafile option I can see squid open the file via an strace but when
> I connect to the server it fails with a 503 as the SSL session to the
> remote side is failing to verify.
> With the capath option, strace shows that squid never attempts to open any
> files in that directory.
> Dynamic certificate generation between squid and the client is working fine
> however.
> 
...
> 
> Are the cafile and capath options supposed to work like this i.e. do they
> allow you to complement the OS supplied CA certs for remote site
> verification or have I completely misread the documentation?

The options *on http_port* are supposed to act like that, yes.

I think you have just mistaken the distinction between the three types
of connection Squid has to juggle.


http(s)_port is for links between client and Squid. Those parameters
used for verifying *client certificates*.

sslproxy_* set of directives are for direct Squid->server links. The
sslproxy_cafile and/or sslproxy_capath load the extra special CA you
want to add to the system default ones.

cache_peer is for static links to a known server/peer. It has its own
cafile= and capath= options for CA to verify that specific server.
Ideally the system CAs would not be used here.


If I'm understanding your needs correctly then you want to be
configuring sslproxy_cafile and/or sslproxy_capath.


Amos