httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <>
Subject Re: Small things to do
Date Tue, 08 Nov 2011 23:52:26 GMT
On 11/8/2011 5:37 PM, Graham Leggett wrote:
> Currently in our environment we have reverse proxies connecting to
> client-cert-authenticated backends, and one of the things we can't do
> is this:
> <VirtualHost ...>
>   <Location /foo>
>      ProxyPass https://some.where.back.there/foo
>      ...
>   </Location>
>   <Location /bar>
>      ProxyPass https://some.where.different/bar
>      ...
>   </Location>
> </VirtualHost>
> where "https://some.where.back.there" and
> "https://some.where.different" are authenticated by separate sets of
> client certs and separate CA certs.
> We do some nasty php to get around this, it isn't ideal. It is nice to
> have though, and shouldn't block 2.4.
> Regards,
> Graham
> -- 

   I'd have to set up a test case to mimic what you have, but as I
understand it, the SSLProxyMachineCertificateFile at the vhost level
should have both client certs in use within the file. When connecting to
both backends, mod_proxy's client cert callback should pick the correct
client cert from those in the file already (if you look in the code it
actually uses X509_NAME_cmp on each item in the store)... This was one
of the things I verified with my patch for

   One thing I know for certain that does not fall in line with this is
if some.where.back.there and some.where.different are signed out of the
same CA, but you wish to send different client certs based on path (such
a use case exists, silly as it may seem in my eyes). Is this more in
line with what you are doing? If not, can you email me directly or share
a bit more of a complete example configuration? I have a few test CA's I
stood up for the patch mentioned above that I wouldn't mind taking a
crack at this one. FWIW, In all of my test cases I used ProxyPass to

Daniel Ruggeri

View raw message