[squid-users] FATAL: Unable to open HTTPS Socket

Yuri Voinov yvoinov at gmail.com
Wed Aug 26 09:31:43 UTC 2015

Hash: SHA256

this issue looks like very similar to bug 4188, isn't it?

WBR, Yuri

26.08.15 11:36, Amos Jeffries пишет:
> On 26/08/2015 6:51 a.m., Oliver Webb wrote:
>> TLDR Skip to ----------
>> I have squid 3.5.7 installed on linux with the following configure
>>  '--build=arm-linux-gnueabihf' '--prefix=/usr' '--localstatedir=/var'
'--libexecdir=/usr/lib/squid' '--srcdir=.' '--datadir=/usr/share/squid'
'--sysconfdir=/etc/squid' '--with-default-user=proxy'
'--with-logdir=/var/log' '--with-pidfile=/var/run/squid.pid'
'--enable-ssl' '--with-openssl' '--enable-ssl-crtd'
'--enable-delay-pools' '--enable-external-acl-helpers=session'
>> I have the following ports assigned in squid.conf:
>> http_port 3129
>> http_port 3128 intercept
>> https_port 3130 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/myCA.pem
>> I also have IPTables redirecting port 443 traffic to port 3130 and
port 80 traffic to 3128
>> For port 80 HTTP traffic the proxy works fine pages load except
blocked ones which the proxy successfully replaces which blocked message
>> Port 443 HTTPS traffic is successfully bumped by squid and the
certificate is replaced with the dynamically generated one.
>> ----------
>> The page squid serves over the browser-squid tunnel is the
ERR_DNS_FAIL error page with the %H hostname template code evaluated to
'http' (without quotes)
> That means one or more of these is most likely:
> A) the SNI value sent by the client was "http".
>  - that is invalid TLS protocol
> B) the Host header in the HTTP message was "Host: http:443" or "Host:
> http://blah"
>  - both are invalid FQDN
> C) the reverse-DNS for the IP address Squid is dealing with says "http"
>  - that is an invalid DNS record
> Maybe be more I've overlooked right now.
>> Also in the cache.log the following message appears after every HTTPS
>> FATAL: Unable to open HTTPS Socket
> For (B) and some of (A), try adding "debug_options 11,2 83,5" to your
> config file and see what the messages are doing in Squid.
>  If there are no HTTP messages, then the issue is in the TLS or DNS
> For the rest of (A), you will likely need to use packet captures to see
> what is happening on the connections both in and out of Squid
> (from-client and to-server). The TLS/SSL library command line test tools
> may also be useful there to track the TLS protocol details Squis is not
> showing well yet.
> For (C) try resolving the domain name "http" from the command line of
> your Squid machine.
> If you configured dns_nameservers directive in squid.conf repeat that
> test using each of the listed servers.
> If the machine normal lookup works but the Squid NS fail, you may need
> to add dns_defnames and dns_appenddomain directives to your squid.conf
> with details that match what /etc/resolv.conf tells the machine to do.
> PS. The best setup IMHO, is to remove the dns_* directives entirely and
> let Squid use the normal /etc/resolv.conf settings.
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

Version: GnuPG v2

More information about the squid-users mailing list