|
I found the answer to my problem. The SNI and Subject CN were different in my case and I was not peeking at step2 (meaning not looking at the server certificate) that is why my ACLs were ineffective. Regards, Sarfaraz From: Ahmad, Sarfaraz Forgot to add. Remote IP addresses are not expected to remain constant. So I cannot build ACLs that way. So ssl::server_name is the only other hope. From: Ahmad, Sarfaraz Hi, I need to provide access to a API service exposed on the internet to my clients. That API uses a certificate signed by a private CA. I don’t want to trust that private CA in my proxies (lest it gets abused and I end up trusting certificates in the proxy that I shouldn’t be. My clients would be unaware since I am bumping all the TLS connections
unless explicitly configured. ) To avoid that I tried ignoring the ssl validation error with sslproxy_cert_error directive and then splicing the connection. But its not working out. SubjectCN in that services’ certificate is “kube-apiserver” Ignore settings : acl broken_kubernetes ssl::server_name kube-apiserver sslproxy_cert_error allow broken_kubernetes sslproxy_cert_error deny all Splicing settings: acl no_ssl_bump_kubernetes ssl::server_name kube-apiserver acl step1 at_step SslBump1 acl step2 at_step SslBump2 acl step3 at_step SslBump3 ssl_bump peek step1 ssl_bump splice no_ssl_bump_kubernetes ssl_bump bump all Splicing settings are in the lower half of my config.
But I am still getting MITM’ed (bumped) and on the clients, I get a “Not Trusted by MyCA” certificate is being shown. Any ideas ? Regards, Sarfaraz |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
