net::err_cert_common_name_invalid just in squid page with dstdomain block

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

net::err_cert_common_name_invalid just in squid page with dstdomain block

erdosain9
Hi to all.
I block some webs for a group of users.

That users can use internet without problem, but... i block some web (social
networks).
In firefox, all work fine, when someone try to go to facebook for example,
they found with "access denied" (web from squid).
But, in Chrome.. they get this error "net::err_cert_common_name_invalid".

Why??
If all is working (they can use internet with https without problem, why
with the page from squid they have that error)???
All the users use Chrome so, this is a problem for me.
Somebody can help me??

Thanks to all!

This is my config file

####GRUPOS DE IP
acl sin_autenticacion src "/etc/squid/listas/sin_autenticacion.lst"



###Kerberos Auth with ActiveDirectory###
auth_param negotiate program /lib64/squid/negotiate_kerberos_auth -s
HTTP/[hidden email]
auth_param negotiate children 35 startup=0 idle=1
auth_param basic credentialsttl 2 hours
auth_param negotiate keep_alive on

external_acl_type i-restringidos %LOGIN
/usr/lib64/squid/ext_kerberos_ldap_group_acl -g [hidden email]
external_acl_type i-full %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl
-g [hidden email]
external_acl_type i-limitado %LOGIN
/usr/lib64/squid/ext_kerberos_ldap_group_acl -g [hidden email]

#GRUPOS
acl i-restringidos external i-restringidos
acl i-full external i-full
acl i-limitado external i-limitado

####Bloquea Publicidad ( http://pgl.yoyo.org/adservers/ )
acl ads dstdom_regex "/etc/squid/listas/ad_block.lst"
http_access deny ads
#deny_info TCP_RESET ads

####Streaming
acl youtube url_regex -i \.flv$
acl youtube url_regex -i \.mp4$
acl youtube url_regex -i watch?
acl youtube url_regex -i youtube
acl facebook url_regex -i facebook
acl facebook url_regex -i fbcdn\.net\/v\/(.*\.mp4)\?
acl facebook url_regex -i fbcdn\.net\/v\/(.*\.jpg)\?
acl facebook url_regex -i akamaihd\.net\/v\/(.*\.mp4)\?
acl facebook url_regex -i akamaihd\.net\/v\/(.*\.jpg)\?

##Dominios denegados
*acl restringidos dstdomain "/etc/squid/listas/restringidos.lst" (here is
.whatsapp.com)
*acl dominios_denegados dstdomain "/etc/squid/listas/dominios_denegados.lst"


#Puertos
acl SSL_ports port 443
acl SSL_ports port 4443
acl SSL_ports port 8443
acl SSL_ports port 8080
acl SSL_ports port 20000
acl SSL_ports port 10000
acl SSL_ports port 2083

acl Safe_ports port 631         # httpCUPS
acl Safe_ports port 85
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 4443        # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 8443        # httpsalt
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 8080        # edesur y otros
acl Safe_ports port 2199 # radio
acl CONNECT method CONNECT


#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow sin_autenticacion
http_access deny i-restringidos !restringidos
http_access allow i-limitado !dominios_denegados
http_access allow i-full !dominios_denegados
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 127.0.0.1:3128
http_port 192.168.1.215:3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myca.pem
key=/etc/squid/ssl_cert/myca.pem

acl step1 at_step SslBump1

acl excludeSSL ssl::server_name_regex "/etc/squid/listas/excluidosSSL.lst"

ssl_bump peek step1
ssl_bump splice excludeSSL
ssl_bump bump all

#tcp_outgoing_address  

# Uncomment and adjust the following to add a disk cache directory.
cache_dir diskd /var/spool/squid 15000 16 256
cache_mem 500 MB
#maximum_object_size_in_memory 1 MB

cache_swap_low 70
cache_swap_high 85

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid


#Your refresh_pattern
refresh_pattern -i \.jpg$ 30 0% 30 ignore-no-cache ignore-no-store
ignore-private
refresh_pattern -i ^http:\/\/www\.google\.com\/$ 0 20% 360 override-expire
override-lastmod ignore-reload ignore-no-cache ignore-no-store
reload-into-ims ignore-must-revalidate
#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

