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@xxxxxxxxxxxxx> 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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
