[squid-users] Cert authority invalid failures.

Markey, Bruce bmarkey at steinmancommunications.com
Thu Apr 21 14:36:10 UTC 2016

acl internal src
acl wireless src

acl Safe_ports port 80
acl Safe_ports port 443
acl SSL_ports port 443

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


wccp_version 2
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
717.291.8758 (o) | bmarkey at steinmancommunications.com
8 West King St | PO Box 1328, Lancaster, PA 17608-1328

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Amos Jeffries
Sent: Thursday, April 21, 2016 8:59 AM
To: squid-users at 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
> The system returned:
> (71) Protocol error (TLS code: 
> 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.


squid-users mailing list
squid-users at lists.squid-cache.org

More information about the squid-users mailing list