###ACTIVAR EN CASO DE "Connection reset by peer" EN MUCHOS HOST
via off
forwarded_for delete

request_header_access From deny all
request_header_access Server deny all
request_header_access WWW-Authenticate deny all
request_header_access Link deny all
request_header_access Cache-Control deny all
request_header_access Proxy-Connection deny all
request_header_access X-Cache deny all
request_header_access X-Cache-Lookup deny all
request_header_access Via deny all
request_header_access X-Forwarded-For deny all
request_header_access Pragma deny all
request_header_access Keep-Alive deny all

###

#Pools para ancho de banda
delay_pools 5

#Ancho de Youtube
delay_class 1 2
delay_parameters 1 1000000/1000000 10000/100000
delay_access 1 allow i-limitado youtube !facebook
delay_access 1 deny all

#Ancho de Facebook
delay_class 2 2
delay_parameters 2 1000000/1000000 50000/256000
delay_access 2 allow i-limitado facebook !youtube
delay_access 2 deny all

#Ancho de banda YOUTUBE FULL
delay_class 3 1
delay_parameters 3 1000000/1000000
delay_access 3 allow i-full youtube !facebook
delay_access 3 deny all

#Ancho de banda LIMITADO
delay_class 4 2
delay_parameters 4 4000000/4000000 100000/500000
delay_access 4 allow i-limitado !youtube !facebook
delay_access 4 deny all

#Ancho de banda FULL
delay_class 5 2
delay_parameters 5 4000000/4000000 500000/1000000
delay_access 5 allow i-full !youtube !facebook
delay_access 5 deny all

dns_nameservers 192.168.1.10 192.168.1.22
visible_hostname squid.domain.lan

# try connecting to first 25 ips of a domain name
forward_max_tries 25

# fix some ipv6 errors (recommended to comment out)
dns_v4_first on



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Alex Rousskov
On 12/05/2017 08:50 AM, erdosain9 wrote:
> i block some web (social networks).
> In firefox, all work fine, when someone try to go to facebook for example,
> they found with "access denied" (web from squid).
> But, in Chrome.. they get this error "net::err_cert_common_name_invalid".

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?


> Why??

To answer that question, 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

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

The differences (if any) may help you answer the question.


HTH,

Alex.


