Re: Have you submitted the modified Edelkey patch to httpd-dev

development version of openssl is required. The patch also removes problem introduces by some 'const'ifying og SSL_method. http://www.edelweb.fr/EdelKey/files/apache-2.2.0+0.9.9+servername.patch have fun Peter Sylvester Yusuf Goolamabbas wrote: Kaspar, Thanks for your response. Peter.

smal mod to mod_ssl

server */ ctx = SSL_CTX_new(method); /* be more flexible */ } -- Since method is only used in the two cases before I think it is better to use the expressions as a parameter to SSL_CTX_new and not declare "method". Thanks for consideration. Peter Sylvester smime.p7s Des

Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

Hi: On 11/26/2013 06:18 PM, Kaspar Brand wrote: 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 spec

Re: [SPAM?]: Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

On 12/12/2013 12:20 AM, William A. Rowe Jr. wrote: On Tue, 26 Nov 2013 18:47:39 +0100 Peter Sylvester wrote: Hi: On 11/26/2013 06:18 PM, Kaspar Brand wrote: 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

Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

On 12/12/2013 12:15 AM, William A. Rowe Jr. wrote: On Tue, 26 Nov 2013 09:47:44 +0100 Yann Ylavic wrote: On Tue, Nov 26, 2013 at 9:29 AM, Yann Ylavic wrote: On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand wrote: On 26.11.2013 00:46, Yann Ylavic wrote: Ideas for the appropriate patch to htt

Re: [SPAM?]: RE: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

On 12/12/2013 10:28 AM, Plüm, Rüdiger, Vodafone Group wrote: -Original Message- From: Kaspar Brand [mailto:httpd-dev.2...@velox.ch] Sent: Donnerstag, 12. Dezember 2013 07:01 To: dev@httpd.apache.org Subject: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests On 12.12.2013

bug in modssl

Hello, I have just reported a bug in modssl which was already reported earlier here in more details. https://issues.apache.org/bugzilla/show_bug.cgi?id=45107 Thanks in advance for considering the proposed patch. Peter Sylvester smime.p7s Description: S/MIME Cryptographic Signature

Re: TLS/SNI status

ame alert has to be sent, this by default is a warning; it becomes fatal with the '-servername_fatal' option. [Peter Sylvester, Remy Allais, Christophe Renou]

Re: TLS/SNI status

Gervase Markham wrote: Peter Sylvester wrote: As most of you will know, supporting it in Apache requires changes to OpenSSL (which we funded, and which went into version 0.9.8f) and to the httpd itself. I am certainly not one of those "most". I apologise for the am

Re: [VOTE] httpd 2.2.12 tarballs

Are there any plans to make mod_ssl compilable against openssl-1.0.0betaX, as far as I see, just some STACK things and casts need to be cleaned. /PS

Re: svn commit: r798359 - in /httpd/httpd/branches/2.2.x: modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.c support/ab.c

William A. Rowe, Jr. wrote: Paul Querna wrote: -1 veto, please revert this commit. Unless I missed something, these changes were not voted on in the STATUS file. I think wrowe's endorsement was... badly worded. wrowe's endorsement was fine, and one of three votes required to override

Re: svn commit: r798359 - in /httpd/httpd/branches/2.2.x: modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.c support/ab.c

I looked at the patch in question and it seems reasonable to me. That should work fine on much older versions of OpenSSL it's just that now some things are enforced that weren't before. A little nit in ssl_engine_init.c: instead of -SSL_CTX_set_client_CA_list(ctx, (STACK *)ca_list);

Re: svn commit: r798359 - in /httpd/httpd/branches/2.2.x: modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.c support/ab.c

Instead it is another cleanup which should go the usual way = apply in HEAD, propose for backport. Please lets separate these things - the bigger we make the one 2.2.x backport patch the lesser the other developers are in the mood to review it. I agree.

Re: svn commit: r798359 - in /httpd/httpd/branches/2.2.x: modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.c support/ab.c

Dr Stephen Henson wrote: Peter Sylvester wrote: There is some non-portable code round there that accesses extensions in a most convoluted fashion for some unknown reason. the stuff in ..vars.c ssl_ext_list? Well that too but was mainly thinking of the extension

