httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Wed, 13 Apr 2016 15:04:34 GMT
On 13 Apr 2016, at 12:40 PM, Rainer Jung <rainer.jung@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.

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>

Regards,
Graham
—


Mime
View raw message