> If all is working (they can use internet with https without problem, why
> with the page from squid they have that error)???
> All the users use Chrome so, this is a problem for me.
> Somebody can help me??
>
> Thanks to all!
>
> This is my config file
>
> ####GRUPOS DE IP
> acl sin_autenticacion src "/etc/squid/listas/sin_autenticacion.lst"
>
>
>
> ###Kerberos Auth with ActiveDirectory###
> auth_param negotiate program /lib64/squid/negotiate_kerberos_auth -s
> HTTP/[hidden email]
> auth_param negotiate children 35 startup=0 idle=1
> auth_param basic credentialsttl 2 hours
> auth_param negotiate keep_alive on
>
> external_acl_type i-restringidos %LOGIN
> /usr/lib64/squid/ext_kerberos_ldap_group_acl -g [hidden email]
> external_acl_type i-full %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl
> -g [hidden email]
> external_acl_type i-limitado %LOGIN
> /usr/lib64/squid/ext_kerberos_ldap_group_acl -g [hidden email]
>
> #GRUPOS
> acl i-restringidos external i-restringidos
> acl i-full external i-full
> acl i-limitado external i-limitado
>
> ####Bloquea Publicidad ( http://pgl.yoyo.org/adservers/ )
> acl ads dstdom_regex "/etc/squid/listas/ad_block.lst"
> http_access deny ads
> #deny_info TCP_RESET ads
>
> ####Streaming
> acl youtube url_regex -i \.flv$
> acl youtube url_regex -i \.mp4$
> acl youtube url_regex -i watch?
> acl youtube url_regex -i youtube
> acl facebook url_regex -i facebook
> acl facebook url_regex -i fbcdn\.net\/v\/(.*\.mp4)\?
> acl facebook url_regex -i fbcdn\.net\/v\/(.*\.jpg)\?
> acl facebook url_regex -i akamaihd\.net\/v\/(.*\.mp4)\?
> acl facebook url_regex -i akamaihd\.net\/v\/(.*\.jpg)\?
>
> ##Dominios denegados
> *acl restringidos dstdomain "/etc/squid/listas/restringidos.lst" (here is
> .whatsapp.com)
> *acl dominios_denegados dstdomain "/etc/squid/listas/dominios_denegados.lst"
>
>
> #Puertos
> acl SSL_ports port 443
> acl SSL_ports port 4443
> acl SSL_ports port 8443
> acl SSL_ports port 8080
> acl SSL_ports port 20000
> acl SSL_ports port 10000
> acl SSL_ports port 2083
>
> acl Safe_ports port 631         # httpCUPS
> acl Safe_ports port 85
> acl Safe_ports port 80          # http
> acl Safe_ports port 21          # ftp
> acl Safe_ports port 443         # https
> acl Safe_ports port 4443        # https
> acl Safe_ports port 70          # gopher
> acl Safe_ports port 210         # wais
> acl Safe_ports port 8443        # httpsalt
> acl Safe_ports port 1025-65535  # unregistered ports
> acl Safe_ports port 280         # http-mgmt
> acl Safe_ports port 488         # gss-http
> acl Safe_ports port 591         # filemaker
> acl Safe_ports port 777         # multiling http
> acl Safe_ports port 8080        # edesur y otros
> acl Safe_ports port 2199 # radio
> acl CONNECT method CONNECT
>
>
> #
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
>
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
>
> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager
>
> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> http_access deny to_localhost
>
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
>
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
> http_access allow sin_autenticacion
> http_access deny i-restringidos !restringidos
> http_access allow i-limitado !dominios_denegados
> http_access allow i-full !dominios_denegados
> http_access allow localhost
>
> # And finally deny all other access to this proxy
> http_access deny all
>
> # Squid normally listens to port 3128
> http_port 127.0.0.1:3128
> http_port 192.168.1.215:3128 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myca.pem
> key=/etc/squid/ssl_cert/myca.pem
>
> acl step1 at_step SslBump1
>
> acl excludeSSL ssl::server_name_regex "/etc/squid/listas/excluidosSSL.lst"
>
> ssl_bump peek step1
> ssl_bump splice excludeSSL
> ssl_bump bump all
>
> #tcp_outgoing_address  
>
> # Uncomment and adjust the following to add a disk cache directory.
> cache_dir diskd /var/spool/squid 15000 16 256
> cache_mem 500 MB
> #maximum_object_size_in_memory 1 MB
>
> cache_swap_low 70
> cache_swap_high 85
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
>
>
> #Your refresh_pattern
> refresh_pattern -i \.jpg$ 30 0% 30 ignore-no-cache ignore-no-store
> ignore-private
> refresh_pattern -i ^http:\/\/www\.google\.com\/$ 0 20% 360 override-expire
> override-lastmod ignore-reload ignore-no-cache ignore-no-store
> reload-into-ims ignore-must-revalidate
> #
> # Add any of your own refresh_pattern entries above these.
> #
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> ###ACTIVAR EN CASO DE "Connection reset by peer" EN MUCHOS HOST
> via off
> forwarded_for delete
>
> request_header_access From deny all
> request_header_access Server deny all
> request_header_access WWW-Authenticate deny all
> request_header_access Link deny all
> request_header_access Cache-Control deny all
> request_header_access Proxy-Connection deny all
> request_header_access X-Cache deny all
> request_header_access X-Cache-Lookup deny all
> request_header_access Via deny all
> request_header_access X-Forwarded-For deny all
> request_header_access Pragma deny all
> request_header_access Keep-Alive deny all
>
> ###
>
> #Pools para ancho de banda
> delay_pools 5
>
> #Ancho de Youtube
> delay_class 1 2
> delay_parameters 1 1000000/1000000 10000/100000
> delay_access 1 allow i-limitado youtube !facebook
> delay_access 1 deny all
>
> #Ancho de Facebook
> delay_class 2 2
> delay_parameters 2 1000000/1000000 50000/256000
> delay_access 2 allow i-limitado facebook !youtube
> delay_access 2 deny all
>
> #Ancho de banda YOUTUBE FULL
> delay_class 3 1
> delay_parameters 3 1000000/1000000
> delay_access 3 allow i-full youtube !facebook
> delay_access 3 deny all
>
> #Ancho de banda LIMITADO
> delay_class 4 2
> delay_parameters 4 4000000/4000000 100000/500000
> delay_access 4 allow i-limitado !youtube !facebook
> delay_access 4 deny all
>
> #Ancho de banda FULL
> delay_class 5 2
> delay_parameters 5 4000000/4000000 500000/1000000
> delay_access 5 allow i-full !youtube !facebook
> delay_access 5 deny all
>
> dns_nameservers 192.168.1.10 192.168.1.22
> visible_hostname squid.domain.lan
>
> # try connecting to first 25 ips of a domain name
> forward_max_tries 25
>
> # fix some ipv6 errors (recommended to comment out)
> dns_v4_first on
>
>
>
> --
> Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

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

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

