acl internal src 192.168.200.0/21 acl wireless src 192.168.100.0/23 acl Safe_ports port 80 acl Safe_ports port 443 acl SSL_ports port 443 acl CONNECT method CONNECT
acl allowed dstdomain -i "/etc/squid3/acls/http_allowed.acl" acl prime dstdomain -i "/etc/squid3/acls/squid-prime.acl" acl ips dst -n "/etc/squid3/acls/broken_ips.acl" acl blocked dstdomain -i "/etc/squid3/acls/http_blocked.acl" http_access allow allowed http_access allow ips http_access deny blocked http_access deny prime http_access allow internal http_access allow wireless http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access deny all acl step1 at_step SslBump1 acl step2 at_step SslBump2 acl step3 at_step SslBump3 acl broken_sites ssl::server_name_regex "/etc/squid3/acls/http_broken.txt" ssl_bump peek !broken_sites ssl_bump splice all sslproxy_capath /etc/ssl/certs sslcrtd_program /lib/squid3/ssl_crtd -s /etc/squid3/ssl_db -M 4MB sslcrtd_children 32 startup=5 idle=1 http_port 3128 intercept https_port 3129 intercept ssl-bump cert=/etc/squid3/certs/squid.pem cafile=/etc/squid3/certs/squid.pem key=/etc/squid3/certs/squid.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB sslflags=NO_SESSION_REUSE dns_nameservers 192.168.201.1 8.8.8.8 wccp_version 2 wccp2_router 192.168.200.73 wccp2_forwarding_method gre wccp2_return_method gre wccp2_service standard 0 password=xxxx wccp2_service dynamic 70 password=xxxx wccp2_service_info 70 protocol=tcp flags=dst_ip_hash priority=240 ports=443 I did update the ca bundle if that helps. Bruce Markey | Network Security Analyst STEINMAN COMMUNICATIONS 717.291.8758 (o) | bmar...@steinmancommunications.com 8 West King St | PO Box 1328, Lancaster, PA 17608-1328 -----Original Message----- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Amos Jeffries Sent: Thursday, April 21, 2016 8:59 AM To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] Cert authority invalid failures. On 21/04/2016 8:18 a.m., Markey, Bruce wrote: > I'm curious as to why this is happening. > > Proxy was implemented last week and since then I've been dealing with all the > sites that don't work. Not a problem, knew it was going to happen. I'd like > to understand why the following is happening. > > > 1. User goes to https://www.whatever.com > > 2. Browser, mostly chrome, gives the following error. Connection not > private. NET:ERR_CERT_AUTHORITY_INVALID > Typing that into search engine produces a thread explaining that it is the browser message shown when HSTS is in effect on a website and the server cert is not trusted by the browser. > 3. If you view the cert it shows the dynamic cert listed. > > 4. Click the "Proceed to www.whatever.com<http://www.whatever.com> > (unsafe ) > > 5. Now I get a squid error. Requested url could not be retrieved. > Access denied while trying to retrieve https:// some ip address/* > And that #5 explains why. It was actually not the web server producing the cert. But Squid doing SSL-Bumping in order to show you the error page. > Thing is I don't have an acl blocking that ip? ( Small sub question here, > is there a way to tell which acl blocks something? ) > Something clearly is. But not what you expect, or you would not be here asking about it. > What I've had to do to get around this is add > www.whatever.com<http://www.whatever.com> to my broken_sites.acl. Then add > the ip to an allowed_ips.acl. > > Then I http_access allow the ips list > > And skip peeking at the broken site. > > acl broken_sites ssl::server_name_regex "/etc/squid3/acls/http_broken.txt" > ssl_bump peek !broken_sites > ssl_bump splice all > > I'm trying to understand why this is breaking and if I'm doing the right > thing in fixing it. > Please provide your whole squid.conf (except empty or # comment lines). We might need to see it all to find what the problem is. > > The second error I'm getting is: > > > The following error was encountered while trying to retrieve the URL: > https://*.agentimediaservices.com/*<https://%2A.agentimediaservices.co > m/*> > > Failed to establish a secure connection to 63.240.52.151 > > The system returned: > > (71) Protocol error (TLS code: > X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) > > SSL Certficate error: certificate issuer (CA) not known: > /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO > RSA Organization Validation Secure Server CA Same question. From what > I've read this means that I don't have the correct root ca? Is that > correct? If so is the fix to then go try to find the correct .crt and > add it to the standard ca-cert store? ( I'm on debian so > /usr/share/ca-certificates/Mozilla ) > > Again, is this correct as to what is going wrong and the correct fix? Well, first step is to ensure your ca-certificates package is up to date. That usually solves these. But not always, especially if the CA has been caught doing bad things and suddenly dropped. Or if they have begun issuing certs to clients before being accepted by the Mozilla CA list people. It could also be a problem with intermediary cert just being omitted by the server. In that case adding it to your server-wide cert store or configuring it to be loaded by Squid will be needed. Amos _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
