>> 18.05.16 3:11, Robert W Weaver пишет: >>> The issue is I need to connect to a site that requires client >>> authentication. Don't want to put the key and cert on each individual >>> user, so instead want the key and cert on the proxy. >>> Diagram:
>>> User A ---> Squid S ---> Server B >>> ^ ^ >>> | +-- TLS client authentication >>> +-- cleartext okay On Wed, 18 May 2016 17:48:26 +1200, Amos Jeffries <squ...@treenet.co.nz> wrote: > On 18/05/2016 10:05 a.m., Yuri Voinov wrote: >> >> ..... and a bit below in squid.conf.documented we can see..... >> >> # SSL OPTIONS >> # >> ----------------------------------------------------------------------------- >> >> # TAG: sslproxy_client_certificate >> # Client SSL Certificate to use when proxying https:// URLs >> #Default: >> # none >> >> # TAG: sslproxy_client_key >> # Client SSL Key to use when proxying https:// URLs >> #Default: >> # none >> >> Ta-daaaaaaaa! > > You are the one getting it wrong here Yuri :-( I am celebrating Yuri's ta dah. The clue to squid.config.documented was crucial, and the specific hint to sslproxy_client_* was what was missing. From S to B is now working properly. Squid is now in the middle, and is performing authentication to server B properly. > * clientca= is for listening ports. He wants that conectio to be cleartext. > * sslproxy_* directives are for generic DIRECT connections. He wants a > specific proxy<->server connection to be TLS authenticated. > For the S<->B connection to use client certificates. cert= and key= on > the cache_peer directive defining that link are correct. > But there are twe other details that need to happen for it to work: > * the server actually challenge for the proxies 'client' cert, and > * the server trust the CA which signed that cert. This is happening. I'd generated a CSR and had the CA that is the "owner" of server B sign it for me. We are cool. > The world of "not working" is a very big place. We need more details of > *how* its not working in order to have any guideposts towards what the > problem actually is. As Yuri used to say a lot, my psychic friend is on > holiday. It is now working to an acceptable point, although there is an enhancement that would be nice. Right now, 1. A connects to S, requests https://B/some/image.png 2. S connects to B over TLS, performs client authentication, gets /some/image.png (or pulls from cache) 3. A converts to TLS to S, pulls down data. This is fine, its just that there is an unnecessary encrypt/decrypt between A and S. The connection is inside a controlled data center (on the same switch, perhaps on the same ESX host) so I'm not concerned about security -- not to mention the cached data isn't especially sensitive. So this last bit is just an enhancement, a nice to have. Its the opposite of SSL termination for accelerators, so I suspect its possible, just don't know how to do it. Coffee (or a favorite beverage) all around! --woody -- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users