[squid-users] Error negotiating SSL connection on FD 16

[Amos Jeffries]

On 2/04/20 5:42 pm, saiyan_gc wrote:
> Hi, thank you for reply me. Really appreciated!
> 
> I modified the squid conf file to:
> 
> http_port 2128 ssl-bump cert=/etc/squid/ssl_cert/example.com.cert \
>     key=/etc/squid/ssl_cert/example.com.private \
>     generate-host-certificates=on \
>     dynamic_cert_mem_cache_size=4MB
> https_port 3130 cert=/etc/squid/ssl_cert/example.com.cert \
>     key=/etc/squid/ssl_cert/example.com.private  
> auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
> auth_param basic children 5 startup=0 idle=1
> auth_param basic credentialsttl 2 hours
> auth_param basic casesensitive off
> acl ncsa_users proxy_auth REQUIRED
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump bump all
> http_access deny !ncsa_users
> http_access allow ncsa_users
> 
> And it's working for http_port. I put the cert into
> /etc/pki/trust-ca/source/anchor, and run a update-ca-trust command. And both
> aws cli and curl command work now. I am still not sure why https_port desn't
> work.


What you have here is:

* TLS explicit/forward proxy on port 3130.

This requires a regular server certificate for the proxy to use it as a
server encrypting traffic between the client and proxy.


* Interception of HTTPS sent in CONNECT tunnels over a plain-text proxy
on port 2128.

This requires a CA certificate to sign auto-generated server
certificates encrypting the traffic between client and origin server.


That difference in cert type is why when one port works, the other will not.

So first thing to do is make sure the cert types are correct.


> The previous setting work with curl but not aws cli, not sure why it failure
> during tls handshake.
> 

The second thing you will need to do, is find out which port the tool is
using and whether it is using it in the right mode of traffic.


Amos