Re: [us...@httpd] Trouble compiling apache with mod_ssl, having two versions of OpenSSL on openSUSE 10.3

Dan Stromberg wrote: It seems that building Apache 2.2.12 from source against OpenSSL 1.0.0 beta 3 (also built from source) on an openSUSE 10.3 system that has rpm's of older Apache and OpenSSL, yields a build failure - maybe because of the dual OpenSSL, maybe not. Is this a known issue? Is the

backport of 630858

Hi, can someone make a backport of 630858 * modules/ssl/ssl_engine_init.c (ssl_init_FindCAList): Cast return value of sk_X509_NAME_set_cmp_func to void, to avoid warnings with recent version of OpenSSL. --- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c 2008/02/22 11:36:51 630163 +++

backport request for patch 787683

Someone mind to backport this to 2.2.x ? thanks /P *787683* --- httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c 2009/05/27 05:41:07 779005 +++ httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c 2009/06/23 14:10:06 787683 @@

Re: Certificate chain order not conform to TLS standard

Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Nick Gearls [mailto:nickgea...@gmail.com] Sent: Donnerstag, 13. August 2009 08:51 To: dev@httpd.apache.org Subject: Re: Certificate chain order not conform to TLS standard I tried both order: SSLCertificateFile

Re: Certificate chain order not conform to TLS standard

Right, but as far as I remember there are some picky SSL clients that puke if it is present. I am not saying that the behaviour of these clients is correct. Thus I said don't put it in :-) ok. something that could be said in a FAQ?

backport and enhancement of patch 724717

n addition it concentrates logic at one place ... ... almost. Wouldn't it be better to move the for loop in the following snippet of ssl_engine_kernel (and the ssl_hoolFixup_vars table also inside the the routine above (changing maybe its name). Thanks in advance for comments. Peter Sylveste

[Fwd: backport and enhancement of patch 724717]

;t it be better to move the for loop in the following snippet of ssl_engine_kernel (and the ssl_hoolFixup_vars table also inside the the routine above (changing maybe its name). Thanks in advance for comments. Peter Sylvester /* standard SSL environment variables */ if (dc->nOptions &a

Re: [Fwd: backport and enhancement of patch 724717]

Graham Leggett wrote: Peter Sylvester wrote: I am not whether I have missed a response. I think backporting this patch is not critical and helps to remove differences between the mod_ssl versions. Can you confirm the URL of whre the patch lives? I assumed 724717 was a bugzilla number

Re: [Fwd: backport and enhancement of patch 724717]

Joe Orton wrote: On Wed, Sep 09, 2009 at 10:22:28PM +0200, Peter Sylvester wrote: The patch for 724717 moves some logic from ssl_engine_kernel into ssl__engine_vars and simplifies the code (and enhances it btw). Can this code be backported to the 2.2.x version Have you done any

Re: [Fwd: backport and enhancement of patch 724717]

Following a remark from Guenter, it seems that the patch 724717 removed some variables. Only the details of the DNs are handled by the new function but not the complet DNs The enclosed patch should correct this I hope by adding the four variables back. regards and have fun Peter Sylvester

Re: Strange error(parse tlsext bug) in mod_ssl since httpd-2.2.12

Kaspar Brand wrote: Joe Orton wrote: the OpenSSL client (SNI extensions should never contain literal IPv4 addresses). Good point - I've changed neon for future releases to only enable SNI if the hostname is not a numeric IP address. This logic should go into OpenSSL, I think...

Re: any reason for ssl_engine_kernel.c to use ap_log_error() when r and/or c are known?

On 11/01/2010 11:53 AM, Joe Orton wrote: Generally "no reason, no", there are lots of places in mod_ssl where _cerror should be used but the code predates the existence of _cerror; it's possible the SNI-related use of ap_log_error() in ssl_hook_ReadReq() is deliberate, however, I'm guessing. Reg

Re: [users@httpd] SNI with apache 2.4.1 reverse proxy

On 04/16/2012 12:45 PM, Michael Weiser wrote: that makes mod_ssl put the content of the host header into the sni data structures instead of the hostname from the URL used in the ProxyPass(Reverse) configuration itself. This way even name-based virtual hosts should work behind the reverse proxy.