httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <DRugg...@primary.net>
Subject Re: Allow SSLProxy* config in <Proxy> context?
Date Fri, 15 Apr 2016 01:20:17 GMT

On 4/14/2016 3:08 AM, Rainer Jung wrote:
> Your idea to allow selecting a client cert based on CN or DN sounds
> attractive to me as well. But since it wouldn't help with other per
> backend settings (like different Verify settings) we might even think
> about combining both. As long as your only problem would be client
> certs, you can select via CN or DN and keep the config vhost global,
> but once you need more adjustments per backend, you would start to
> configure SSLProxy* inside <Proxy ...>.
>
> WDYT? 

Yep! Agreed - I was focusing on the use case presented, but didn't think
about other cases such as different SSLProxyVerify settings and friends
such as this. I'd cast a vote for the more comprehensive solution you
and Graham shared that makes each option available in a directory
context. Adding yet another directive would satisfy this one use case,
but the bigger picture would serve users better and be less confusing.

Food for thought - I haven't dug into these...
* Not sure if it would be a handy target of opportunity or PITA... Since
ProxyPass is currently server/vhost/dir configurable, should we think to
include this capability as arguments to ProxyPass/BalancerMember, too?
* Maybe I missed it, but I don't think the proposed ideas truly provide
per-backend configuration. Rather, they provide configuration for all
backends in a dir context if you land on a balancer containing many
targets. Is that OK, or should we be thinking about ways to make it even
more granular? (the use cases that come to mind are rather contrived, so
I may be overthinking it)
* Would each of these per-dir configs post-merge result in a distinct
SSL_CTX that needs to be created in mod_ssl? If so, does that require
significant refactoring in mod_ssl or does the proxy module manage these?

-- 
Daniel Ruggeri


Mime
View raw message