Re: New segfault with 2.4.20 with mod_perl
r->useragent_addr is assigned on ap_read_request (http_core.c), called from ap_process_http_(async_)connection called from process_connection hook (APR_HOOK_REALLY_LAST). The SEGV occured on process_connection hook, maybe before ap_process_http_(async_)connection, #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, c=, run_mode=) at modperl_callback.c:359 #12 0x55feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at connection.c:42 #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0) at connection.c:226 so r->useragent_addr had not been assigned any value.
Re: Allow SSLProxy* config in context?
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 and fills it with information received from the client and binds this cert to the session. Then it connects to the backend and uses this dynamic client cert in the handshake. I realise this is way beyond what Apache is capable of doing. But when looking into the limitations of SSLProxy..., one might consider an architecture, that would allow this. Maybe not immediately, but sometime down the road. Best, Christian -- Seek simplicity, and distrust it. -- Alfred North Whitehead
Re: Allow SSLProxy* config in context?
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 the
callback function about too much information
On 4/13/2016 10:04 AM, Graham Leggett wrote:
> 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:
>
>
> SSLProxyEnable foo
>
On one hand, this is an attractive idea because we have already
conditioned users/administrators to think about naming things via config
as you can do with authn providers and aliases.
On another hand, there are two gotchas I see. Giving something a name in
the configuration does not necessarily mean anything to the file or
certificate store because they aren't married in the same way that authn
providers and their aliases are. That is, if a different team/individual
manages the certificate store than the server configuration, the two
would have to keep in sync with additions or removals. This can be a
PITA if you have a short certificate lifecycle and have to renew often.
PLUS, there are cases where there may be many certificates in the file.
Combine that with the previous point and you could have a nightmare.
Perhaps in addition to or instead of aliases via config, something more
"dynamic" could be used where a DN, CN or some other attribute about the
cert that was parsed during startup becomes the representation?
...
#As today
SSLProxyMachineCertificateFile /path/to/file
#Plus new stuff
SSLProxyMachineCertificateCN myIdentity
#or
SSLProxyMachineCertificateDN /C=US/ST=Missouri/L=St.
Louis/O=BitNebula/CN=DanielRuggeri.bitnebula.com
This could be a really clean solution because the proxy can just pass
this name or DN to the ssl module in a note and the ssl module could
make the selection of certs from that data.
Stashing this (completely untested and thrown together) code around line
1778 in modules/ssl/ssl_engine_kernel.c could be all that's needed in
mod_ssl
char *preferred_name;
..
if (preferred_name) {
for (i = 0; i < sk_X509_INFO_num(certs); i++) {
X509_NAME *name;
info = sk_X509_INFO_value(certs, i);
name = X509_get_subject_name(inf->x509);
for(j = 0; j < X509_NAME_entry_count(name); j++) {
const char *this_name = //something
if (strcmp(preferred_name, this_name) == 0) {
modssl_proxy_info_log(c, info, APLOGNO(02279)
"found acceptable cert");
modssl_set_cert_info(info, x509, pkey);
return TRUE;
}
}
}
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(00)
SSLPROXY_CERT_CB_LOG_FMT
"server configuration requested certificate name %s"
"but it was not found in the certificate store",
preferred_name);
}
I haven't cracked open the proxy code to see what it would take to
collapse this down to a per proxy/worker/etc, but it doesn't seem like
terrible endeavor.
--
Daniel Ruggeri
Re: New segfault with 2.4.20 with mod_perl
I wrote the patch for ap_get_useragent_host, but am not familiar with the details of the report. Researching... On Wed, Apr 13, 2016 at 5:33 PM, Stefan Fritsch wrote: > Hi, > > I got a report about a new crash in mod_perl tests with 2.4.20: > > (gdb) bt > #0 apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, > sockaddr=0x0, flags=flags@entry=0) > at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663 > #1 0x55feaf0f513a in ap_get_useragent_host > (r=r@entry=0x7fd4461ee0a0, type=type@entry=3, > str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990 > #2 0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, > method=method@entry=0, a=, > a=) at mod_access_compat.c:279 > #3 0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at > mod_access_compat.c:332 > #4 0x55feaf0f8f30 in ap_run_access_checker > (r=r@entry=0x7fd4461ee0a0) at request.c:87 > #5 0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker > (my_perl=0x55feb2964a20, cv=) > at HookRun.c:235 > > Does this ring a bell with anyone? > > More info is at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824 > > Cheers, > Stefan > >
New segfault with 2.4.20 with mod_perl
Hi, I got a report about a new crash in mod_perl tests with 2.4.20: (gdb) bt #0 apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, flags=flags@entry=0) at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663 #1 0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, type=type@entry=3, str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990 #2 0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0, a=, a=) at mod_access_compat.c:279 #3 0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332 #4 0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87 #5 0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20, cv=) at HookRun.c:235 Does this ring a bell with anyone? More info is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824 Cheers, Stefan
Re: [Bug 53555] Scoreboard full error with event/ssl
On Monday 11 April 2016 18:12:43, Eric Covener wrote:
> On Mon, Apr 11, 2016 at 4:59 PM, wrote:
> > ServerLimit >= 10 * MaxRequestWorkers / ThreadsPerChild
>
> Hi Stefan -- I am curious -- prior to the recent patches, just
> having the extra capacity in ServerLimit didn't help / didn't help
> as much?
No, without the patches attached to the PR, ServerLimit does not play
any role for this issue. Only the scoreboard entries up to
(MaxRequestWorkers / ThreadsPerChild) will ever be used.
The state in 2.4 is that scoreboard entries of processes where some
threads have already terminated would get re-used, but there is no
code that terminate threads before the whole process terminates.
In trunk, I have added logic to terminate threads as soon as possible
during graceful finishing of a process. But the reason for that is
that I want old processes to use as few resources as possible. I am
not sure that new processes re-using the scoreboard entries of those
threads is a good idea. In the worst case, you could get
ThreadsPerChild processes that each use one worker slot in the
scoreboard area of a single process.
Maybe it would be better to remove the logic to re-use scoreboard
slots of processes which have already terminated some threads.
Instead, one could use the scoreboard area abore (MaxRequestWorkers /
ThreadsPerChild) more aggressively, and maybe even allocate some
additional slack space at startup. There could be these config knobs:
- the max number of fully active processes (ServerLimit)
- the max number of gracefully finishing processes ("OldServerLimit"?)
- what to do if OldServerLimit is reached during a graceful restart:
* reduce the max number of fully active processes accordingly
* kill off old processes
- what to do if OldServerLimit during normal operation:
* stop doing idle-cleanup of fully active processes [X]
* kill off old processes
Hmm. Now that I think of it, I think we should really do [X] if there
are too many old processes. The only question is how to define too
many.
Any thoughts?
Re: allow newlines in T_ESCAPE_LOGITEM?
It's especially important when doing log processing on Apache Hadoop, if you give uncompressed text files as input files to a Hadoop job, it'd split large log files on newlines to be processed on multiple nodes. That split should be done on a record boundary. On Wed, Apr 13, 2016 at 5:16 PM, Yann Ylavic wrote: > On Wed, Apr 13, 2016 at 11:08 PM, Eric Covener wrote: > > On Wed, Apr 13, 2016 at 5:05 PM, Daniel Lescohier > > wrote: > >> Isn't T_ESCAPE_LOGITEM also used by mod_log_config's use of > >> ap_escape_logitem? We rely on the API that data from HTTP requests > that are > >> logged in our mod_log_config logfiles are newline-escaped, so that one > line > >> in the logfile is parsed as one log entry. Our parsers first split on > >> newline to get records, then splits the fields of the record on the > field > >> delimiter to get fields, then it unescapes the backslash-escapes to get > the > >> original data for that field. > > > > You make a good point, it couldn't change and affect current callers > > of ap_escape_logitem(). > > IMHO, even ErrorLog shouldn't contain splitted lines (w/o "[date] > [level] [pid]" prefix). >
Re: allow newlines in T_ESCAPE_LOGITEM?
On Wed, Apr 13, 2016 at 11:08 PM, Eric Covener wrote: > On Wed, Apr 13, 2016 at 5:05 PM, Daniel Lescohier > wrote: >> Isn't T_ESCAPE_LOGITEM also used by mod_log_config's use of >> ap_escape_logitem? We rely on the API that data from HTTP requests that are >> logged in our mod_log_config logfiles are newline-escaped, so that one line >> in the logfile is parsed as one log entry. Our parsers first split on >> newline to get records, then splits the fields of the record on the field >> delimiter to get fields, then it unescapes the backslash-escapes to get the >> original data for that field. > > You make a good point, it couldn't change and affect current callers > of ap_escape_logitem(). IMHO, even ErrorLog shouldn't contain splitted lines (w/o "[date] [level] [pid]" prefix).
Re: allow newlines in T_ESCAPE_LOGITEM?
On Wed, Apr 13, 2016 at 5:05 PM, Daniel Lescohier wrote: > Isn't T_ESCAPE_LOGITEM also used by mod_log_config's use of > ap_escape_logitem? We rely on the API that data from HTTP requests that are > logged in our mod_log_config logfiles are newline-escaped, so that one line > in the logfile is parsed as one log entry. Our parsers first split on > newline to get records, then splits the fields of the record on the field > delimiter to get fields, then it unescapes the backslash-escapes to get the > original data for that field. You make a good point, it couldn't change and affect current callers of ap_escape_logitem().
Re: allow newlines in T_ESCAPE_LOGITEM?
Isn't T_ESCAPE_LOGITEM also used by mod_log_config's use of ap_escape_logitem? We rely on the API that data from HTTP requests that are logged in our mod_log_config logfiles are newline-escaped, so that one line in the logfile is parsed as one log entry. Our parsers first split on newline to get records, then splits the fields of the record on the field delimiter to get fields, then it unescapes the backslash-escapes to get the original data for that field. On Wed, Apr 13, 2016 at 3:43 PM, Eric Covener wrote: > Currently newlines get backslash-escaped if written to the errorlog. > This is via server/gen_test_char.c and stems from an ancient vuln > about escape sequences in log files potentially affecting peoples > terminals when cat'ed. > > On a few occasions I have worked with some libraries that return a > newline-formatted buffer that I'd love to dump to the error log > without scanning and splitting up into multiple log entries. > > I also occasionally see \n's from third-party mods once in a while. > > Any opinions on punching a hole for \n in T_ESCAPE_LOGITEM? >
Re: svn commit: r1732275 - in /httpd/httpd/branches/2.4.x: ./ include/ap_mmn.h include/http_connection.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/ssl_engine_kernel.c server/con
The old behavior was expected, and very, very useful. It
was made that way for a reason.
+1 on reverting to old behavior...
> On Apr 13, 2016, at 4:04 PM, Yann Ylavic wrote:
>
> On Thu, Feb 25, 2016 at 11:27 AM, wrote:
>> Author: icing
>> Date: Thu Feb 25 10:27:27 2016
>> New Revision: 1732275
>>
>> URL: http://svn.apache.org/viewvc?rev=1732275&view=rev
>> Log:
>> merging pre_close_connection hook, prep_lingering_close and
>> ap_update_child() additions from trunk
>>
>> Modified:
> []
>>httpd/httpd/branches/2.4.x/server/scoreboard.c
> []
>>
>> Modified: httpd/httpd/branches/2.4.x/server/scoreboard.c
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/scoreboard.c?rev=1732275&r1=1732274&r2=1732275&view=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/server/scoreboard.c (original)
>> +++ httpd/httpd/branches/2.4.x/server/scoreboard.c Thu Feb 25 10:27:27 2016
>> @@ -32,6 +32,7 @@
>> #include "http_main.h"
>> #include "http_core.h"
>> #include "http_config.h"
>> +#include "http_protocol.h"
>> #include "ap_mpm.h"
>>
>> #include "scoreboard.h"
>> @@ -457,7 +458,9 @@ static int update_child_status_internal(
>> int thread_num,
>> int status,
>> conn_rec *c,
>> -request_rec *r)
>> +server_rec *s,
>> +request_rec *r,
>> +const char *descr)
>> {
>> int old_status;
>> worker_score *ws;
> []
>> @@ -489,28 +495,44 @@ static int update_child_status_internal(
>> }
>> ws->conn_count = 0;
>> ws->conn_bytes = 0;
>> +ws->last_used = apr_time_now();
>> }
>> -if (r) {
>> -const char *client = ap_get_remote_host(c, r->per_dir_config,
>> - REMOTE_NOLOOKUP, NULL);
>> -if (!client || !strcmp(client, c->client_ip)) {
>> -apr_cpystrn(ws->client, r->useragent_ip,
>> sizeof(ws->client));
>> +if (status == SERVER_READY) {
>> +ws->client[0]='\0';
>> +ws->vhost[0]='\0';
>> +ws->request[0]='\0';
>> +ws->protocol[0]='\0';
>> +}
>
> This seems to have changed mod_status' output.
> Prior to this change the previous values were displayed until the
> worker was reused for another connection/request, now it is reset as
> soon as the worker is idle (i.e. each connection/request end).
>
> I prefer the new behaviour, but there are some concerns on users@...
Re: svn commit: r1732275 - in /httpd/httpd/branches/2.4.x: ./ include/ap_mmn.h include/http_connection.h include/scoreboard.h modules/generators/mod_status.c modules/ssl/ssl_engine_kernel.c server/con
On Thu, Feb 25, 2016 at 11:27 AM, wrote:
> Author: icing
> Date: Thu Feb 25 10:27:27 2016
> New Revision: 1732275
>
> URL: http://svn.apache.org/viewvc?rev=1732275&view=rev
> Log:
> merging pre_close_connection hook, prep_lingering_close and ap_update_child()
> additions from trunk
>
> Modified:
[]
> httpd/httpd/branches/2.4.x/server/scoreboard.c
[]
>
> Modified: httpd/httpd/branches/2.4.x/server/scoreboard.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/scoreboard.c?rev=1732275&r1=1732274&r2=1732275&view=diff
> ==
> --- httpd/httpd/branches/2.4.x/server/scoreboard.c (original)
> +++ httpd/httpd/branches/2.4.x/server/scoreboard.c Thu Feb 25 10:27:27 2016
> @@ -32,6 +32,7 @@
> #include "http_main.h"
> #include "http_core.h"
> #include "http_config.h"
> +#include "http_protocol.h"
> #include "ap_mpm.h"
>
> #include "scoreboard.h"
> @@ -457,7 +458,9 @@ static int update_child_status_internal(
> int thread_num,
> int status,
> conn_rec *c,
> -request_rec *r)
> +server_rec *s,
> +request_rec *r,
> +const char *descr)
> {
> int old_status;
> worker_score *ws;
[]
> @@ -489,28 +495,44 @@ static int update_child_status_internal(
> }
> ws->conn_count = 0;
> ws->conn_bytes = 0;
> +ws->last_used = apr_time_now();
> }
> -if (r) {
> -const char *client = ap_get_remote_host(c, r->per_dir_config,
> - REMOTE_NOLOOKUP, NULL);
> -if (!client || !strcmp(client, c->client_ip)) {
> -apr_cpystrn(ws->client, r->useragent_ip, sizeof(ws->client));
> +if (status == SERVER_READY) {
> +ws->client[0]='\0';
> +ws->vhost[0]='\0';
> +ws->request[0]='\0';
> +ws->protocol[0]='\0';
> +}
This seems to have changed mod_status' output.
Prior to this change the previous values were displayed until the
worker was reused for another connection/request, now it is reset as
soon as the worker is idle (i.e. each connection/request end).
I prefer the new behaviour, but there are some concerns on users@...
allow newlines in T_ESCAPE_LOGITEM?
Currently newlines get backslash-escaped if written to the errorlog. This is via server/gen_test_char.c and stems from an ancient vuln about escape sequences in log files potentially affecting peoples terminals when cat'ed. On a few occasions I have worked with some libraries that return a newline-formatted buffer that I'd love to dump to the error log without scanning and splitting up into multiple log entries. I also occasionally see \n's from third-party mods once in a while. Any opinions on punching a hole for \n in T_ESCAPE_LOGITEM?
Re: Allow SSLProxy* config in context?
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 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 . 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. Per directory or better in some new way per proxy backend (or proxy worker, proxy balancer). 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: SSLProxyEnable foo I would also like to prevent using per dir config, directory walk etc. Like (I think) proxy has it's backend config in per server structures which are lists of backends with names, the proxy ssl config could be a list of traditional ssl configs indexed by name. Name could be like you suggest a name given via additional directive attributes, or simply the balancer name (URL) given in the opening tag of the proxy container. What I haven't yet investigated is, how easy one could pass the worker or balancer name from mod_proxy to mod_ssl, so that mod_ssl can choose the correct ssl proxy config (without coupling the proxy and ssl details too close to each other). Another thing is getting a hand at the URL when the SSLProxy* directive is handled inside during directive parsing. Maybe similar to how mod_proxy does it. Yes, that looks like a deeper coupling of mod_ssl and mod_proxy, but the whole use case of mod_ssl as an client currently is coupled to the proxy setup, so it doesn't look wrong to "fully" support SSLProxy* per . 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. I guess we need to prototype something. Regards, Rainer
Re: Allow SSLProxy* config in context?
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. 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 . 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. Per directory or better in some new way per proxy backend (or proxy worker, proxy balancer). 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: SSLProxyEnable foo I would also like to prevent using per dir config, directory walk etc. Like (I think) proxy has it's backend config in per server structures which are lists of backends with names, the proxy ssl config could be a list of traditional ssl configs indexed by name. Name could be like you suggest a name given via additional directive attributes, or simply the balancer name (URL) given in the opening tag of the proxy container. What I haven't yet investigated is, how easy one could pass the worker or balancer name from mod_proxy to mod_ssl, so that mod_ssl can choose the correct ssl proxy config (without coupling the proxy and ssl details too close to each other). Another thing is getting a hand at the URL when the SSLProxy* directive is handled inside during directive parsing. Maybe similar to how mod_proxy does it. Yes, that looks like a deeper coupling of mod_ssl and mod_proxy, but the whole use case of mod_ssl as an client currently is coupled to the proxy setup, so it doesn't look wrong to "fully" support SSLProxy* per . I guess we need to prototype something. Regards, Rainer
Re: Allow SSLProxy* config in context?
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 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 > . 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: SSLProxyEnable foo Regards, Graham —
Revision to Release Question (esp rev 1692258)
I need a change for httpd/mod_ssl that was committed to the project's source code repository back on 2015-07-22 ( https://svn.apache.org/viewvc?view=revision&revision=1692258). I checked the source tarball for the most current release, httpd 2.4.20, downloaded from https://httpd.apache.org/download.cgi and it does not contain the revision even though that release was just issued 2016-04-11. Nor can I find any httpd 2.2.x release that contains the revision. How can I determine if and when a revision will be released?
Re: Allow SSLProxy* config in context?
> 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 experiments on how to solve this for the future? > > Not sure how to handle this since is in mod_proxy whereas > SSLProxy* are in mod_ssl. > is a dir_config still, not sure how we could make it > available/shared in/with mod_ssl... For the user it makes more sense to have Proxy settings inside . I always found the SSLProxy* confusing, although I can of course understand how implementation drove this... -Stefan
Re: Allow SSLProxy* config in context?
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 since is in mod_proxy whereas SSLProxy* are in mod_ssl. is a dir_config still, not sure how we could make it available/shared in/with mod_ssl... Regards, Yann.
Allow SSLProxy* config in context?
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 . Did anyone else already encounter a similar problem? Any thoughts or experiments on how to solve this for the future? Regards, Rainer
