Am 13.04.2016 um 19:49 schrieb Rainer Jung:
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>.
We could pass the worker name from mod_proxy to mod_ssl via a connection
note, similar to currently already passing the SNI name via the
connection note proxy-request-hostname.
I guess we need to prototype something.
Regards,
Rainer
