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

[Eric Veiras Galisson]

On Fri, Mar 31, 2017 at 4:44 AM, Amos Jeffries <squid3 at treenet.co.nz> 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.



> 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.




> When that is working you should use the sslflags=NO_DEFAULT_CA option to
> prevent MITM on those connections altering the chain - and saves a huge
> amount of memory :-).
>
> Amos
>


[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170331/bd099ee1/attachment.html>