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

Alex Rousskov rousskov at measurement-factory.com
Tue Dec 5 21:08:51 UTC 2017


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.


More information about the squid-users mailing list