"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 [hidden email] HIER_NONE/- -
1512493257.716    169 192.168.1.121 TCP_MISS/204 193 GET
http://www.gstatic.com/generate_204 [hidden email]
HIER_DIRECT/172.217.30.163 -


Line corresponding to blocked Firefox

1512493386.314     43 192.168.1.121 TCP_DENIED/200 0 CONNECT
es-la.facebook.com:443 [hidden email] HIER_NONE/- -
1512493386.317      0 192.168.1.121 TAG_NONE/403 6569 GET
https://es-la.facebook.com/ [hidden email] HIER_NONE/- text/html
1512493386.370    173 192.168.1.121 TAG_NONE/200 0 CONNECT
www.google.com.ar:443 [hidden email] HIER_DIRECT/216.58.222.163 -
1512493386.397     45 192.168.1.121 TCP_DENIED/200 0 CONNECT
es-la.facebook.com:443 [hidden email] 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
[hidden email] HIER_NONE/- text/html


Is strange that from Firefox the "answer" is instantaneous, from chrome not.

Thanks to all.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email] HIER_NONE/- -
> 1512493257.716    169 192.168.1.121 TCP_MISS/204 193 GET http://www.gstatic.com/generate_204 [hidden email] 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 [hidden email] HIER_NONE/- -
> 1512493386.317      0 192.168.1.121 TAG_NONE/403 6569 GET https://es-la.facebook.com/ [hidden email] 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 [hidden email] 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
> [hidden email] 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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

erdosain9
Hi, and thanks.

But, i dont get it, how this is possible, if the bumping is working well. I
mean, if all https is working with my certificate, except for those that i
block (from chrome). But the bumping is working well in Chrome and Firefox.

This is log from Chrome with port

1512501177.181     33 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501177.182     35 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501177.186     40 192.168.1.121 TCP_MISS/200 815 POST
https://www.google.com.ar/url? [hidden email] HIER_DIRECT/- text/html 443
1512501177.252     59 192.168.1.121 TCP_DENIED/200 0 CONNECT
web.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501177.338     80 192.168.1.121 TCP_MISS/204 193 GET
http://www.gstatic.com/generate_204 [hidden email]
HIER_DIRECT/www.gstatic.com - 80


This is the log from firefox with port

