I have lots of servers which access various external webservices, most of which use SSL, some of which require client certificates. I would like to centralize the configuration of client certs and dissociate the presentation layer from the underlying servers.
While I could use Squid to proxy the requests, I can't see from the docs how to tell Squid to select a client certificate specific to the target webservice. Is this possible?
One approach would be to maintain a gang of stunnel instances beyond the Squid proxy, then configure the client software to use http requests with a URL rewriter to route the request via the appropriate stunnel instance, however that will break if I get a XML response referencing a HTTPS DTD (unless I rewrite the content with a full MITM).
Is there another solution?
The problem with re-writing 'https' to 'http' is that it then breaks any additional resources with an http URI - since the protocol adapter will then convert these back to https!
I came across this article which addressed the problem of adding a client certificate to a proxied connection - which is potentially a solution. But does require that the client be configured to use a proxy, there are also problems around naming things and how to get it working with split DNS. Admittedly not huge problems, but it got me thinking that what I am describing here is the pattern used by most CDN providers - hence I am currently considering using Apache Traffic Server as the intermediate component - this allows use of split DNS, seperate SSL channels between the client and the origin, and client certificates for the communication with the origin server.