On Sun, Apr 2, 2017 at 10:27 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 1/04/2017 4:42 a.m., Eric Veiras Galisson wrote:
That does not matter. TLS is point-to-point.> On Fri, Mar 31, 2017 at 4:44 AM, Amos Jeffries wrote:
>
>> On 31/03/2017 4:01 a.m., Eric Veiras Galisson wrote:
>>> Hello,
>>>
>>> I want to setup Squid as a HTTPS reverse proxy for several of our
>> websites,
>>> but I have a certificate verification problem on Squid access.log.
>>> Our upstream webservers are behind a VPN tunnel and only the Squid server
>>> can access it. (*We actually use Nginx for the same purpose but want to
>>> switch to Squid)*
>>>
>>> HTTPS HTTPS
>>> [client browser] -----------------------> [Squid]
>>> --------------------------> [upstream server]
>>>
>>>
>>> I run squid 3.4.8-6+deb8u4 recompiled with --enable-ssl
>>> --with-open-ssl="/etc/ssl/openssl.cnf" on Debian Jessie.
>>>
>>> The certificate presented to the client is the same as on the upstream
>>> server, a wildcard one signed by GeoTrust (with intermediate CA). It
>>> appears correctly in the browser.
>>> The problem comes from squid verification of upstream certificate.
>>>
>> ...
>>>
>>> What am I doing wrong? and what should I do to make squid work in this
>>> setup?
>>
>> The server (and Squid) should be supplying the intermediate cert along
>> with its own cert for best validation behaviour.
>>
>
> 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.
>
What matters is that *any* software operating as the server endpoint of
a TLS connection sends the right details along with its cert.
I think that is what I'm doing: priv key, server cert + intermediate CA cert.
And openssl s_client is OK with TLS chain.
Your setup is special in that it has multiple pieces of software using
the same cert (Squid and the peer web service). That is not great for
security (reduces the effective trust lifetime of the cert), but is doable.
I understand that.
>
>> If it cannot, use the cache_peer sslcafile= option to provide Squid with
>> a PEM file containing the public certs of the whole chain (excluding the
>> server cert itself). Order of those certs in the file is important. I've
>> forgotten which end of the chain to start with sorry, but it is one or
>> the other and definitely sequential.
>>
>>
> 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.
>
> And when verifying with openssl s_client -showcerts -connect
> upstream1.domain.tld directly (no squid) or via squid, it's OK [1]
>
> $ openssl s_client -showcerts -connect upstream.domain.tld:443
> CONNECTED(00000003)
> depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
> verify return:1
> depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA
> verify return:1
> depth=0 CN = *.domain.tld
> verify return:1
> ---
> Verify return code: 0 (ok)
>
>
> But I still have the same error when connecting to the website with a
> browser.
>
Exact same error? Since Squid is juggling multiple TLS connections for
the transaction I am looking at "fwdNegotiateSSL" in the log message
which is the only detail indicating what connection is having the issue.
Yes, same error. If I try to access upstream1.domain.tld via a browser via squid, I got this in squid/cache.log
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)
2017/04/03 09:29:57 kid1| TCP connection to <upstream IP>/443 failed
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)
2017/04/03 09:29:57 kid1| TCP connection to <upstream IP>/443 failed
No request is visible in upstream Apache logs.
That Squid->server connection has zero difference between the browser
and the command line tool connecting to a reverse-proxy, or when both
are using opaque (non-Bumped) CONNECT tunnels. So one working and the
other not is impossible.
Yes, I understand this. My problem now is finding what is failing in my setup.
Eric.
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