1512501278.321     41 192.168.1.121 TCP_MISS/200 813 GET
https://www.google.com.ar/url? [hidden email] HIER_DIRECT/- text/html 443
1512501278.684    185 192.168.1.121 TCP_DENIED/200 0 CONNECT
www.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501278.875      3 192.168.1.121 TAG_NONE/403 6567 GET
https://www.whatsapp.com/? [hidden email] HIER_NONE/- text/html 443
1512501278.916     35 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501279.160    877 192.168.1.121 TAG_NONE/200 0 CONNECT
www.google.com.ar:443 [hidden email] HIER_DIRECT/www.google.com.ar - 443
1512501279.278     52 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501279.529    608 192.168.1.121 TCP_DENIED/200 0 CONNECT
www.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501279.746      2 192.168.1.121 TAG_NONE/403 6569 GET
http://squid.mydomain.lan:3128/squid-internal-static/icons/SN.png
[hidden email] HIER_NONE/- text/html 3128
1512501279.832     75 192.168.1.121 TCP_DENIED/200 0 CONNECT
www.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501279.838      0 192.168.1.121 TAG_NONE/403 6571 GET
https://www.whatsapp.com/favicon.ico [hidden email] HIER_NONE/- text/html
443

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

is the same CN :squid.mydomain.lan

And, again, this error just happend from Chrome when there is time to show a
"web from squid" (no route to host, error, access denied,  etc.)

For example if i see the certificate from facebook (trough squid https
bumping) i see my certificate... so why when i block the web Chrome give
that problem....

Thanks again
(sorry i dont speak english very well)



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Rafael Akchurin

Op 5 dec. 2017 om 20:34 heeft erdosain9 <[hidden email]> het volgende geschreven:

Hi, and thanks.

But, i dont get it, how this is possible, if the bumping is working well. I
mean, if all https is working with my certificate, except for those that i
block (from chrome). But the bumping is working well in Chrome and Firefox.

This is log from Chrome with port

1512501177.181     33 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501177.182     35 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501177.186     40 192.168.1.121 TCP_MISS/200 815 POST
https://www.google.com.ar/url? [hidden email] HIER_DIRECT/- text/html 443
1512501177.252     59 192.168.1.121 TCP_DENIED/200 0 CONNECT
web.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501177.338     80 192.168.1.121 TCP_MISS/204 193 GET
http://www.gstatic.com/generate_204 [hidden email]
HIER_DIRECT/www.gstatic.com - 80


This is the log from firefox with port

1512501278.321     41 192.168.1.121 TCP_MISS/200 813 GET
https://www.google.com.ar/url? [hidden email] HIER_DIRECT/- text/html 443
1512501278.684    185 192.168.1.121 TCP_DENIED/200 0 CONNECT
www.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501278.875      3 192.168.1.121 TAG_NONE/403 6567 GET
https://www.whatsapp.com/? [hidden email] HIER_NONE/- text/html 443
1512501278.916     35 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501279.160    877 192.168.1.121 TAG_NONE/200 0 CONNECT
www.google.com.ar:443 [hidden email] HIER_DIRECT/www.google.com.ar - 443
1512501279.278     52 192.168.1.121 TCP_MISS/204 459 POST
https://www.google.com.ar/gen_204? [hidden email] HIER_DIRECT/- text/html
443
1512501279.529    608 192.168.1.121 TCP_DENIED/200 0 CONNECT
www.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501279.746      2 192.168.1.121 TAG_NONE/403 6569 GET
http://squid.mydomain.lan:3128/squid-internal-static/icons/SN.png
[hidden email] HIER_NONE/- text/html 3128
1512501279.832     75 192.168.1.121 TCP_DENIED/200 0 CONNECT
www.whatsapp.com:443 [hidden email] HIER_NONE/- - 443
1512501279.838      0 192.168.1.121 TAG_NONE/403 6571 GET
https://www.whatsapp.com/favicon.ico [hidden email] HIER_NONE/- text/html
443

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

is the same CN :squid.mydomain.lan

And, again, this error just happend from Chrome when there is time to show a
"web from squid" (no route to host, error, access denied,  etc.)

For example if i see the certificate from facebook (trough squid https
bumping) i see my certificate... so why when i block the web Chrome give
that problem....

