On 12/05/2017 12:33 PM, erdosain9 wrote: > i dont get it, how this is possible, if the bumping is working well. Depending on your configuration and traffic, Squid may have more origin server information when generating certificates for (future) successfully bumped connections compared to when generating certificates for (future) error responses. Lack of information often leads to bumping failures. > This is log from Chrome with port I did not find the client source port in your access log lines. 80 and 443 are server ports. If you were using the correct %>p code, try the opposite one (%<p) and file a bug report. You can always log both, of course. Also, to reduce analysis time in the future, while working on this specific thread/question, please post only access log lines related to a single problematic TCP connection that starts with a CONNECT request. There is no need to post other/unrelated traffic. > "How do you compare the two certificates? " > > I see the certificate, and look detail (both, firefox and chrome). > <http://squid-web-proxy-cache.1019090.n4.nabble.com/file/t376870/Captura_de_pantalla_de_2017-12-05_16-25-48.png> That screenshot does not show the certificate detail, so I cannot confirm or deny your claim that the CN is the same in both FireFox and Chrome cases. To see certificate details, you need to (at least) click on the "View Certificate" button shown on that screenshot. > is the same CN :squid.mydomain.lan That CN is wrong for bumped connections to Facebook (or WhatsApp). If that is indeed the certificate CN for the error response connection, and that connection was trying to get to Facebook (or WhatsApp), then Chrome may be telling you the truth! Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
