httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Wed, 13 Apr 2016 17:49:11 GMT
Am 13.04.2016 um 17:04 schrieb Graham Leggett:
> On 13 Apr 2016, at 12:40 PM, Rainer Jung <> 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 

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.



View raw message