Thanks again
(sorry i dont speak english very well)



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Amos Jeffries
Administrator
In reply to this post by Alex Rousskov
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 [hidden email] HIER_NONE/- -
>> 1512493257.716    169 192.168.1.121 TCP_MISS/204 193 GET http://www.gstatic.com/generate_204 [hidden email] 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 [hidden email] HIER_NONE/- -
>> 1512493386.317      0 192.168.1.121 TAG_NONE/403 6569 GET https://es-la.facebook.com/ [hidden email] 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 [hidden email] 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
>> [hidden email] 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
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

erdosain9
In reply to this post by Rafael Akchurin
When i put the in Chrome
https://wwww.sdfasdfasdfasdfasd.com

it produces the same error...
but this just happend with  "https" and with chrome.............. not with
firefox.

With firefox i get the error web pager from squid

    Unable to determine IP address from host name
"www.sdfasdfasdfasdfasf.com"

But... i dont get, why this problem if web.whatsapp.com, facebook.com, etc.
exist... in the other hand why this when squid is trying to show the
informative page (access denied). Because like i say, bumping is working
well.

Thanks all.





--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Amos Jeffries
Administrator
On 06/12/17 09:01, erdosain9 wrote:

> When i put the in Chrome
> https://wwww.sdfasdfasdfasdfasd.com
>
> it produces the same error...
> but this just happend with  "https" and with chrome.............. not with
> firefox.
>
> With firefox i get the error web pager from squid
>
>      Unable to determine IP address from host name
> "www.sdfasdfasdfasdfasf.com"
>
> But... i dont get, why this problem if web.whatsapp.com, facebook.com, etc.
> exist... in the other hand why this when squid is trying to show the
> informative page (access denied). Because like i say, bumping is working
> well.

You are asking the wrong people here. The Chrome developers decided
Chrome should act that way.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Alex Rousskov
In reply to this post by erdosain9
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Yuri Voinov
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
> [hidden email]
> 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 *
**************************



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Yuri Voinov
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
>> [hidden email]
>> 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 *
**************************



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Yuri Voinov
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
>>> [hidden email]
>>> 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 *
**************************



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

erdosain9
In reply to this post by Yuri Voinov
Yes, Chrome tell this when i look the certificate

"The certificate for this site does not contain a Subject Alternative Name
extension containing a domain name or IP address."

So, my certificate does not have a Subject Alternative Name.
But, this is not a problem with Firefox.

I have to change my certificate?? t
There is a way to tell Chrome "dont look for this"???
Thanks





--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Matus UHLAR - fantomas
On 07.12.17 08:05, erdosain9 wrote:
>Yes, Chrome tell this when i look the certificate
>
>"The certificate for this site does not contain a Subject Alternative Name
>extension containing a domain name or IP address."

are you aware that this is not a squid problem?

>So, my certificate does not have a Subject Alternative Name.
>But, this is not a problem with Firefox.

only with certificates issued after some date, not sure when, but it will
come.

>I have to change my certificate?? t
>There is a way to tell Chrome "dont look for this"???

only by using chrome <58

the CommonName does not have documented format, the SubjectAlternativeName
does.


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
He who laughs last thinks slowest.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Alex Rousskov
In reply to this post by erdosain9
On 12/07/2017 08:05 AM, erdosain9 wrote:
> Yes, Chrome tell this when i look the certificate
>
> "The certificate for this site does not contain a Subject Alternative Name
> extension containing a domain name or IP address."

That is not the only error reported by your Chrome, but you can try to
solve one error at a time.

The first step is to understand which certificate the browser is talking
about. Is that a Squid-generated certificate or an origin server
certificate? If it is a Squid-generated certificate, does it mimic an
erroneous property of the origin server certificate? Or did Squid fail
to (or decided not to) mimic something?

The next step, for this specific error, would be to make sure that your
Squid version has as fix for Bug 4711:

