[squid-users] net::err_cert_common_name_invalid just in squid page with dstdomain block

[Yuri]

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 at lists.squid-cache.org
>>> 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 *
**************************


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20171206/c96cb020/attachment.sig>