[squid-users] HTTPS reverse proxy: SSL Certficate verification failed

[Eric Veiras Galisson]

On Sun, Apr 2, 2017 at 10:27 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 1/04/2017 4:42 a.m., Eric Veiras Galisson wrote:
> > 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.
> >
>
> That does not matter. TLS is point-to-point.
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170403/59598c71/attachment.html>