> bug 4711: SubjectAlternativeNames is missing in some generated certificates
>
> Squid may generate certificates which have a Common Name, but do not have
> a subjectAltName extension. For example when squid generated certificates
> do not mimic an origin certificate or when the certificate adaptation
> algorithm sslproxy_cert_adapt/setCommonName is used.
>
> This is causes problems to some browsers, which validates a certificate using
> the SubjectAlternativeNames but ignore the CommonName field.
>
> This patch fixes squid to always add a SubjectAlternativeNames extension in
> generated certificates which do not mimic an origin certificate.
>
> Squid still will not add a subjectAltName extension when mimicking an origin
> server certificate, even if that origin server certificate does not include
> the subjectAltName extension. Such origin server may have problems when
> talking directly to browsers, and patched Squid is not trying to fix those
> problems.
>
> This is a Measurement Factory project
>
> Fixes: http://bugs.squid-cache.org/show_bug.cgi?id=4711 fixed
> Bzr-Reference: master r15131

If your Squid does not have the above fix, then it might explain the
second problem reported by Chrome as well, provided the origin server
certificate lacks any CN for Squid to mimic.


> So, my certificate does not have a Subject Alternative Name.
> But, this is not a problem with Firefox.

Yes, different browsers (and different browser versions) may impose
different requirements on certificates (and other traffic parameters).

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

erdosain9
This post was updated on .
Ok, thanks for your time.

This "fix" the problem...

reg add HKLM\Software\Policies\Google\Chrome /v
EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1

When i wrote that command, the problem is gone.

but, i want to know about that fix that you are telling me.
Im using this version Squid Cache: Version 3.5.20

How i know if this is patched (probably not)... and, more important, how i
cant apply that patch (sorry i never do that).
Im working on a Centos 7.

Thanks for your time.

pd.:
i see for apply a patch, this

cd squid-2.5.STABLE1 (whatever)
 patch -p1 <../squid-2.5.STABLE1-spaces.patch
 make clean
 make install

So i need to download the source and re compile??? ................
Thanks



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Yuri Voinov
In reply to this post by Matus UHLAR - fantomas


07.12.2017 21:27, Matus UHLAR - fantomas пишет:

> On 07.12.17 08:05, erdosain9 wrote:
>> Yes, Chrome tell this when i look the certificate
>>
>> "The certificate for this site does not contain a Subject Alternative
>> Name
>> extension containing a domain name or IP address."
>
> are you aware that this is not a squid problem?
>
>> So, my certificate does not have a Subject Alternative Name.
So what? Re-issue cert with openssl and add this field. This is trivial.
>> But, this is not a problem with Firefox.
Firefox uses not so restrictive SSL handling.
>
> only with certificates issued after some date, not sure when, but it will
> come.
>
>> I have to change my certificate?? t
>> There is a way to tell Chrome "dont look for this"???
>
> only by using chrome <58
Not only. It is exists registry hack for Chrome to workaround this. Not
sure it will still works.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:00000001
"EnableDeprecatedWebBasedSignin"=dword:00000000

It's easy to JFGI this hack as .reg-file, if any difficults to make this
by manual.
>
> the CommonName does not have documented format, the
> SubjectAlternativeName
> does.
>
It is documented in openssl man pages. Also it is documented in Google
technical documentation. JFGI.

--
"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 *
**************************



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

Amos Jeffries
Administrator
In reply to this post by erdosain9
On 08/12/17 07:18, erdosain9 wrote:

> Ok, thanks for your time.
>
> This "fix" the problem...
>
> reg add HKLM\Software\Policies\Google\Chrome /v
> EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1
>
> When i wrote that command, the problem is gone.
>
> but, i want to know about that fix that you are telling me.
> Im using this version Squid Cache: Version 3.5.20
>
> How i know if this is patched (probably not)... and, more important, how i
> cant apply that patch (sorry i never do that).
> Im working on a Centos 7.
>

Eliezers repository contains RPMs for more up to date 3.5.27 releases.
The 'beta' area also contains Squid-4 releases.

<https://wiki.squid-cache.org/KnowledgeBase/CentOS>


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: net::err_cert_common_name_invalid just in squid page with dstdomain block

erdosain9
Thanks.
I update to  3.5.27 and now i dont have this problem.
But, i have this doubt... so, this was a problem of my certificate or a bug
from squid???

Thanks



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
12