Am 13.04.2016 um 17:04 schrieb Graham Leggett:
On 13 Apr 2016, at 12:40 PM, Rainer Jung <rainer.j...@kippdata.de> wrote:
I stumbled into a situation where a reverse proxy had two different backends
behind the same VHost of the proxy. Both backends demand client certs as
becomes more and more common for services today. Unfortunately the CA which
issues the client certs in both cases is the same CA, but the demanded client
cert is individual to the backend services.
As far as I can see, this is currently not configurable. The
SSLProxyMachineCertificateFile and SSLProxyMachineCertificatePath only work on
the VHost level and the client cert detection algo in ssl_callback_proxy_cert()
chooses the first client cert it can find which was issued b the right CA. No
way to distinguish further.
To me it looks like the "right" way of handling SSLProxy* config would be per
<Proxy>. Did anyone else already encounter a similar problem? Any thoughts or experiments
on how to solve this for the future?
I looked at this a while back.
The catch is that mod_ssl forces us to declare SSL certs and keys server wide,
not per directory, loaded and parsed at startup. We however want to specify
certs per directory.
Per directory or better in some new way per proxy backend (or proxy
worker, proxy balancer).
What I had in mind was a syntax where the certs were named, for example:
SSLProxyCertificate foo /path/to/foo.cert
Followed somewhere else by:
<Proxy …>
SSLProxyEnable foo
</Proxy>
I would also like to prevent using per dir config, directory walk etc.
Like (I think) proxy has it's backend config in per server structures
which are lists of backends with names, the proxy ssl config could be a
list of traditional ssl configs indexed by name. Name could be like you
suggest a name given via additional directive attributes, or simply the
balancer name (URL) given in the opening <Proxy URL> tag of the proxy
container.
What I haven't yet investigated is, how easy one could pass the worker
or balancer name from mod_proxy to mod_ssl, so that mod_ssl can choose
the correct ssl proxy config (without coupling the proxy and ssl details
too close to each other). Another thing is getting a hand at the URL
when the SSLProxy* directive is handled inside <Proxy> during directive
parsing. Maybe similar to how mod_proxy does it.
Yes, that looks like a deeper coupling of mod_ssl and mod_proxy, but the
whole use case of mod_ssl as an client currently is coupled to the proxy
setup, so it doesn't look wrong to "fully" support SSLProxy* per <Proxy>.
I guess we need to prototype something.
Regards,
Rainer
