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
