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

Amos Jeffries squid3 at treenet.co.nz
Tue Dec 5 19:46:51 UTC 2017


On 06/12/17 06:29, Alex Rousskov wrote:
> On 12/05/2017 10:05 AM, erdosain9 wrote:
>> "Does that error match the generated certificate sent by Squid to a
>> blocked Chrome user? In other words, does that certificate have an
>> invalid common name (CN) field? "
> 
>> No, is the same certificate.
> 
> Your statement does not answer my question. I can ask a different
> question if you prefer: What is is common name (CN) field of the
> generated certificate sent by Squid to a blocked Chrome user?
> 
> 
>> "I suggest comparing the following two certificates:
>>    * the certificate sent by Squid to a blocked FireFox user
>>    * the certificate sent by Squid to a blocked Chrome user "
>>
>> Is the same certificate.
> 
> How do you compare the two certificates?
> 
> 
>> "I also suggest comparing the following access.log entries:
>>
>>    * the line(s) corresponding to the blocked FireFox user request
>>    * the line(s) corresponding to the blocked Chrome user request "
> 
> 
>> Line corresponding to blocked Chrome
>>
>> 1512493257.523    175 192.168.1.121 TCP_DENIED/200 0 CONNECT es-la.facebook.com:443 user at DOMAIN.LAN HIER_NONE/- -
>> 1512493257.716    169 192.168.1.121 TCP_MISS/204 193 GET http://www.gstatic.com/generate_204 user at DOMAIN.LAN HIER_DIRECT/172.217.30.163 -
> 
> The allowed GET request looks out of place here. It is possible that
> that request was sent by Chrome after (or during) Chrome error page
> generation and, hence, should be ignored during this analysis. To make
> sure you look at requests on one TCP connection, log the source TCP port
> number of the client connection to Squid (%>p).

That URI is Chrome testing for Internet access.

> 
>> Line corresponding to blocked Firefox
> 
>> 1512493386.314     43 192.168.1.121 TCP_DENIED/200 0 CONNECT es-la.facebook.com:443 user at DOMAIN.LAN HIER_NONE/- -
>> 1512493386.317      0 192.168.1.121 TAG_NONE/403 6569 GET https://es-la.facebook.com/ user at DOMAIN.LAN HIER_NONE/- text/html
> 
> This group looks OK to me: The CONNECT request was denied (without
> letting the browser know). The following GET request (presumably on the
> same TCP connection) was bumped to serve the denial error page to the
> browser.
> 
> 
>> 1512493386.397     45 192.168.1.121 TCP_DENIED/200 0 CONNECT es-la.facebook.com:443 user at DOMAIN.LAN HIER_NONE/- -
>> 1512493386.400      0 192.168.1.121 TAG_NONE/403 6561 GET http://squid.DOMAIN.lan:3128/squid-internal-static/icons/SN.png
>> user at DOMAIN.LAN HIER_NONE/- text/html
> 
> Something went wrong here. The denied GET request is (logged as) a plain
> HTTP request (no "https://"). Perhaps it is unrelated to the denied
> CONNECT attempt, but then why did that GET get a 403 response? The above
> %>p logging suggestion applies here as well.

It is the icon on a Squid error page. I doubt it has anything to do with 
the second CONNECT line directly above it, but is probably the result of 
the 403 being delivered by Squid two lines previously.


Amos


More information about the squid-users mailing list