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
Received on Mon Apr 28 2014 - 13:37:36 MDT
This archive was generated by hypermail 2.2.0 : Tue Apr 29 2014 - 12:00:07 MDT