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. 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. 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
