Search squid archive

Re: HTTPS reverse proxy: SSL Certficate verification failed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux