PPS. I want to add an obvious thing. Blocking https pages should also be redirected to the https page. This is obvious and required by the RFC. As I know. And the https page for the https deny must be opened correctly by the client browser. It's simple. 06.12.2017 5:24, Yuri пишет: > PS. And, of course, both CN/subjectAltName should be resolvable by > client. If not - you will get such an error. > > This, automatically, point us to DNS (internal) which must have local > zone to internal resolving resources such as proxy, local web, etc. > > > 06.12.2017 5:17, Yuri пишет: >> Everything can be much simpler. If the deny is redirected to the local >> web server with https, and the server certificate does not have the >> correct CN - or there is no subjectAltName - Chrome will give such an error. >> >> >> 06.12.2017 3:08, Alex Rousskov пишет: >>> 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 -- "Some people, when confronted with a problem, think «I know, I'll use regular expressions.» Now they have two problems." --Jamie Zawinsk ************************** * C++: Bug to the future * **************************
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
