<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 2, 2017 at 10:27 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">On 1/04/2017 4:42 a.m., Eric Veiras Galisson wrote:<br>
<div><div class="gmail-h5">> On Fri, Mar 31, 2017 at 4:44 AM, Amos Jeffries wrote:<br>
><br>
>> 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<br>
>> 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>
>>> can access it. (*We actually use Nginx for the same purpose but want to<br>
>>> switch to Squid)*<br>
>>><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/<wbr>openssl.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>
>> ...<br>
>>><br>
>>> What am I doing wrong? and what should I do to make squid work in this<br>
>>> setup?<br>
>><br>
>> The server (and Squid) should be supplying the intermediate cert along<br>
>> with its own cert for best validation behaviour.<br>
>><br>
><br>
> Both the server and squid (https_port cert= option) are actually using the<br>
> same certificate: a single file with priv key, server certificate and<br>
> intermediary cert CA.<br>
><br>
<br>
</div></div>That does not matter. TLS is point-to-point.<br>
<br>
What matters is that *any* software operating as the server endpoint of<br>
a TLS connection sends the right details along with its cert.<br></blockquote><div><br></div><div>I think that is what I'm doing: priv key, server cert + intermediate CA cert.</div><div><br></div><div>And openssl s_client is OK with TLS chain.</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">
Your setup is special in that it has multiple pieces of software using<br>
the same cert (Squid and the peer web service). That is not great for<br>
security (reduces the effective trust lifetime of the cert), but is doable.<br></blockquote><div> </div><div>I understand that.</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"><span class="gmail-">
<br>
><br>
>> 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>
>><br>
> I changed cache_peer directive to add sslcafile option to a PEM file<br>
> containing root and intermediary CA certificate, in one order or the other.<br>
><br>
> And when verifying with openssl s_client -showcerts -connect<br>
> upstream1.domain.tld directly (no squid) or via squid, it's OK [1]<br>
><br>
> $ openssl s_client -showcerts -connect upstream.domain.tld:443<br>
> CONNECTED(00000003)<br>
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA<br>
> verify return:1<br>
> depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA<br>
> verify return:1<br>
> depth=0 CN = *.domain.tld<br>
> verify return:1<br>
> ---<br>
>     Verify return code: 0 (ok)<br>
><br>
><br>
> But I still have the same error when connecting to the website with a<br>
> browser.<br>
><br>
<br>
</span>Exact same error? Since Squid is juggling multiple TLS connections for<br>
the transaction I am looking at "fwdNegotiateSSL" in the log message<br>
which is the only detail indicating what connection is having the issue.<br>
<br></blockquote><div><br></div><div>Yes, same error. If I try to access upstream1.domain.tld via a browser via squid, I got this in squid/cache.log</div><div><br></div><div><div>2017/04/03 09:29:57 kid1| fwdNegotiateSSL: Error negotiating SSL connection on FD 14: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)</div><div>2017/04/03 09:29:57 kid1| TCP connection to <upstream IP>/443 failed</div><div>2017/04/03 09:29:57 kid1| fwdNegotiateSSL: Error negotiating SSL connection on FD 14: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)</div><div>2017/04/03 09:29:57 kid1| TCP connection to <upstream IP>/443 failed</div><div><br></div><div>No request is visible in upstream Apache logs.</div><div><br></div></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">
That Squid->server connection has zero difference between the browser<br>
and the command line tool connecting to a reverse-proxy, or when both<br>
are using opaque (non-Bumped) CONNECT tunnels. So one working and the<br>
other not is impossible.<br></blockquote><div><br></div><div>Yes, I understand this. My problem now is finding what is failing in my setup.</div><div><br></div><div>Eric.</div><div><br></div></div>
</div></div>