On 20.02.2014 04:06, Dr Stephen Henson wrote:
On 19/02/2014 17:30, Falco Schwarz wrote:
The ECC certificate should in any way be skipped and not taken into account
when setting DH params.
I think that's a consequence of how SSL_get_certificate works. You
doesn't use either of these but an enhancement to tidy up
certificate
handling by Kaspar Brand does use SSL_CTX_use_certificate_chain_file.
That's part of the mod_ssl backport proposal currently in 2.4.x/STATUS.
(A previous version had a vote from jorton, but I'm not sure if he's
willing to refresh
On 07.02.2014 01:58, Daniel Kahn Gillmor wrote:
As part of the goal of dropping encrypted private key support, have you
considered using an agent-based framework for private keys?
I haven't, no, since an important aspect of that goal is to reduce
complexity in code. Dropping
On 03.02.2014 12:21, Dr Stephen Henson wrote:
On 02/02/2014 13:45, Kaspar Brand wrote:
Yes, this sounds like a useful extension - not only for the issue at
hand (i.e. SSL_CONF and stapling initialisation), but as a general
mechanism for retrieving all certificates of an SSL_CTX.
Added now
On 05.02.2014 18:13, Falco Schwarz wrote:
Kaspar, I ran into another issue when using an encrypted private key and
SSLOpenSSLConfCmd PrivateKey.
Again it fails to load the encrypted private key with the following errors:
That's by design, see [1]. Eventually I'd like to drop support for
On 04.02.2014 19:16, Falco Schwarz wrote:
After playing around a bit more with this patch, I discovered that
OCSPStapling cannot get the issuer certificate if you use only the
SSLCertificateFile directive. It works if you specify
SSLCertificateChainFile, though.
Error only using
On 05.02.2014 08:25, Brian Smith wrote:
It would be possible for a server to fetch and staple the OCSP
response only using the information from the server's end-entity
certificate.
Actually no - you can't properly fill in the CertID for the request
otherwise. From RFC 6960:
Request
On 01.02.2014 14:37, Dr Stephen Henson wrote:
I'm wondering how that could be avoided. Would a way to enumerate all
certificates in an SSL_CTX structure in OpenSSL help? Something like
SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate(). That
would
also set the current
On 01.02.2014 09:06, Falco Schwarz wrote:
The attached patch, to be applied on top of
mod_ssl-2.4.x-certkeyfile.diff, should take care of this problem.
Thank you for your quick reply. Your provided patch indeed solves the problem.
Everything now works just as expected.
Thanks for promptly
On 01.02.2014 13:21, Dr Stephen Henson wrote:
On 01/02/2014 07:43, Kaspar Brand wrote:
https://mail-archives.apache.org/mod_mbox/httpd-dev/201401.mbox/%3c52cc3c0d.1030...@velox.ch%3E
IMHO, yes.
Ok, committed to trunk with r1563420 and proposed for backport to 2.4.x
in r1563421. Review
On 31.01.2014 19:23, Falco Schwarz wrote:
I tested the patch altering the SSLCertificate* directives with httpd-2.4.x
and OpenSSL-1.0.2-dev:
https://people.apache.org/~kbrand/mod_ssl-2.4.x-certkeyfile.diff
Thank you for testing and for the report.
When putting certificate, CA and
On 30.01.2014 22:51, Jeff Trawick wrote:
On Thu, Jan 30, 2014 at 2:37 PM, Dr Stephen Henson
I wasn't sure of the details of the current implementation either. Would
it be
appropriate to have SSL_CONF usable with SSLProxy* too?
Surely yes is the answer; i.e., there is or will be some
On 29.01.2014 19:15, Graham Leggett wrote:
On 29 Jan 2014, at 16:24, kbr...@apache.org wrote:
URL: http://svn.apache.org/r1562500
Log:
propose SSLCertificate[Key]File/SSLCertificateChainFile overhaul for mod_ssl
Would it be possible to do the same for the SSLProxy* directives?
I think so.
On 14.01.2014 19:16, Graham Leggett wrote:
Most specifically, I am after the DN of the root certificate in the chain,
which in the past was the issuer in the client certificate, but in an
environment with intermediate certs this is no longer valid.
Would a syntax like this make some sense?
On 06.01.2014 08:46, Jan Kaluža wrote:
On 01/05/2014 11:10 AM, Kaspar Brand wrote:
I think I have no problem with changing the code to work as you
describe. I've only thought the way it works now is better, because
otherwise httpd could dump some files which it does not consider later
On 05.01.2014 15:09, Dr Stephen Henson wrote:
One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter
selection as the default in mod_ssl where supported? As things stand one
single
curve can be set (with default P-256) and it's an all or nothing choice, with
auto
On 03.01.2014 23:51, Dr Stephen Henson wrote:
On 28/12/2013 13:34, Kaspar Brand wrote:
FYI: in r1553824 (which I just committed to trunk), I'm now manually
shuffling things around to support per-cert chains - but would happily
drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you
On 02.01.2014 07:49, Jan Kaluza wrote:
At first sorry for late response, I was away during Christmas time. The
idea was to stay consistent with what DUMP_CERTS does, so DUMP_CA_CERTS
prints only filename of the cert so it can be later passed to certwatch.
I'm trying to load the certificate
On 18.11.2013 18:42, Kaspar Brand wrote:
On 18.11.2013 15:38, Dr Stephen Henson wrote:
For OpenSSL 1.0.2 this limitation is removed and you can have different
chains
for each certificate type (and for SSL structures too) and it just uses the
right one. This uses the function
On 21.12.2013 14:21, Ruediger Pluem wrote:
I guess a more general fix for this would be:
No further comments / feedback? If not then I would commit the patch.
The change looks fine to me (for easier comparison/review,
a whitespace-change-ignoring version is attached).
What would probably
On 11.12.2013 08:16, jkal...@apache.org wrote:
Author: jkaluza
Date: Wed Dec 11 07:16:28 2013
New Revision: 1550060
URL: http://svn.apache.org/r1550060
Log:
mod_ssl: Add -t -DDUMP_CA_CERTS option which dumps the filenames of all
configured SSL CA certificates to stdout the same way as
On 16.12.2013 20:25, William A. Rowe Jr. wrote:
On Sat, 14 Dec 2013 10:25:00 +0100
Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 14.12.2013 09:36, William A. Rowe Jr. wrote:
ProxyPass is not involved in the SSL forward proxy case at all, as I
already tried to point out.
Good, we've
On 17.12.2013 05:29, William A. Rowe Jr. wrote:
On Sat, 14 Dec 2013 10:25:00 +0100
Kaspar Brand httpd-dev.2...@velox.ch wrote:
On 14.12.2013 09:36, William A. Rowe Jr. wrote:
I beg to differ. We are left with a question of whether you are
responsible to defend the current behavior
On 26.11.2013 06:31, Kaspar Brand wrote:
As far as PR 55782 is concerned, the problem might be that
proxy_util.c:ap_proxy_determine_connection() does not take Host: header
differences into account when checking if an existing connection can be
reused (not sure). With SNI this would have
On 13.12.2013 15:52, Yann Ylavic wrote:
I can't tell whether this applies to all the other SSL parameters though
(most -if not all?- seem to be handled the same way in ssl_hook_Access(),
but I didn't do an exhaustive search to tell the truth, and maybe it is not
feasible here for all).
An
On 13.12.2013 20:17, William A. Rowe Jr. wrote:
I will agree, plain-text forward proxy listeners are unaffected, only
https:// listeners are tested for TLS/Host: mismatches. Also, if the
proxy request refers to a resource on the same proxy host, I suppose
that would also succeed. Although I
On 14.12.2013 09:36, William A. Rowe Jr. wrote:
I beg to differ. We are left with a question of whether you are
responsible to defend the current behavior, or whether I can simply
rely on RFC2817 to document that you are wrong,
RFC 2817 is irrelevant in the context of https: URIs (see its
On 12.12.2013 20:06, William A. Rowe Jr. wrote:
On Thu, 12 Dec 2013 09:28:16 +
Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote:
The reason is that you can define SSL parameters in Virtual hosts
like SSLCiphers or SSLProtocols. If Host header and SNI host match
you can be
On 12.12.2013 00:15, William A. Rowe Jr. wrote:
The rest of the SNI hostname processing steps are where the problem
lies. We still need to perform http headers - vhost translation after
the connection is established. If there's any desire to do SNI hostname
validation, that has to be limited
On 06.12.2013 01:17, Daniel Ruggeri wrote:
On 11/14/2013 5:54 AM, Joe Orton wrote:
a) people who want the ability to do filesystem backups without exposing
private keys to the set of admins who can read such backups; or e.g.
stick keys on NFS mounts, a similar requirement there.
b) people
On 30.11.2013 12:54, Graham Leggett wrote:
A question out of ignorance on my side. Will/can the above directive
be able to influence / somehow affect the ENGINE_ctrl_cmd_string()
openssl call needed when using dynamic engines in openssl (the
engine -pre and -post options specifically)?
Steve
On 27.11.2013 15:33, Dr Stephen Henson wrote:
On 27/11/2013 12:26, Nick Gearls wrote:
Maybe it's time to remove all redundant code in mod_ssl and use all features
of
OpenSSL; PKCS#11 will then be automatically supported and the maintenance of
mod_ssl will be simplified a lot.
PKCS#11
On 26.11.2013 09:29, Yann Ylavic wrote:
Another point is that SNI can not be an IP address according to the RFC
6066 :
3. Server Name Indication
[...]
Literal IPv4 and IPv6 addresses are not permitted in HostName.
and this is not specifically checked by mod_proxy before filling
On 26.11.2013 16:44, Graham Leggett wrote:
Hi all,
I am trying to use a pkcs11 engine within mod_ssl, and am digging as to how
this might be done.
The closest I've found is this patch
https://issues.apache.org/bugzilla/show_bug.cgi?id=52473
Anyone know if there is anything newer out
On 26.11.2013 10:38, Yann Ylavic wrote:
With the per worker (single) connections-reslist model, If the connection
were to be closed in determine_connection() when the Host mismatches, that
would be be a painful performance penalty when SNI is enabled (no option to
disable currently)...
With
On 26.11.2013 18:54, Yann Ylavic wrote:
Do you know if the port can be part of the SNI (eg. www.domain.net:8080)
so that it can be checked against the Host (which may contain that port)? I
can't find any reference about this.
Pure host names (FQDN!) only: RFC 6066, section 3.
Kaspar
On 26.11.2013 00:46, Yann Ylavic wrote:
Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
requests alone, or all forward proxy requests?
Maybe all forward proxy modules are concerned.
There is PR
55782
which I started to debug but did not finish (run out of time).
From
Thanks Jeff and Yann for your reviews. Fixed all items as suggested,
except for these ones:
The various calls to ssl_server_import_cert() in ssl_init_server_certs()
need different rc checking than before. (Now ssl_server_import_cert() can
return a fatal error instead of just a boolean.)
On 23.11.2013 13:56, Jeff Trawick wrote:
Maybe I'm still missing something here, but it looks like we can still
survive some calls to ssl_die() this logic. (I guess it doesn't make sense
to have a configuration where that could happen, but it is confusing
looking at the code.) Look at the
On 23.11.2013 15:03, Jeff Trawick wrote:
IMO it adds some future-proofing and self explanation to return early if
(rv != APR_SUCCESS rv != APR_NOTFOUND) instead of just checking for
equality with APR_EGENERAL.
Done with r1544812. Note that I'm working towards nukeing
On 18.11.2013 15:38, Dr Stephen Henson wrote:
Erk typo.. I of course meant ...after you call SSL_CTX_use_certificate_file
or
SSL_CTX_use_certificate_chain_file...
Yeah this was obvious... makes me cringe as well but here we go:
On 14.11.2013 12:54, Joe Orton wrote:
I've also always been a sceptic of this (mis)feature, so I hate to be
one to defend it. But demand comes from:
a) people who want the ability to do filesystem backups without exposing
private keys to the set of admins who can read such backups; or
On 17.11.2013 15:43, Dr Stephen Henson wrote:
On 13/11/2013 14:06, Kaspar Brand wrote:
- only supporting unencrypted private keys with SSLOpenSSLConfCmd
PrivateKey ...
Just to clarify that. Do you mean that SSLOpenSSLConfCmd shouldn't work with
encrypted private keys at all (e.g. return
On 23.10.2013 16:09, Kaspar Brand wrote:
On 21.10.2013 06:09, Trevor Perrin wrote:
I looked at your patch. Besides lack of passphrase-handling, it
breaks compatibility with existing config files (which assume
certs/keys are matched by type, not order).
I don't think that random order
On 13.11.2013 15:28, Dr Stephen Henson wrote:
I can vaguely recall that some of that code is designed to avoid the need to
enter the private key passphrase more than once by decrypting private keys
once
and storing the unencrypted forms in serialised form.
True, it allows to SIGHUP/SIGUSR1
On 21.10.2013 06:09, Trevor Perrin wrote:
I looked at your patch. Besides lack of passphrase-handling, it
breaks compatibility with existing config files (which assume
certs/keys are matched by type, not order).
I don't think that random order of multiple SSLCertificateFile and
On 22.10.2013 22:04, Dr Stephen Henson wrote:
Only bit I'm not completely sure about is the use of the SSL_CONF_CTX
structure
in modssl_ctx_t. It's done that way to avoid having to keep creating and
destroying the SSL_CONF_CTX for each directive but a quick test showed it was
creating
On 23.10.2013 16:48, Dr Stephen Henson wrote:
Well the handling remains in ssl_init_ctx_protocol but now an SSL_CONF_CTX
with
appropriate flags is created in moddssl_ctx_init. That is done because a valid
SSL_CONF_CTX is needed to call SSL_CONF_cmd_value_type in
ssl_cmd_SSLOpenSSLConfCmd.
On 14.10.13 10:51, Rob Stradling wrote:
Kaspar, I don't think data from 2010 (or even data from today) should be
assumed to be a reliable indicator of future use of non-RSA certs on
public sites.
Past performance is not indicative of future performance, as they use
to say in other
On 13.10.2013 00:43, Trevor Perrin wrote:
On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson
I *think* you then have to delve into ssl_pphrase_Handle() [note the comment
on
the way in] and somehow link the ServerInfo index with something you can use
to
recognise it later. The algorithm
On 11.10.2013 13:53, Dr Stephen Henson wrote:
IMHO though there needs to be a way to be able to tie a directive to a
certificate in mod_ssl anyway though. I'm surprised no one has needed to do
that
before.
I'm not sure we really need this for mod_ssl, as configuring more than
one cert per
On 09.10.2013 15:52, Dr Stephen Henson wrote:
It's tempting to just add a directive but after some thought I think expanding
Apache SSL_CONF handling is the way to go. This would add some future proofing
so we don't have to go through this all again in future.
Yes, please. Let's not perpetuate
On 01.10.2013 12:15, Dr Stephen Henson wrote:
That's just OpenSSL internals though. To handle ServerInfo properly in mod_ssl
IMHO you would need a new directive as there's no support for per-certificate
SSL_CONF commands: it wasn't intended to be used like that in its current
form.
This
On 29.09.2013 19:48, Hanno Böck wrote:
What needs to happen so this can be backported to 2.4?
Testing patches and reporting on its results e.g. (as previously
solicited in this thread). I have put a backport of the relevant trunk
commits under
On 28.09.2013 18:34, Dr Stephen Henson wrote:
How about something like:
int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
which can return things like...
SSL_CONF_TYPE_INVALID:unrecognised name.
SSL_CONF_TYPE_FILE: file name.
SSL_CONF_TYPE_DIR:directory name.
On 27.09.2013 20:58, Trevor Perrin wrote:
On Fri, Sep 27, 2013 at 9:16 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
It could probably be handled in
ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd(), but this would again
mean adding specific code for ServerInfoFile.
If we're adding specific
On 26.09.2013 23:59, Trevor Perrin wrote:
It doesn't work with filenames relative to the Apache root. The patch
I submitted uses ssl_engine_config.c:ssl_cmd_check_file() to map
relative to absolute filenames. I'm not sure how you'd do that with
SSLOpenSSLConfCmd?
It could probably be
On 25.09.2013 09:42, Plüm, Rüdiger, Vodafone Group wrote:
IMHO 0.9.8 seems reasonable for trunk and 2.4.
More formal question: Can we do this for 2.4 without breaking any promise?
Sorry for my somewhat naive question, but I guess you need to explain
more specifically (at least to me) what
On 23.09.2013 11:17, Joe Orton wrote:
On Sun, Sep 22, 2013 at 12:32:23PM +0200, Kaspar Brand wrote:
Feedback on this approach is again very welcome. Increasing the minimum
required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern,
IMO, as 0.9.7 is no longer maintained, and 0.9.8a
Thanks Joe and Rüdiger for your feedback. I'm going to finish and commit
part1 of the patch next (which seems uncontroversial), and wait a few
more days for opinions re: OpenSSL 0.9.8a, see also the separate thread.
Kaspar
On 25.09.2013 04:13, Trevor Perrin wrote:
The feature is checked in to the 1.0.2 branch [1], so we'd like to
expose it through Apache.
The patch is pretty simple. I suppose more tests or docs might be
needed (?), which I'm happy to write.
Anyways, is this something Apache is interested
On 10.07.2013 07:53, William A. Rowe Jr. wrote:
Color me confused. Where SSLv2 alone is dropped from the stock OpenSSL
build, 2.2.25 would not compile. The www.a.o/dist/httpd/Announcement
file calls out this patch as a workaround, which I will publish once
I have sorted why the binary win32
On 10.07.2013 10:32, William A. Rowe Jr. wrote:
If you frame this as a fast vote for adoption, and correct the text
in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
as well as the .html version, I'll post that in my morning (which is
still stuck on PDT from my travels).
On 10.07.2013 10:32, William A. Rowe Jr. wrote:
If you frame this as a fast vote for adoption, and correct the text
in https://dist.apache.org/repos/dist/release/httpd/Announcement2.2.txt
as well as the .html version, I'll post that in my morning (which is
still stuck on PDT from my travels).
On 05.07.2013 21:25, rj...@apache.org wrote:
Author: rjung
Date: Fri Jul 5 19:25:28 2013
New Revision: 1500108
URL: http://svn.apache.org/r1500108
Log:
mod_ssl: Fix SNI for backend when compiled against
OpenSSL without support for SSLv2.
PR 55194.
Followup to r1497466. Does not
On 10.04.2013 02:49, Lam, Eugene wrote:
Was Re: SSLProxyCheckPeerCN / ProxyPreserveHost issue
So, what do folks think about adding this directive to use the
connection hostname for SNI and the SSLProxyCheckPeerCN feature?
Would such a directive be beneficial? It seems a number of users who
On 21.06.2012 18:17, b...@apache.org wrote:
Author: ben
Date: Thu Jun 21 16:17:41 2012
New Revision: 1352596
URL: http://svn.apache.org/viewvc?rev=1352596view=rev
Log:
RFC 5878 support.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/ssl/mod_ssl.c
On 11.01.2013 23:53, minf...@apache.org wrote:
Author: minfrin
Date: Fri Jan 11 22:53:50 2013
New Revision: 1432322
URL: http://svn.apache.org/viewvc?rev=1432322view=rev
Log:
mod_ssl: Allow the SSLUserName to be used to control the username passed
by the FakeBasicAuth option. PR52616.
On 04.01.2013 22:40, Stefan Fritsch wrote:
On Thursday 03 January 2013, Joe Orton wrote:
Maybe the wording of pkg-config's --static option is somewhat
misleading. It doesn't force linking against the static libs
(i.e. lib{ssl,crypto}.a), but outputs the libraries from
openssl.pc's
On 03.01.2013 12:20, Joe Orton wrote:
add --static to pkg-config invocations, so that libraries for
static linking are also taken into account (PR 54252 - note that
the additional flags will only appear in modules/ssl/modules.mk
and ab_LDFLAGS, so potential side effects are limited)
This is
On 18.09.2012 15:05, Joe Orton wrote:
one minor nit/bikeshed-colour-review:
- APR_ADDTO(MOD_SSL_LDADD, [-export-symbols-regex ssl_module])
+ APR_ADDTO(MOD_LDFLAGS, [-export-symbols-regex ssl_module])
this is currently equivalent but keeping _LDADD seems better.
No
On 18.09.2012 17:55, Ben Laurie wrote:
though I still have to actually install openssl somewhere,
which would be irritating if I had to do any serious development. That
said, I could probably figure out how to work around that if I needed
to...
Something like the following will make your
On 23.08.2012 09:22, Kaspar Brand wrote:
On 17.08.2012 10:11, Joe Orton wrote:
On Thu, Aug 16, 2012 at 08:36:31PM +0200, Kaspar Brand wrote:
I wonder if we should add support for module-specific CFLAGS etc.,
which would always appear before the EXTRA_XXX stuff in the compile
and link commands
On 16.09.2012 08:00, Kaspar Brand wrote:
I have committed an improved version in r1385214
Um, make that read r1385216. I left out the acinclude.m4 changes in the
first attempt, unfortunately.
Kaspar
On 02.09.2012 14:04, Michael Felt wrote:
The simple part first. AIX has a default install of openssl.
-- however, the name of the library is libssl.a - see attachment for a
filelist of what is included in openssl.base
Ok, this also shows that the AIX package does not include a pkg-config
file
On 27.08.2012 15:42, Michael Felt wrote:
FYI: I get an error message from configure that I do not understand.
+ ./configure
--enable-layout=AIX
--with-apr=/opt/bin/apr-1-config
--with-apr-util=/opt/bin/apu-1-config
On 17.08.2012 10:11, Joe Orton wrote:
On Thu, Aug 16, 2012 at 08:36:31PM +0200, Kaspar Brand wrote:
I wonder if we should add support for module-specific CFLAGS etc.,
which would always appear before the EXTRA_XXX stuff in the compile
and link commands, i.e. in rules.mk we would have
On 18.8.12 21:51, William A. Rowe Jr. wrote:
to drop the #ifndef around SSL_PROTOCOL_SSLV2 in ssl_private.h,
this should also make some of the other #if[n]def
OPENSSL_NO_SSL2
encapsulations unnecessary.
+ [wrowe] agreed the patch was wrong,
On 19.8.12 19:37, Dr Stephen Henson wrote:
On 19/08/2012 18:22, Kaspar Brand wrote:
(ssl.h is not customized by OpenSSL's Configure script, AFAICT you would
have to call openssl version -f and look for any flags set at compile
time.)
I.e., unless mod_ssl is explicitly compiled
On 19.8.12 19:59, Kaspar Brand wrote:
Ok, thanks for clarifying, I stand corrected. opensslconf.h is included
in ssl_private.h via #include openssl/x509_vfy.h, that's why the
current 2.2.x code is working as expected.
Um, for 2.2.x that should read: in ssl_toolkit_compat.h, and it's
actually
On 17.8.12 13:59, jor...@apache.org wrote:
Author: jorton
Date: Fri Aug 17 11:59:45 2012
New Revision: 1374214
URL: http://svn.apache.org/viewvc?rev=1374214view=rev
Log:
* modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for
missing decrypted private keys, and ensure that
On 12.8.12 20:01, Ben Laurie wrote:
On Sun, Aug 12, 2012 at 5:23 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
a workaround is to call configure with
suitable {CPP,LD}FLAGS, i.e.
CPPFLAGS=-I${openssl_build_dir}/include \
LDFLAGS=-L${openssl_build_dir} \
./configure ...
(when using
On 10.08.2012 01:55, William A. Rowe Jr. wrote:
An openssl 'make localinstall' could trivially create the lib, include
trees consisting entirely of symlinks to the origin files in the same
build tree, and create an appropriate openssl.pc file describing the
link steps required to
On 06.08.2012 23:36, Rainer Jung wrote:
On 05.08.2012 10:10, Kaspar Brand wrote:
It's a useful enhancement if mod_ssl can be linked with a specific
OpenSSL version in a non-default location, but the current approach has
at least one problem, AFAICT: it will only work if the directory pointed
On 06.08.2012 22:08, William A. Rowe Jr. wrote:
On 8/5/2012 10:10 PM, Kaspar Brand wrote:
On 05.08.2012 14:38, Guenter Knauf wrote:
Am 05.08.2012 10:10, schrieb Kaspar Brand:
1) use --with-ssl-builddir for linking with the static OpenSSL libraries
in that directory (and ignore --with-ssl
On 08.07.2012 10:30, Kaspar Brand wrote:
On 06.07.2012 14:41, b...@apache.org wrote:
Author: ben
Date: Fri Jul 6 12:41:10 2012
New Revision: 1358167
URL: http://svn.apache.org/viewvc?rev=1358167view=rev
Log:
Work correctly with a development version of OpenSSL. I suspect
something
On 05.08.2012 10:10, Kaspar Brand wrote:
test feedback would be much appreciated (remember to run buildconf after
applying the patch to acinclude.m4, and before calling configure).
The patch attached to the previous message was missing an important
line, unfortunately (sorry to anybody who
On 05.08.2012 14:38, Guenter Knauf wrote:
Am 05.08.2012 10:10, schrieb Kaspar Brand:
1) use --with-ssl-builddir for linking with the static OpenSSL libraries
in that directory (and ignore --with-ssl in this case)
what about splitting into two arguments:
--with-ssl-include=
--with-ssl-lib
On 08.07.2012 22:33, Daniel Gruno wrote:
[ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs
[ ] 0: I don't care
[ ] -1: Don't adopt the system, because
Thanks for enduring your work on this - glad to see that it has become
comments.a.o. in the meantime! I'm in favor
On 06.07.2012 14:41, b...@apache.org wrote:
Author: ben
Date: Fri Jul 6 12:41:10 2012
New Revision: 1358167
URL: http://svn.apache.org/viewvc?rev=1358167view=rev
Log:
Work correctly with a development version of OpenSSL. I suspect
something similar is needed when there are two OpenSSL
On 01.06.2012 21:36, s...@apache.org wrote:
Author: sf
Date: Fri Jun 1 19:36:37 2012
New Revision: 1345319
URL: http://svn.apache.org/viewvc?rev=1345319view=rev
Log:
Add new directive SSLCompression to disable SSL-level compression.
PR: 53219
Submitted by: Björn Jacke bjoern j3e de,
On 23.05.2012 17:42, jor...@apache.org wrote:
Author: jorton
Date: Wed May 23 15:42:33 2012
New Revision: 1341905
URL: http://svn.apache.org/viewvc?rev=1341905view=rev
Log:
suexec: Add support for logging to syslog as an alternative to a
logfile.
* support/suexec.c (err_output)
On 20.05.2012 14:47, Daniel Gruno wrote:
This will effectively make for two (or three) new votes for adopting
each piece:
- Adopt a privacy policy for the docs and refer to the various tracking
methods used as they get implemented - see the draft at
On 07.05.2012 16:02, Daniel Gruno wrote:
With an impressive 8 x +1 binding votes and no -1's, as well as +2 from
other docs@ readers, I believe we can call this vote passed with flying
colors :).
Apologies for being late with this, but the specifics of the currently
used implementation
On 23.04.2012 17:11, Michael Weiser wrote:
I don't think so: I'm not directing the Proxy to connect to a different
host. I just make it send different SNI data to the configured backend
server and accept a different CN in the server's certificate.
I guess it boils down to the question of what
On 16.04.2012 16:47, Michael Weiser wrote:
So implementation-wise this will most likely have two parts of code:
1. Determining the hostname to put into SNI data depending on
ProxyPreserveHost somewhere in the reverse proxy module.
2. Putting that value into the SNI data in mod_ssl's
On 10.04.2012 12:38, Tom Evans wrote:
On Tue, Apr 10, 2012 at 1:38 AM, Jie Gao j@sydney.edu.au wrote:
Hi All
Would it be possible to expand the scope of ProxyPreserveHost to Location?
Regards,
Jie
I don't understand; ProxyPreserveHost affects the proxying apache
server, and
On 07.04.2012 00:34, Daniel Ruggeri wrote:
I wanted to bring this up here - seems like a few things are going on
that are confusing to me. I'll try to look into it when time becomes
available, but I thought someone might have an opinion off the bat.
Original Message
On 23.03.2012 18:11, Rainer Jung wrote:
It should be RewriteRule not RewriteMap in my previous mail. I
simplified the config to a single RewriteRule but forgot to adjst
subject and intro of my mail. The problem remains the same.
Doesn't that ring a bell - namely the one of PR 52774?
Kaspar
On 13.02.2012 14:56, Jim Jagielski wrote:
I'm calling a VOTE on releasing these as Apache httpd 2.4.1 GA.
NOTE: The -deps tarballs are included here *only* to make life
easier for the tester. They will not be, and are not, part
of the official release.
[X] +1: Good to go
[ ] +0: meh
101 - 200 of 308 matches
Mail list logo
