On 14.10.2015 14:55, Eric Covener wrote:
> On Wed, Oct 14, 2015 at 8:37 AM, Stefan Eissing
> wrote:
>> Any advice on how to add a test host (e.g. real port) to our test suite in
>> the most compatible way?
>
> 1426878 added an SSL vhost. It seems like there is a
On 16.10.2015 12:45, Stefan Eissing wrote:
> If the blacklist in RFC 7540 proves to be totally bogus, I'd favor
> ditching it in our server checks.
Sharing Yann's surprise about this huge blacklist... I'm also wondering
if this won't become a Sisyphean task, in the end (will the httpwg
regularly
On 10.10.2015 20:14, Stefan Eissing wrote:
> Testing 2.4.17 release tar ball on OS X 10.11 (event/worker/prefork, openssl
> 1.0.2d):
>
> t/ssl/varlookup.t ... 1/81 # Failed test 55 in
> t/ssl/varlookup.t at line 105 fail #55
> # Failed test 56 in t/ssl/varlookup.t at line 105
On 09.10.2015 19:40, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.17 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.17 GA.
>
> [X] +1: Good to go
Tested with mod_ssl
On 03.10.2015 12:07, Reindl Harald wrote:
> Am 03.10.2015 um 11:16 schrieb Kaspar Brand:
>> What do you have security.OCSP.require set to? If it's "true" (a setting
>> no longer configurable through the UI, BTW, see
>> https://bugzilla.mozilla.org/show_bug.cgi?id=
On 01.10.2015 16:32, Reindl Harald wrote:
> Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:
>> The question is: What happens on Firefox side. Of course it still tries to
>> get to the OCSP server, but it should not cause an error on Firefox side if
>> this does not work.
>
> no,
On 29.09.2015 18:24, Reindl Harald wrote:
> i just restarted the servers and disabled stapling since all our
> servcies where unreachable (before i write the second mail 5 different
> hosts with several sites where affected)
>
> in fact the error caching does more harm than benefits - IHMO a
On 17.10.2014 19:25, Kaspar Brand wrote:
> On 17.10.2014 12:02, Takashi Sato wrote:
>> SSLv3 is now insecure (CVE-2014-3566, POODLE)
>> Let's disable SSLv3 by default, at least trunk.
>>
>> SSLProtocol default is "all".
>> <http://httpd.apache.org/do
On 05.09.2015 13:06, Tim Bannister wrote:
> It's not just conventional browsers. I think automated / embedded
> HTTP clients will also benefit from stapling, either because
> networking filters would block a conversation between the client and
> the CA's OCSP responder, or the extra latency from
On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <httpd-dev.2...@velox.ch> wrote:
>> I'm also very sceptical that a higher percentage of handshakes with
>> stapled responses (how much exactly?) will lead browser vendors to
>> switch
On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 1. The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would put it.
>
> Re: "unsolicit
On 04.09.2015 17:54, Rob Stradling wrote:
> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> enabled. Browsers aren't likely to start hard-failing by default until
> that % is a lot higher.
>
> The vast majority of the servers that have OCSP stapling enabled are
> running
On 02.09.2015 01:54, Jeff Trawick wrote:
> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>> today's situation, because this assessment misses the fact that with the
>> current RFC-6066-based implementation, stapling can't fully achieve the
>> goal of obviating OCSP queries
On 28.08.2015 19:27, Jeff Trawick wrote:
For one, it is appropriate for the default config is there to enable
practices which are reasonable in most situations, and OCSP Stapling is
widely accepted as an appropriate feature for HTTP servers to enable.
I have some doubts whether widely accepted
On 29.08.2015 17:56, olli hauer wrote:
On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
Thanks for the detailed explanation. So yes OCSP stapling is really
beneficial if it is possible for the server admin to set it up. But
it likely requires additional configuration steps outside of
On 14.8.15 20:01, Eric Covener wrote:
On Wed, Apr 15, 2015 at 12:02 PM, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
The other option to fix the problem which originally triggered this
investigation would be to simply replace cmd-server in
ssl_engine_config.c:836 with NULL, though it would
On 19.07.2015 17:24, Kaspar Brand wrote:
But, to be on the safe side, I think we could a) move the OBJ_create()
call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
For the record: I have now committed this to trunk with r1693792.
Kaspar
On 13.07.2015 16:03, Joe Orton wrote:
On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
@@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
free_dh_params();
+OBJ_cleanup();
+
return APR_SUCCESS;
From being burnt previously three or four
On 29.06.2015 15:14, Jan Pazdziora wrote:
How about just passing char * and doing all the mapping logic
including possible OBJ_create in parse_otherName_value? My goal here
is to have all the hard work of determining the semantics isolated
in one place.
Please see patch attached.
You're
On 01.07.2015 14:27, Ben Laurie wrote:
On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote:
The fundamental objection I have to enabling stapling by default in our
GA releases is that it would enable a phoning home feature (to the
CA's OCSP responders) as a side effect
On 22.06.2015 10:37, Jan Pazdziora wrote:
Please find a new patch attached which I hope covers all the
parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.
Thanks. Your implementation assumes that only a single otherName form
(msUPN) needs to be supported, but I would prefer to code it in a
On 23.06.2015 13:40, Stefan Eissing wrote:
Sorry for missing that: it is still dynamically linked.
Am 23.06.2015 um 13:39 schrieb Rainer Jung rainer.j...@kippdata.de:
Am 23.06.2015 um 11:34 schrieb Stefan Eissing:
Sorry to bother the list, but I am banging my head against the wall trying
On 19.06.2015 16:51, Jan Pazdziora wrote:
On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
I think a more generic way would to have something like
SSL_CLIENT_OID_oid_n, so that we wouldn't have to add a new field
each time.
In this case, that would be:
On 26.05.2015 10:33, Rainer Jung wrote:
I find it questionable. I would find it more natural to embed the params
in the cert files they apply to, so e.g. the DH params in the RSA cert
file and the EC params in the ECDH cert file and also to not require a
special order for the files which at
On 01.05.2015 16:29, s...@apache.org wrote:
Author: stsp
Date: Fri May 1 14:28:59 2015
New Revision: 1677149
URL: http://svn.apache.org/r1677149
Log:
mod_ssl namespacing: Make SSL_ASN1_STRING_to_utf8 a static function inside
ssl_util_ssl.c (no callers outside this file). The new static
On 01.05.2015 17:11, Stefan Sperling wrote:
I believe SSL_X509_INFO_load_path() should be inlined into
its only caller.
I'm +1 for this. The Low-Level CA Certificate Loading part in
ssl_util_ssl.c is / was only used by ssl_init_proxy_certs, so I would be
in favor of also moving
On 27.04.2015 17:04, Stefan Eissing wrote:
Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it
certainly needs more eyes before a backport proposal could be made.
There's also a TODO: we should have
On 28.04.2015 14:04, Tom Browder wrote:
On Tue, Apr 28, 2015 at 6:45 AM, Eric Covener cove...@gmail.com wrote:
about openssl 1.02 though -- what exactly do you see?
I see this when attempting to start apache:
/usr/local/apache2/bin/httpd: symbol lookup error:
/usr/local/apache2/bin/httpd:
On 29.04.2015 15:06, Tom Browder wrote:
On Wed, Apr 29, 2015 at 12:57 AM, Kaspar Brand httpd-dev.2...@velox.ch
wrote:
On 28.04.2015 14:04, Tom Browder wrote:
I have no system installed openssl,
Hmm, what platform is this? Are you sure there are no libcrypto/libssl
libraries somewhere under
On 23.02.2014 09:03, Kaspar Brand wrote:
On 22.02.2014 19:17, Falco Schwarz wrote:
Kaspar, I switched back to your version and realized, that the directive
SSLCertificateChainFile was always used in a VirtualHost.
If the directive is in server scope, the warning is written correctly
On 22.04.2015 18:54, Jim Jagielski wrote:
For me the time seems right to rip NPN out of trunk and only backport
the ALPN code to 2.4.
I'd be +1 for that.
So, to get one step further, and since there were no explicit objections
to removing NPN support so far (or arguments for keeping it,
On 22.04.2015 10:36, Jan Kaluža wrote:
On 04/22/2015 09:50 AM, Kaspar Brand wrote:
Fiddling with OpenSSL internals
looks rather scary to me, at least at first sight - perhaps there's an
API for clearing a CRL store in OpenSSL?
Unfortunately there's no such API in OpenSSL. There's caching
On 22.04.2015 10:52, Stefan Eissing wrote:
I made two small patches based on the feedback from Kaspar. One for
the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h,
On 22.04.2015 10:12, Stefan Sperling wrote:
On Wed, Apr 22, 2015 at 09:29:49AM +0200, Kaspar Brand wrote:
Sorry for having missed this in my previous review: we should also
#ifdef the SSL_RSSRC_EGD case in
ssl_engine_config.c:ssl_cmd_SSLRandomSeed(), to make sure that egd:...
settings
On 22.04.2015 18:45, Stefan Eissing wrote:
I understand your argument. My pov is of someone trying to bring
http/2 to the people. While bringing a new httpd on an existing
system seems easy, installing a new system openssl is more
challenging with its dependencies and the changes in hiding non
On 22.04.2015 21:30, Rainer Jung wrote:
Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h, just 10 lines above.
I've kept the new one and dropped
On 18.04.2015 19:03, s...@apache.org wrote:
Author: stsp
Date: Sat Apr 18 17:03:47 2015
New Revision: 1674542
URL: http://svn.apache.org/r1674542
Log:
mod_ssl: Check for RAND_egd() at configure time and only use it if present.
Fixes the build with LibreSSL which does not provide this
On 21.04.2015 12:20, Jan Kaluža wrote:
we used to have a patch against httpd-2.2.15 to add SSLDisableCRLCaching
option to not cache CRLs. I was trying to adapt this patch for
httpd-trunk and eventually include it upstream but now I'm in dead end.
The patch removes all the CRLs from the
On 16.04.2015 22:57, Stefan Sperling wrote:
On Wed, Apr 15, 2015 at 08:43:04PM +0200, Stefan Sperling wrote:
LibreSSL does not provide the RAND_egd() function.
This patch adds a configure check to allow building mod_ssl with LibreSSL.
Updated version following Kaspar Brand's suggestion to
On 14.04.2015 06:54, Kaspar Brand wrote:
On 13.04.2015 22:05, Ruediger Pluem wrote:
Shouldn't we only do that in case that vit-log.level is set to
main_server-log.level?
Don't we lose the configuration done by the user for this particular host
otherwise?
Yes, you're right - thanks
On 15.04.2015 18:36, Stefan Sperling wrote:
However, the actual issue here is that mod_ssl is squatting the SSL_
namespace.
Historically this may have made sense (it seems mod_ssl and OpenSSL have
shared history/authors). Bill Rowe suggested to try moving mod_ssl's
functions into the ap_
On 15.04.2015 20:43, Stefan Sperling wrote:
LibreSSL does not provide the RAND_egd() function.
This patch adds a configure check to allow building mod_ssl with LibreSSL.
Index: modules/ssl/config.m4
===
---
On 13.04.2015 22:05, Ruediger Pluem wrote:
On 04/08/2015 09:33 AM, kbr...@apache.org wrote:
Modified: httpd/httpd/trunk/server/config.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/config.c?rev=1672014r1=1672013r2=1672014view=diff
On 31.03.2015 19:12, j...@apache.org wrote:
Author: jim
Date: Tue Mar 31 17:12:51 2015
New Revision: 1670397
URL: http://svn.apache.org/r1670397
Log:
ALPN support, based on mod_spdy/mod_h2 patch set
Modified:
httpd/httpd/trunk/modules/ssl/mod_ssl.c
On 05.02.2015 19:22, Graham Leggett wrote:
What I’ve done is broken the problem into two sections, the first is
to give a unique handle on the certificate that can be used in LDAP
queries. RFC4523 defines a CertificateExactAssertion, which is “{
serialNumber decimal-serial-number-string,
On 07.01.2015 15:17, Plüm, Rüdiger, Vodafone Group wrote:
Why checking for FALSE and !*ids? Shouldn't the empty array cause a
return of FALSE?
Not necessarily. Early returns in SSL_X509_getSAN (when argument
checking etc. is taking place) may return a NULL pointer for the array,
But don't
On 07.01.2015 14:03, Ruediger Pluem wrote:
+/* return an array of (RFC 6125 coined) DNS-IDs and CN-IDs in a certificate
*/
+BOOL SSL_X509_getIDs(apr_pool_t *p, X509 *x509, apr_array_header_t **ids)
+{
+X509_NAME *subj;
+int i = -1;
+
+/* First, the DNS-IDs (dNSName entries in
On 09.11.2014 14:30, Graham Leggett wrote:
On 06 Nov 2014, at 8:05 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
Is there another way to do this?
Manually performing what certificateExactMatch is specifying, I would
say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple
On 12.11.2014 03:28, Dr Stephen Henson wrote:
I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7
years ago...
For 0.9.8, it was fixed with 0.9.8e:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=900f7a87760d1053127976480efcd71371787d6e
I.e., given that
On 06.11.2014 14:19, Dirk-Willem van Gulik wrote:
On 06 Nov 2014, at 14:14, Andreas B. regis...@progandy.de wrote:
Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik:
On 06 Nov 2014, at 07:05, Kaspar Brand httpd-dev.2...@velox.ch
mailto:httpd-dev.2...@velox.ch wrote:
(i.e., we
On 02.11.2014 15:44, Graham Leggett wrote:
Currently the application in this case is mod_authnz_ldap. While it
is possible to build a complex expression to match a series of DNs,
you are limited in knowing the length of the chain in advance, and in
my case that isn’t possible - chains may be
On 05.11.2014 14:26, Graham Leggett wrote:
The problem I am trying to solve is to find a practical way to
integrate an SSL client cert identity with LDAP, in such a way where
I can say “we recognise this certificate is mapped to that
capability”. I am struggling to find an accurate indicator
On 01.11.2014 14:46, Yann Ylavic wrote:
There is still that a client handshaking with a SSLv2Hello (by using
SSLv23_client_method()) is likely to accept SSLv[23] protocols (unless
using SSL_OP_NO_SSLv[23] explicitly like today's mod_ssl, but it's
probably not the case for legacy clients), so
On 01.11.2014 13:41, Graham Leggett wrote:
The trouble with doing that is that it makes life really difficult to
match arbitrary certificate chains - you need to know in advance how
many certs are in each chain, and you need to perform a lot of
messing about to perform a match, and to ensure
On 29.10.2014 16:42, Yann Ylavic wrote:
On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
That would solve our problem, though some may wonder about the subtle
differences between any and all :-) More seriously, it would also make
the config-files incompatible with
On 30.10.2014 15:51, Jeff Trawick wrote:
IMO the present concerns with OCSP Stapling are:
* not so clear that it has seen enough real-world testing; commented out
sample configs and better documentation will help, as will enabling by
default in trunk (just a little?)
* related bugs 57121
On 27.10.2014 12:55, Jeff Trawick wrote:
Putting SSLUseStapling at global scope makes it easier for the admin, who
may have had trouble getting SSL working in the first place.
I don't see yet how it makes it easier - my point is more that an
admin should consciously enable OCSP stapling when he
On 29.10.2014 11:41, Yann Ylavic wrote:
I chose to use (MD5 digest) all the IP:port from the s-addrs list
(ie. VitualHost IP|*|_default_:port ...), plus s-server_hostname
and s-port (ie. ServerName, be it configured or not, knowing that in
the latter case, apr_gethostname() is used fot the
On 29.10.2014 16:40, Graham Leggett wrote:
The attached patch makes the variable SSL_CLIENT_CERT_SUBJECTS
available, which contains a list of subject DNs in each certificate
in the chain. It is designed to be able to match against a full
certificate chain where the subject and issuer of the
On 01.11.2014 11:23, Yann Ylavic wrote:
How about SSLv2Hello keyword (à la JDK), should we agree on a real
issue caused by ALL -SSLv3 (see below)?
This keyword wouldn't fit into the current set of options, so I'm not in
favor of it (the SSL2 compatible hello is like a flag which is
orthogonal
On 23.10.2014 02:59, traw...@apache.org wrote:
Author: trawick
Date: Thu Oct 23 00:59:40 2014
New Revision: 1633730
URL: http://svn.apache.org/r1633730
Log:
add OCSP Stapling configuration, disabled by default
Modified:
httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
On 17.10.2014 12:02, Takashi Sato wrote:
SSLv3 is now insecure (CVE-2014-3566, POODLE)
Let's disable SSLv3 by default, at least trunk.
SSLProtocol default is all.
http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol
all means a shortcut for ``+SSLv3 +TLSv1'' or - when using
On 05.10.2014 13:55, Yann Ylavic wrote:
sk_OPENSSL_STRING_value() is undefined in openssl-0.9.8x, I commited a
follow up in r1629485.
Can you please check this is the right thing to do?
Thanks. It would make more sense to change ssl_private.h, actually - you
can just
Author: jim
Date: Tue Jun 3 13:07:29 2014
New Revision: 1599531
URL: http://svn.apache.org/r1599531
Log:
Optimize w/ duplicated listeners and use of SO_REUSEPORT
where available.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/include/ap_listen.h
On 05.10.2014 02:27, Lu, Yingqi wrote:
Kaspar, can you please test the patch and let us know if that
resolves your issue?
Yes, makes the restart issues disappear for me (only tested with the
worker MPM, and not very extensively). Thanks.
At the meantime, can some please review the patch and
On 19.06.2014 23:17, Joe Orton wrote:
I was reminded that there was a request to use the larger key sizes as
well.
Using ephemeral DH keys with sizes 4096 bits in TLS seems way overkill
for the next decade or so (3072 bits are already considered to have a
128-bit symmetric-key strength), but
On 14.06.2014 12:53, Rainer Jung wrote:
SSL_CTX_set_timeout() seems to work pretty well.
Indeed. I missed the fact that after the ticket has been decrypted/processed,
there's a timeout check in ssl_sess.c:ssl_get_prev_session(), based on the
SSL_SESSION's time value, which is the timestamp of
On 13.06.2014 16:55, Rainer Jung wrote:
Now since a long time most clients do no longer rely on the server
caching the sessions. Instead they use TLS session resumption (RFC
5077).
without server-side state/stateless is actually the important term
from this RFC (session resumption is a
On 02.06.2014 20:49, Ruediger Pluem wrote:
Joe Orton wrote:
On Wed, May 28, 2014 at 10:10:16PM +0200, Ruediger Pluem wrote:
Thanks, but I missed some stuff during review:
1. We don't need to have two DH pointers in make_dh_params
Doh!
2. There possible frees on NULL pointers in
On 27.05.2014 22:33, Ruediger Pluem wrote:
Joe Orton wrote:
We have a potential race here between threads doing the param
generation, right?
+static DH *dh = NULL; \
+DH *dh_tmp; \
...
+dh = dh_tmp; \
though it would not matter who wins the race *if* we could rely on
On 19.05.2014 10:15, Plüm, Rüdiger, Vodafone Group wrote:
Maybe stupid idea, but can't we do that once and hand it out over
and over again?
Not a stupid idea at all - I think it's actually the most sensible
solution to this problem. This is what OpenSSL does with the
DH parameters provided by
On 19.05.2014 16:58, Graham Leggett wrote:
In httpd v2.4's mod_ssl I can access the various components of the
subject and the issuer DN using SSL_CLIENT_S_DN_x509 and
SSL_CLIENT_I_DN_x509.
Is there a corresponding set of variables that can pull the same
information out of the
On 23.02.2014 09:03, Kaspar Brand wrote:
Yes, that's the underlying issue which changing cmd-server to NULL in
the ap_log_error actually uncovers: it's a somewhat (at least IMO)
unfortunate side effect of how the LogLevel for a new VirtualHost is
inherited/merged from the global LogLevel
On 16.04.2014 10:17, Kaspar Brand wrote:
There's another backwards-compatibility fix I consider necessary for
2.4.x (see https://issues.apache.org/bugzilla/show_bug.cgi?id=56306#c8),
so I think I'll wait a few days for feedback on that one before
combining them into a single proposal for 2.4.x
On 22.04.2014 12:55, Yann Ylavic wrote:
On Mon, Apr 21, 2014 at 8:39 AM, kbr...@apache.org wrote:
+#ifdef SSL_CERT_SET_SERVER
+/*
+ * When multiple certs/keys are configured for the SSL_CTX: make sure
+ * that we get the private key which is indeed used for the current
+ *
On 22.04.2014 14:57, Ligade, Shailesh [USA] wrote:
I think by default, the certificate hint list asks for client
authentication certificates. Is there any configuration option to ask
for different types of certificates? e.g. signing or encryption
certificates?
This would be a question for
On 19.04.2014 09:37, Falco Schwarz wrote:
I successfully tested your attached patch with the latest 1.0.2
branch. The DH temp key now has the bit length of the used RSA key,
regardless of SSLCertificate[Key]File order.
Thanks for testing. Committed to trunk with r1588851 and proposed for
On 05.02.2014 14:05, Kaspar Brand wrote:
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
On 15.04.2014 17:25, traw...@apache.org wrote:
Author: trawick
Date: Tue Apr 15 15:25:03 2014
New Revision: 1587607
URL: http://svn.apache.org/r1587607
Log:
mod_ssl: Add hooks to allow other modules to perform processing at
several stages of initialization and connection handling. See
On 18.04.2014 23:19, Falco Schwarz wrote:
On Fri, Apr 18, 2014 at 4:04 PM, Daniel Kahn Gillmor
d...@fifthhorseman.netwrote:
Looking at the code, it appears that ssl_callback_TmpDH() in
modules/ssl/ssl_engine_kernel.c doesn't try to match ECC keys at all --
this probably needs to be updated.
On 19.04.2014 09:00, Falco Schwarz wrote:
that OpenSSL actually returns the private key used by the connection.
I just noticed [1], so you might want to try the attached (but untested)
patch with 1.0.2-beta1 at least (beware of CVE-2014-0160 though, later
versions preferred).
Kaspar
[1]
On 18.04.2014 11:11, Yann Ylavic wrote:
Agreed, still it may be useful (for some potential client) to get the
real error when it handshakes with an SNI which is not acceptable on
this server, and for the server the sooner the better IMHO.
mod_ssl will send a Certificate TLS message either way
Sorry for being late with my reply.
On 16.04.2014 16:00, Yann Ylavic wrote:
Before this commit, the client knew it was not reaching any vhost by
receiving an SSL alert (warning), and could stop.
In practice, most SNI-capable clients have ignored these warning-level
alerts (which is completely
On 14.04.2014 10:47, Jan Kaluža wrote:
On 04/12/2014 12:37 PM, Kaspar Brand wrote:
We can partly restore the argument structure for exec-type programs,
but effectively, lifting the limit of 2 (or 3) certs per SSL host means
that there's no longer a reliable way of determining if we
On 16.04.2014 09:45, Jan Kaluža wrote:
On 04/16/2014 09:35 AM, Plüm, Rüdiger, Vodafone Group wrote:
Are we sure that ppcb_arg-key_id always contains a ':'?
I've checked that part of patch and if I'm right, the key_id is only
created by asn1_table_vhost_key(...) like this:
char *key =
On 12.04.2014 12:41, Kaspar Brand wrote:
The Expecting: DH PARAMETERS error is probably a red herring - it's
most likely a leftover in the OpenSSL error stack after the
configuration of another certificate (we try to load DH parameters at
the end of ssl_init_server_certs, which in turn
[picking this up from the comment in Re: svn commit: r1585902 - ...]
On 09.04.2014 21:56, Jeff Trawick wrote:
IMO this needs to be reworked to restore compatibility for 2.x up
through 2.4.7, with the new interface used if some new keyword is
added on the directive. Yeah, some people who
On 11.04.2014 14:27, Jeff Trawick wrote:
Is it just this and the SSLPassPhraseDialog exec command-line parameter
change? I dunno.
-- Forwarded message --
From: Jesse Defer jesse.de...@asu.edu
Date: Thu, Apr 10, 2014 at 4:34 PM
Subject: [users@httpd] 2.4.9 expecting DH
On 04.04.2014 12:22, Jan Kaluža wrote:
commit 1553824 (1573360 in 2.4.x) breaks the compatibility in arguments
passed to exec:/path/to/program pass phrase program. This should be
clear from the following part of mentioned commit(s):
-argv[1] = cpVHostID;
-argv[2] =
On 30.03.2014 21:25, yla...@apache.org wrote:
Author: ylavic
Date: Sun Mar 30 19:25:20 2014
New Revision: 1583191
URL: http://svn.apache.org/r1583191
Log:
mod_ssl: send OCSP request's nonce according to SSLOCSPUseRequestNonce
on/off. PR 56233.
@@ -171,7 +174,8 @@ static int
On 27.03.2014 20:44, Ruediger Pluem wrote:
Daniel Kahn Gillmor wrote:
Do we have a robust, free tool that, given a single X.509 EE cert, can do
automagic fetching and trying of all
combinations of these things and produce a reasonable PEM-encoded
SSLCertificateChainFile on stdout?
On 13.03.2014 17:49, Jim Jagielski wrote:
I'm calling a VOTE on releasing these as Apache httpd 2.4.9 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
+1. Perl framework tests run with mod_ssl compiled against OpenSSL
0.9.8y, 1.0.0k, 1.0.1c, 1.0.1e, 1.0.1f and
On 19.02.2014 14:08, Jim Jagielski wrote:
I'd like to shoot for a TR sometime next week...
On Feb 4, 2014, at 8:58 AM, Jim Jagielski j...@jagunet.com wrote:
I'd like to TR and release 2.4.8 this month... Let's all take
some time to:
1. See what in trunk should really be backported
2.
On 22.02.2014 19:17, Falco Schwarz wrote:
Kaspar, I switched back to your version and realized, that the directive
SSLCertificateChainFile was always used in a VirtualHost.
If the directive is in server scope, the warning is written correctly.
On 22.02.2014 18:56, William A. Rowe Jr. wrote:
Understood and this would explain assigning them to MOD_SSL_LIBS etc. But
added to MOD_LIBS? That struck me as very odd.
Putting a module prefix into the variable name would make assembling the
commands in build/rules.mk more complex, and it
On 20.02.2014 21:37, Falco Schwarz wrote:
As I read through the changed code I found a smaller issue with the
deprecation warning of SSLCertificateChainFile:
+ ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, cmd-server,
+ APLOGNO(02559)
+ The SSLCertificateChainFile directive
On 22.02.2014 11:06, Falco Schwarz wrote:
Perhaps I am missing something here, but if it is printed to stderr I should
see it in the console when starting, right? Because I am unable to see it
anywhere.
Even when reloading or restarting it is not written to the error log.
It does not show
On 22.02.2014 11:27, Falco Schwarz wrote:
Yes, for testing I am currently using these directives (without comment):
SSLCertificateFile conf/ssl/foo.bar.cer# leaf only
SSLCertificateKeyFile conf/ssl/foo.bar.key# key only
SSLCertificateChainFile conf/ssl/foo.bar.ca # chain
On 18.02.2014 15:53, Pavel Matěja wrote:
Hi,
since we've enabled SSLProxyCheckPeerName our reverserse proxy I can see
AH00052: child pid 5711 exit signal Segmentation fault (11)
in our logs during Nessus scans.
Backend server has several X509v3 Subject Alternative Names and Nessus sends
On 20.02.2014 04:18, William A. Rowe Jr. wrote:
Can anyone offer background as to why httpd 2.4 branch ./configure likes
checking for OpenSSL... checking for user-provided OpenSSL base
directory... /usr/local/ssl adding -I/usr/local/ssl/include to
CPPFLAGS setting MOD_CFLAGS to
1 - 100 of 308 matches
Mail list logo