On 20/07/17 09:10, Yuri wrote:
Aha,
20.07.2017 3:04, Cherukuri, Naresh пишет:
Yuri,
I am sorry I didn’t get you I already installed certificate on all
clients(trusted root certificate authorities). You want me install
proxy public key also on clients, if so were should I put the proxy
public key. Below is my squid.conf file.
Squid.conf
key=/etc/squid/pctysquid2sslcerts/pctysquid2prod.pkey \ proxy ca
public key??
This is proxy private key AFAIK.
Correct. It should be the proxy private key. If the public key is put in
there and startup actually succeeds I'm not sure what broken runtime
errors will occur - nothing good anyhow.
Also, note that cert= parameter should be configured *before* the key=
parameter so Squid loads them from the right place. The very latest
releases (v4+) will fail to start if the ordering is wrong, so best to
prepare for that now.
I suspect that part of the problem here is what is being configured in
that cert= parameter. For SSL-Bump ports in current Squid it needs to
contains the self-signed *CA* certificate that Squid is using to
generate other certs from, the key= being the private key of that CA cert.
If you generate a regular proxy cert and load it there (like normal
proxy cert= would use) the bumping process will get all broken.
The ConfigExample page Yuri linked to earlier had the exact and full
process to follow for setting up the multiple different certs, keys and
file types involved with SSL-Bump.
cert=/etc/squid/pctysquid2sslcerts/pctysquid2prod.crt \(installed
certificate on IE all clients as a trusted root certificate authorities)
Yes, if it installed into clients - this is ok.
So. The only reason I can see - proxy can't see OpenSSL CA's bundle.
To make it work you should add to your squid's config one of this:
# TAG: sslproxy_cafile
# file containing CA certificates to use when verifying server
# certificates while proxying https:// URLs
#Default:
# none
# TAG: sslproxy_capath
# directory containing CA certificates to use when verifying
# server certificates while proxying https:// URLs
#Default:
# none
Er, those are for Squid->server connections. You were correct about the
errors referring to client->Squid connections, so these are irrelevant.
If anything, the cafile= parameter of the ssl-bump port might be
needed. Then it should point at the same CA's found in the cert=
parameter (bit weird, but that is bugs in the SSL-Bump config design).
FTR: those particular errors occur when Squid accepts a connection from
a client, begins the TLS handshake and the client suddenly disconnects
before the handshake is complete.
The "certificate unknown" seems to be saying that either 1) the client
sent a client-cert to Squid and OpenSSL did not accept it, or 2) that
the client did not accept the auto-generated cert Squid sent.
If (1) is happening it s because the browser was not correctly
configured with the self-signed CA public cert.
If (2) is happening, then probably the cert=, key=, cafile= parameters
on the ssl-bump port are not configured right, OR browser was not
correctly configured with the self-signed CA public cert.
Or, maybe bugs in that particular Squid release SSL-Bump code. We are
constantly fixing them and 3.5.20 is now a whole year behind with
SSL-Bump fixes - many of them rather major behaviour fixes.
==> Best Practice to follow with SSL-Bump is that when having *any*
problems with the SSL-Bump process try the latest Squid release first
before spending time trying to figure it out.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
