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 SSLProxyMachineCertificateChainFile. 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 balancers. -- Daniel Ruggeri
