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

[Alex Rousskov]

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).


> 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.

Alex.