On 29/04/2014 12:40 a.m., tomsl wrote: > It is a reverse proxy. This is the cache peer that would be used: > > cache_peer 10.190.254.85 parent 443 0 no-query login=PASS no-digest > originserver ssl ssldomain=*.mydomain.com sslversion=6 name=mainserver > > Looking at the logs the url that client is trying to access does not get > logged so it does not actually get to that stage. > > The certificate being used is identical and present on both the old and new > servers. Some of these client devices can connect and some cannot, and a > firmware upgrade on the devices that do not will fix the issue. > Unfortunately we cannot do a firmware update remotely so although it does > look like a client issue we would prefer to try and find a workaround on the > proxy that would allow the client to connect. > I have been digging into the "clientNegotiateSSL". It seems the missing certificate is the client device which connected to Squid. That is fine after all. It looks like this is happening: - client connects with TCP to Squid - Squid issues TLS challenge to client - client responds with TLS response - Squid waits for clients HTTP request. - connection closes. Does your Squid have a 1 or 2 second value on request_timeout ? Amos
