<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 31, 2017 at 4:44 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_5619510244724927757gmail-">On 31/03/2017 4:01 a.m., Eric Veiras Galisson wrote:<br>
> Hello,<br>
><br>
> I want to setup Squid as a HTTPS reverse proxy for several of our websites,<br>
> but I have a certificate verification problem on Squid access.log.<br>
> Our upstream webservers are behind a VPN tunnel and only the Squid server<br>
</span>> can access it. (*We actually use Nginx for the same purpose but want to<br>
> switch to Squid)*<br>
<span class="gmail-m_5619510244724927757gmail-">><br>
>                               HTTPS                           HTTPS<br>
> [client browser] -----------------------> [Squid]<br>
> --------------------------> [upstream server]<br>
><br>
><br>
> I run squid 3.4.8-6+deb8u4 recompiled with --enable-ssl<br>
> --with-open-ssl="/etc/ssl/open<wbr>ssl.cnf" on Debian Jessie.<br>
><br>
> The certificate presented to the client is the same as on the upstream<br>
> server, a wildcard one signed by GeoTrust (with intermediate CA). It<br>
> appears correctly in the browser.<br>
> The problem comes from squid verification of upstream certificate.<br>
><br>
</span>...<br>
<span class="gmail-m_5619510244724927757gmail-">><br>
> What am I doing wrong? and what should I do to make squid work in this<br>
> setup?<br>
<br>
</span>The server (and Squid) should be supplying the intermediate cert along<br>
with its own cert for best validation behaviour.<br></blockquote><div><br></div><div>Both the server and squid (https_port cert= option) are actually using the same certificate: a single file with priv key, server certificate and intermediary cert CA.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If it cannot, use the cache_peer sslcafile= option to provide Squid with<br>
a PEM file containing the public certs of the whole chain (excluding the<br>
server cert itself). Order of those certs in the file is important. I've<br>
forgotten which end of the chain to start with sorry, but it is one or<br>
the other and definitely sequential.<br>
<br></blockquote><div><br></div><div>I changed cache_peer directive to add sslcafile option to a PEM file containing root and intermediary CA certificate, in one order or the other.</div><div><br></div><div><div>And when verifying with openssl s_client -showcerts -connect upstream1.domain.tld directly (no squid) or via squid, it's OK [1]</div><div><br></div><div><font face="monospace, monospace">$ openssl s_client -showcerts -connect upstream.domain.tld:443<br></font></div><div><div><font face="monospace, monospace">CONNECTED(00000003)</font></div><div><font face="monospace, monospace">depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA</font></div><div><font face="monospace, monospace">verify return:1</font></div><div><font face="monospace, monospace">depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA</font></div><div><font face="monospace, monospace">verify return:1</font></div><div><font face="monospace, monospace">depth=0 CN = *.domain.tld</font></div><div><font face="monospace, monospace">verify return:1</font></div><div><font face="monospace, monospace">---</font></div></div><div><font face="monospace, monospace">    Verify return code: 0 (ok)</font></div></div><div><br></div><div><br></div><div>But I still have the same error when connecting to the website with a browser.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When that is working you should use the sslflags=NO_DEFAULT_CA option to<br>
prevent MITM on those connections altering the chain - and saves a huge<br>
amount of memory :-).<br>
<br>
Amos<br></blockquote><div> </div></div><br clear="all"><div><div>[1] for this server at least, which is Apache 2.4 on Debian Jessie, old Apache 2.2 on Debian Wheezy don't work, but it's another problem.</div></div><div><br></div>
</div></div>