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