Woah, quite a patch! Tested on OS X 15.4 and all framework/trunk
and mod_h2/trunk tests pass.
Tried to move SSLProxyEngine into the configs. Worked like
a charm, both when needed and when not. When it was missing I
properly got an internal server error and log:
AH01961: SSL Proxy requested for t
On Thu, Apr 21, 2016 at 9:31 AM, Stefan Eissing
wrote:
> Not in today, but will have a look tomorrow.
On Thu, Apr 21, 2016 at 10:53 AM, Rainer Jung wrote:
> It'll take me a few days, likely over the weekend. Thanks a bunch already.
Thanks Stefan and Rainer.
Here is a v3 which passes the tests
Am 21.04.2016 um 00:35 schrieb Yann Ylavic:
On Tue, Apr 19, 2016 at 9:36 PM, Yann Ylavic wrote:
What changed is:
1. SSLProxy* directives are now per directory (restricted to
Server/VirtualHost and ), so all the internal struct members
have been move from SSLSrvConfigRec to SSLDirConfigRec;
2.
Not in today, but will have a look tomorrow.
> Am 21.04.2016 um 00:35 schrieb Yann Ylavic :
>
>> On Tue, Apr 19, 2016 at 9:36 PM, Yann Ylavic wrote:
>>
>> What changed is:
>> 1. SSLProxy* directives are now per directory (restricted to
>> Server/VirtualHost and ), so all the internal struct me
On Tue, Apr 19, 2016 at 9:36 PM, Yann Ylavic wrote:
>
> What changed is:
> 1. SSLProxy* directives are now per directory (restricted to
> Server/VirtualHost and ), so all the internal struct members
> have been move from SSLSrvConfigRec to SSLDirConfigRec;
> 2. The merge happens from main server t
On Fri, Apr 15, 2016 at 1:30 PM, Yann Ylavic wrote:
> On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic wrote:
>>
>> IIUC, the block is a per_dir context already, which can/could
>> accept any directive provided their ap_check_cmd_context() allows it
>> (we may need to declare a new PROXY_CONF).
>>
>
Am 15.04.2016 um 13:30 schrieb Yann Ylavic:
On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic wrote:
IIUC, the block is a per_dir context already, which can/could
accept any directive provided their ap_check_cmd_context() allows it
(we may need to declare a new PROXY_CONF).
So how about making pe
On Thu, Apr 14, 2016 at 9:57 AM, Yann Ylavic wrote:
>
> IIUC, the block is a per_dir context already, which can/could
> accept any directive provided their ap_check_cmd_context() allows it
> (we may need to declare a new PROXY_CONF).
>
> So how about making per_dir SSLProxy* directives, restricte
Am 15.04.2016 um 03:20 schrieb Daniel Ruggeri:
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
a
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
Am 14.04.2016 um 02:57 schrieb Daniel Ruggeri:
On 4/13/2016 2:22 PM, Rainer Jung wrote:
We could pass the worker name from mod_proxy to mod_ssl via a
connection note, similar to currently already passing the SNI name via
the connection note proxy-request-hostname.
+1 on the connection note i
On Wed, Apr 13, 2016 at 7:49 PM, Rainer Jung wrote:
> Am 13.04.2016 um 17:04 schrieb Graham Leggett:
>>
>> 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 d
Rainer,
There is a commercial apache-based reverse proxy in Switzerland
(with substantial market share) which is able to use / create
a client certificate _per_ session.
So the client connects to the RP, performs authentication. When
creating the session serverside, the RP creates a client cert
On 4/13/2016 2:22 PM, Rainer Jung wrote:
>
> We could pass the worker name from mod_proxy to mod_ssl via a
> connection note, similar to currently already passing the SNI name via
> the connection note proxy-request-hostname.
+1 on the connection note idea, but see below about having to inform th
Am 13.04.2016 um 19:49 schrieb Rainer Jung:
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 beco
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
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 c
> Am 13.04.2016 um 12:55 schrieb Yann Ylavic :
>
> On Wed, Apr 13, 2016 at 12:40 PM, Rainer Jung wrote:
>>
>> To me it looks like the "right" way of handling SSLProxy* config would be
>> per .
>
> ++1
+1
>
>> Did anyone else already encounter a similar problem? Any
>> thoughts or experiment
On Wed, Apr 13, 2016 at 12:40 PM, Rainer Jung wrote:
>
> To me it looks like the "right" way of handling SSLProxy* config would be
> per .
++1
> Did anyone else already encounter a similar problem? Any
> thoughts or experiments on how to solve this for the future?
Not sure how to handle this si
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 demande
20 matches
Mail list logo
