On Sun, Apr 2, 2017 at 10:27 AM, Amos Jeffries <squ...@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.
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
