On 10/30/18 2:36 AM, Sid wrote: > http_port 3128 ssl-bump \ > cert=/usr/local/squid/etc/ssl_cert/myCA.pem \ > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > ssl_bump peek step1 > ssl_bump bump all > Browser & HTTP UA Client connections are working with SSL bump properly; but > except for one connection. > Server sends certificate with SNI; but squid forwards it as IP Address to > client Two problems with that statement: 1. Servers never send SNI. Clients usually send SNI. Squid should forward SNI it received from the client to the server, provided the client actually sent SNI. Did your client send SNI? 2. Bugs notwithstanding, the implied order of events is not what actually happens: Squid, as configured, does _not_ forward anything from the server certificate to the client. Squid, as configured, generates a certificate based on client-supplied information (not server-supplied information). After sending that generated certificate to the client, Squid establishes a TLS connection with the server. > When I took wireshark on Squid; I can see Squid sends: For an accurate picture, in addition to Squid-server and server-Squid traffic, look at what Squid has received from the client and what Squid sent to the client, all in actual order. > 61 Alert (Level: Fatal, Description: Internal Error) to certificate sent by > Server > > cache.log: > 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21: > error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify > failed (1/-1/0) > 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21: > error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify > failed (1/-1/0) > > This is an internal server with its own CA certs. Is your Squid configured to trust those internal CAs? If not, Squid would not be able to validate the server certificate. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
