[squid-users] HTTPS reverse proxy: SSL Certficate verification failed

Eric Veiras Galisson eric.veirasgalisson at gmail.com
Tue Apr 18 09:29:35 UTC 2017


I'm back with more information about my problem.

I put squid in front of https://fr.wikipedia.org, I generated a false
certificate for my test to avoid problems with my browser and... I still
have a problem with squid, the same as before.

I'm thinking that my problem does not come from the upstream certificate
itself (which could be the case with ours, but I don't think about
wikipedia's ;) and that the root cause is my custom squid build.

I'm running squid Debian Jessie version 3.4.8-6+deb8u4 and I recompiled
adding the following options:
- --enable-ssl --with-open-ssl="/etc/ssl/openssl.cnf"
- --enable-ssl --with-open-ssl
- --enable-ssl
- --enable-ssl --with-open-ssl --with-ssl-crtd

I tried these combinations and none of them solve my problem. I think I may
be missing some important compilation option but I can't find which.

Output of squid -v

Squid Cache: Version 3.4.8
Debian linux
configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr'
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var'
'--libexecdir=${prefix}/lib/squid3' '--srcdir=.'
'--disable-maintainer-mode' '--disable-dependency-tracking'
'--disable-silent-rules' '--datadir=/usr/share/squid3'
'--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline'
'--disable-arch-native' '--enable-async-io=8'
'--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap'
'--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client'
'--enable-follow-x-forwarded-for'
'--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB'
'--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper'
'--enable-auth-ntlm=fake,smb_lm'
'--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group'
'--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi'
'--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--enable-ssl'
'--with-open-ssl' '--enable-ssl-crtd' '--disable-translation'
'--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3'
'--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536'
'--with-large-files' '--with-default-user=proxy'
'--enable-build-info=Debian linux' '--enable-linux-netfilter'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE
-fstack-protector-strong -Wformat -Werror=format-security -Wall'
'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat
-Werror=format-security'


On Tue, Apr 4, 2017 at 2:14 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 3/04/2017 8:38 p.m., Eric Veiras Galisson wrote:
> > On Sun, Apr 2, 2017 at 10:27 AM, Amos Jeffries wrote:
> >
> >> That Squid->server connection has zero difference between the browser
> >> and the command line tool connecting to a reverse-proxy, or when both
> >> are using opaque (non-Bumped) CONNECT tunnels. So one working and the
> >> other not is impossible.
> >>
> >
> > Yes, I understand this. My problem now is finding what is failing in my
> > setup.
> >
> > Eric.
> >
>
> I think you are going to have to resort to packet tracing with wireshark
> on the Squid->server connection. :-( good luck.
>
> Amos
>
>


-- 
Eric Veiras Galisson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170418/ef4e5204/attachment.html>


More information about the squid-users mailing list