Re: [users@httpd] SNI with apache 2.4.1 reverse proxy
Hi, On Tue, Apr 10, 2012 at 10:01:11AM +0200, Michael Weiser wrote: A solution might be something like: ProxyPass / https://www.example.com:12443/ no-sni ProxyPassReverse / https://www.example.com:12443/ no-sni , disabling SNI towards the backend server. Or can I tell the 2.2.14 apache inside the VM to ignore the SNI data it sees in the requests? The best solution I can think of would be some switch like ProxyPass / https://www.example.com:12443/ pass-host-as-sni ProxyPassReverse / https://www.example.com:12443/ pass-host-as-sni 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. I haven't heard anything back: What's the general opinion on this? -- bye, Micha
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. I haven't heard anything back: What's the general opinion on this? 2 pfennige: - If a configuration parameter can be avoided, this divides the possibilities of errors by at least 3. I don't think that a configuration parameter is necessary. - If something is put into the SNI, it must be identical to what is in the Host:header. /PS
Re: svn commit: r1325632 - /httpd/httpd/trunk/config.layout
- Original Message -
Author: igalic
Date: Fri Apr 13 07:21:46 2012
New Revision: 1325632
URL: http://svn.apache.org/viewvc?rev=1325632view=rev
Log:
Introduce Slackware layout.
patch: Frank Gingras
Modified:
httpd/httpd/trunk/config.layout
Can I Back-port this for our packager's convenience?
Or does it require a vote?
i
Modified: httpd/httpd/trunk/config.layout
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/config.layout?rev=1325632r1=1325631r2=1325632view=diff
==
--- httpd/httpd/trunk/config.layout (original)
+++ httpd/httpd/trunk/config.layout Fri Apr 13 07:21:46 2012
@@ -347,3 +347,26 @@
proxycachedir: ${localstatedir}/proxy
/Layout
+# FHS layout
+Layout Slackware-FHS
+prefix: /usr
+exec_prefix: ${prefix}
+bindir: ${prefix}/bin
+sbindir: ${prefix}/sbin
+libdir: ${prefix}/lib/httpd
+libexecdir: ${prefix}/lib/httpd/modules
+installbuilddir: ${prefix}/lib/httpd/build
+mandir: ${prefix}/man
+sysconfdir: /etc/httpd
+datadir: /srv/httpd
+iconsdir:${datadir}/icons
+htdocsdir: ${datadir}/htdocs
+manualdir: ${htdocsdir}/manual
+cgidir: ${datadir}/cgi-bin
+errordir:${datadir}/error
+includedir: ${prefix}/include/httpd
+localstatedir: /var
+runtimedir: ${localstatedir}/run/httpd
+logfiledir: ${localstatedir}/log/httpd
+proxycachedir: ${localstatedir}/cache/httpd
+/Layout
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: A bug with httpd-2.4.2 Win-x64
Hi Bing, you did hit the apr list - I think this should go to the httpd list instead ... ;-) Am 16.04.2012 14:32, schrieb Bing Swen: After building the httpd-2.4.2 x64 binaries with VS2010, I encountered a runtime error in the module libhttpd.dll, which alerts that a heap corruption occurred at somewhere: file D:\_bsDev\KSE\httpd-2.4.2\server\config.c line 680: free(ap_module_short_names[m-module_index]); The free() call always led to heap corruption like this: HeapFree(_crtheap, 0, pBlock); // access error with pBlock == NULL. My temp solution is commenting off this single line to get httpd.exe run. Please verify if it is a bug. Regards, Bing
Re: [VOTE] Release Apache httpd 2.4.2 as GA
- Original Message - This is NOT the list for starting OS wars on. Could you please point me to the correct list for that kind of thing? (: i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [RESULT] Re: [VOTE] Release Apache httpd 2.4.2 as GA
+1 - Original Message - With 3+ +1 (binding) votes and no -1s, I call the vote CLOSED and PASSED. Thx to all testers! On Apr 5, 2012, at 8:24 AM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.2 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.2 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. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: CHANGES-FCGID is incorrect
On Tue, Apr 10, 2012 at 12:35 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 4/9/2012 11:30 PM, William A. Rowe Jr. wrote: The patch does have value to a limited number of applications. I even went as far as to put caviats in the docs, and a see-docs note to the directive cmd commentary. I hope it dissuades the casual user from throwing it on there unless they know it won't corrupt their app and know it solves their bug. Please reconsider your veto. I agree that it -should not- occur in any real world scenario. But there are unreal scenarios of server configs and third party modules which spend minutes, not seconds, tearing down on shutdown. Those are the bugs. But users just want some help and I think this patch is some help in rare cases. Disabled by default and won't be used by much of anyone, we hope. I'll revert (yet again) if you really want to make a case that we should never support this, even as a workaround. Gregg, and Jeff and company, if this is reviewed and everyone is happy with an end result, I'd like to ensure 2.4.2 compatibility and get tagging. If you're out of bandwidth I can handle the TRNag today or tomorrow, after doing some testing of 2.3.7-dev with httpd 2.4.3-dev (and double checking with 2.0 and 2.2). We seem well overdue for a release. There is a group of issues with spaces in command lines, spaces in file names that need to be resolved for the typical windows scenario (and obviously also unix, just more unusual there). I think we are best off calling 2.3.7 about baked right now, tagging, reviewing and releasing, and calling 2.3.next the flavor which fixes these command/file string argument quirks. -- Born in Roswell... married an alien...
Re: [VOTE] Release Apache httpd 2.4.2 as GA
On 4/16/2012 8:10 AM, Igor Galić wrote: - Original Message - This is NOT the list for starting OS wars on. Could you please point me to the correct list for that kind of thing? (: http://en.wikipedia.org/wiki/Talk%3AOperating_system_advocacy That's been asked before ;-P
Re: CHANGES-FCGID is incorrect
On 4/16/2012 8:16 AM, Jeff Trawick wrote: On Tue, Apr 10, 2012 at 12:35 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 4/9/2012 11:30 PM, William A. Rowe Jr. wrote: The patch does have value to a limited number of applications. I even went as far as to put caviats in the docs, and a see-docs note to the directive cmd commentary. I hope it dissuades the casual user from throwing it on there unless they know it won't corrupt their app and know it solves their bug. Please reconsider your veto. I agree that it -should not- occur in any real world scenario. But there are unreal scenarios of server configs and third party modules which spend minutes, not seconds, tearing down on shutdown. Those are the bugs. But users just want some help and I think this patch is some help in rare cases. Disabled by default and won't be used by much of anyone, we hope. I'll revert (yet again) if you really want to make a case that we should never support this, even as a workaround. Gregg, and Jeff and company, if this is reviewed and everyone is happy with an end result, I'd like to ensure 2.4.2 compatibility and get tagging. If you're out of bandwidth I can handle the TRNag today or tomorrow, after doing some testing of 2.3.7-dev with httpd 2.4.3-dev (and double checking with 2.0 and 2.2). I got to the same point... needing to look at this against 2.4.3-dev tree. If you are happy, please don't hesitate to TR! Not sure if I could beat you to a tag, but for sure I'll make several hours for testing and voting here this week. [I've had most of trunk/ in test for some time now.]
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy
Hi there, On Mon, Apr 16, 2012 at 01:45:16PM +0200, Peter Sylvester 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. I haven't heard anything back: What's the general opinion on this? - If a configuration parameter can be avoided, this divides the possibilities of errors by at least 3. I don't think that a configuration parameter is necessary. I agree (or at least don't care as long as I get the behaviour I need ;). - If something is put into the SNI, it must be identical to what is in the Host:header. This could be a side-effect of ProxyPreserveHost On since only with ProxyPreserveHost On does it make any sense anyways. With ProxyPreserveHost Off, the SNI data should contain the hostname from the ProxyPassReverse directive. 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 ssl_engine_io.c. ssl_engine_io.c already uses an apr_table_get with a name of proxy-request-hostname which is apr_table_set'd in mod_proxy_http.c. So point 2 seems to be taken care of already. Host header preservation seems to be done done in mod_proxy_http.c as well. Now setting proxy-request-hostname based on that shouldn't be too hard. Shall I have a go at that? -- bye, Michael Elephants don't play chess!
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy
On Mon, Apr 16, 2012 at 3:47 PM, Michael Weiser mich...@weiser.dinsnail.net wrote: Hi there, On Mon, Apr 16, 2012 at 01:45:16PM +0200, Peter Sylvester 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. I haven't heard anything back: What's the general opinion on this? - If a configuration parameter can be avoided, this divides the possibilities of errors by at least 3. I don't think that a configuration parameter is necessary. I agree (or at least don't care as long as I get the behaviour I need ;). - If something is put into the SNI, it must be identical to what is in the Host:header. This could be a side-effect of ProxyPreserveHost On since only with ProxyPreserveHost On does it make any sense anyways. With ProxyPreserveHost Off, the SNI data should contain the hostname from the ProxyPassReverse directive. Er, surely you mean ProxyPass directive here. The ProxyPassReverse directive is only used for rewriting response headers, it has nothing to do with altering the proxied request. Cheers Tom
Why aren't name-based vhosts not working properly under SSL?
If the SSL-certificate is the same for all named vhosts configured for the given IP-address/port-number combination, why can not the vhosts have different DocumentRoots and other settings? Thank you. Yours, -mi
Re: Why aren't name-based vhosts not working properly under SSL?
Am 16.04.2012 17:34, schrieb Mikhail T.: If the SSL-certificate is the same for all named vhosts configured for the given IP-address/port-number combination, why can not the vhosts have different DocumentRoots and other settings? because SSL was misdesigned years ago and the Host-Header is also sent encrypted, so the server can not know for with hostname the ssl-handshake is and since he knows the Hostname AFTER handshake it is too late signature.asc Description: OpenPGP digital signature
Re: Why aren't name-based vhosts not working properly under SSL?
On Mon, Apr 16, 2012 at 4:34 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: If the SSL-certificate is the same for all named vhosts configured for the given IP-address/port-number combination, why can not the vhosts have different DocumentRoots and other settings? Thank you. Yours, -mi They can. Excerpt from my httpd.conf: NameVirtualHost *:443 VirtualHost *:443 ServerName rc.xx.com SSLEngine on SSLCertificateFile /etc/ssl/star.xx.com/apache.crt /VirtualHost VirtualHost *:443 ServerName sab.xx.com SSLEngine on SSLCertificateFile /etc/ssl/star.xx.com/apache.crt /VirtualHost VirtualHost *:443 ServerName svn.xx.com SSLEngine on SSLCertificateFile /etc/ssl/star.xx.com/apache.crt /VirtualHost Cheers Tom
Re: Why aren't name-based vhosts not working properly under SSL?
On 16.04.2012 11:40, Tom Evans wrote: They can. Excerpt from my httpd.conf: Your excerpt does not show different DocumentRoots -- nor any other settings... Could you show more contents? What is the Apache version you are using? In all my attempts, Apache a) issues a pointless warning about multiple SSL vhosts on the same IP/port; b) uses the settings (including DocumentRoot) from the first vhost encountered for all of them. On 16.04.2012 11:39, Reindl Harald wrote: because SSL was misdesigned years ago and the Host-Header is also sent encrypted, so the server can not know for with hostname the ssl-handshake is and since he knows the Hostname AFTER handshake it is too late No, this does not answer my question. In my scenario the SSL-certificate is the same for all vhosts concerned. So Apache could use that certificate to establish the SSL connection, and then parse the Host:-header to determine, which group of other (non-SSL) settings to apply to the request. But Apache does not do that -- not in 2.2.22. Is this an omission, that can and should be fixed, or am I missing something else? Thanks! -mi
Re: Why aren't name-based vhosts not working properly under SSL?
No, this does not answer my question. In my scenario the SSL-certificate is the same for all vhosts concerned. So Apache could use that certificate to establish the SSL connection, and then parse the Host:-header to determine, which group of other (non-SSL) settings to apply to the request. But Apache does not do that -- not in 2.2.22. Is this an omission, that can and should be fixed, or am I missing something else? Thanks! Got a pointer to your configuration?
Re: Why aren't name-based vhosts not working properly under SSL?
On 16.04.2012 11:55, Eric Covener wrote: Got a pointer to your configuration? Well, the real one I was designing now uses a work-around (single vhost with mod_rewrite examining the Host-header and picking the proper subdirectore). Here is a mock one, that I'd rather be using -- instead of messing with mod_rewrite: Listen: 443 # Common settings for all: SSLCertificateFile conf/ssl.crt/everywhere.cer SSLCertificateKeyFile conf/ssl.key/everywhere.key SSLCertificateChainFile conf/ssl.crt/Comodo-intermediate.cer VirtualHost *:443 ServerNamedrupal6 ServerAlias project1.example.com ServerAlias project2.example.net DocumentRoot /www/drupal6 /VirtualHost VirtualHost *:443 ServerNamedrupal7 ServerAlias project3.example.com ServerAlias project4.example.net DocumentRoot /www/drupal7 /VirtualHost Older projects 1 and 2 use Drupal-6, while the new projects 3 and 4 -- Drupal-7. Yours, -mi
Re: Why aren't name-based vhosts not working properly under SSL?
On Mon, Apr 16, 2012 at 4:51 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
On 16.04.2012 11:40, Tom Evans wrote:
They can. Excerpt from my httpd.conf:
Your excerpt does not show different DocumentRoots -- nor any other
settings... Could you show more contents? What is the Apache version you are
using? In all my attempts, Apache a) issues a pointless warning about
multiple SSL vhosts on the same IP/port; b) uses the settings (including
DocumentRoot) from the first vhost encountered for all of them.
Er, OK:
NameVirtualHost *:80
NameVirtualHost *:443
VirtualHost *:443
ServerName rc.xx.com
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/xx/star.xx.com/apache.crt
SSLCertificateKeyFile /etc/ssl/xx/star.xx.com/apache.key
SSLCACertificateFile /etc/ssl/xx/ca.crt
ErrorDocument 403 /errors/certneeded.html
Alias /errors /usr/local/etc/apache22/xxerrors
SSLVerifyClient optional
LocationMatch ^(?!/errors/)
SSLRequire %{SSL_CLIENT_VERIFY} eq SUCCESS
SSLVerifyClient optional
/LocationMatch
SSLVerifyDepth 1
SSLCARevocationFile /etc/ssl/xx/ca.crl
SSLOptions +StdEnvVars
SSLUserName SSL_CLIENT_S_DN_Email
RequestHeader set X-SSL-Enabled 1
DocumentRoot /usr/home/tom/projects/rc/htdocs
Directory /usr/home/tom/projects/rc/htdocs
Order allow,deny
Allow from all
/Directory
#CustomLog /var/log/httpd-ssl-rc.log %t %h %{SSL_PROTOCOL}x
%{SSL_CIPHER}x \%r\ %b
SetEnv proxy-nokeepalive 1
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/media
RewriteCond %{REQUEST_URI} !^/amedia
RewriteCond %{REQUEST_URI} !^/errors
RewriteRule ^/(.*)$ /rc.fcgi/$1 [QSA,L]
FastCGIExternalServer /usr/home/tom/projects/rc/htdocs/rc.fcgi
-socket /usr/home/tom/projects/rc/run/rc.socket
/VirtualHost
VirtualHost *:443
ServerName sab.xx.com
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/xx/star.xx.com/apache.crt
SSLCertificateKeyFile /etc/ssl/xx/star.xx.com/apache.key
SSLCACertificateFile /etc/ssl/xx/ca.crt
SSLVerifyClient optional
ErrorDocument 403 /errors/certneeded.html
Alias /errors /usr/local/etc/apache22/xxerrors
LocationMatch ^(?!/errors/)
SSLRequire %{SSL_CLIENT_VERIFY} eq SUCCESS
SSLVerifyClient optional
/LocationMatch
SSLVerifyDepth 1
SSLCARevocationFile /etc/ssl/xx/ca.crl
SSLUserName SSL_CLIENT_S_DN_Email
SSLOptions +StdEnvVars
RequestHeader set X-SSL-Enabled 1
DocumentRoot /var/empty
Directory /var/empty
Order allow,deny
Allow from all
/Directory
ProxyPass /errors !
ProxyPass / http://ethan.xx.com:8085/sabnzbd/ retry=0
ProxyPassReverse / http://ethan.xx.com:8085/sabnzbd/
SetEnv proxy-nokeepalive 1
/VirtualHost
VirtualHost *:443
ServerName svn.xx.com
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/xx/star.xx.com/apache.crt
SSLCertificateKeyFile /etc/ssl/xx/star.xx.com/apache.key
SSLCACertificateFile /etc/ssl/xx/ca.crt
SSLVerifyClient optional
ErrorDocument 403 /errors/certneeded.html
Alias /errors /usr/local/etc/apache22/xxerrors
Location /
DAV svn
SVNPath /tank/svn/repos/devel
/Location
LocationMatch ^(?!/errors/)
SSLRequire %{SSL_CLIENT_VERIFY} eq SUCCESS
SSLVerifyClient optional
/LocationMatch
SSLVerifyDepth 1
SSLCARevocationFile /etc/ssl/xx/ca.crl
SSLUserName SSL_CLIENT_S_DN_Email
/VirtualHost
This is httpd 2.2.21 btw
Cheers
Tom
RE: Why aren't name-based vhosts not working properly under SSL?
Without a NameVirtualHost directive this cannot work as you intend. Add NameVirtualHost *:433 Regards Rüdiger From: Mikhail T. [mailto:mi+t...@aldan.algebra.com] Sent: Montag, 16. April 2012 18:07 To: dev@httpd.apache.org; cove...@gmail.com Subject: Re: Why aren't name-based vhosts not working properly under SSL? On 16.04.2012 11:55, Eric Covener wrote: Got a pointer to your configuration? Well, the real one I was designing now uses a work-around (single vhost with mod_rewrite examining the Host-header and picking the proper subdirectore). Here is a mock one, that I'd rather be using -- instead of messing with mod_rewrite: Listen: 443 # Common settings for all: SSLCertificateFile conf/ssl.crt/everywhere.cer SSLCertificateKeyFile conf/ssl.key/everywhere.key SSLCertificateChainFile conf/ssl.crt/Comodo-intermediate.cer VirtualHost *:443 ServerNamedrupal6 ServerAlias project1.example.com ServerAlias project2.example.net DocumentRoot /www/drupal6 /VirtualHost VirtualHost *:443 ServerNamedrupal7 ServerAlias project3.example.com ServerAlias project4.example.net DocumentRoot /www/drupal7 /VirtualHost Older projects 1 and 2 use Drupal-6, while the new projects 3 and 4 -- Drupal-7. Yours, -mi
Re: Why aren't name-based vhosts not working properly under SSL?
Are you sure that your client supports SNI?
On 16/04/2012 19:21, Tom Evans wrote:
On Mon, Apr 16, 2012 at 4:51 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
On 16.04.2012 11:40, Tom Evans wrote:
They can. Excerpt from my httpd.conf:
Your excerpt does not show different DocumentRoots -- nor any other
settings... Could you show more contents? What is the Apache version you are
using? In all my attempts, Apache a) issues a pointless warning about
multiple SSL vhosts on the same IP/port; b) uses the settings (including
DocumentRoot) from the first vhost encountered for all of them.
Er, OK:
NameVirtualHost *:80
NameVirtualHost *:443
VirtualHost *:443
ServerName rc.xx.com
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/xx/star.xx.com/apache.crt
SSLCertificateKeyFile /etc/ssl/xx/star.xx.com/apache.key
SSLCACertificateFile /etc/ssl/xx/ca.crt
ErrorDocument 403 /errors/certneeded.html
Alias /errors /usr/local/etc/apache22/xxerrors
SSLVerifyClient optional
LocationMatch ^(?!/errors/)
SSLRequire %{SSL_CLIENT_VERIFY} eq SUCCESS
SSLVerifyClient optional
/LocationMatch
SSLVerifyDepth 1
SSLCARevocationFile /etc/ssl/xx/ca.crl
SSLOptions +StdEnvVars
SSLUserName SSL_CLIENT_S_DN_Email
RequestHeader set X-SSL-Enabled 1
DocumentRoot /usr/home/tom/projects/rc/htdocs
Directory /usr/home/tom/projects/rc/htdocs
Order allow,deny
Allow from all
/Directory
#CustomLog /var/log/httpd-ssl-rc.log %t %h %{SSL_PROTOCOL}x
%{SSL_CIPHER}x \%r\ %b
SetEnv proxy-nokeepalive 1
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/media
RewriteCond %{REQUEST_URI} !^/amedia
RewriteCond %{REQUEST_URI} !^/errors
RewriteRule ^/(.*)$ /rc.fcgi/$1 [QSA,L]
FastCGIExternalServer /usr/home/tom/projects/rc/htdocs/rc.fcgi
-socket /usr/home/tom/projects/rc/run/rc.socket
/VirtualHost
VirtualHost *:443
ServerName sab.xx.com
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/xx/star.xx.com/apache.crt
SSLCertificateKeyFile /etc/ssl/xx/star.xx.com/apache.key
SSLCACertificateFile /etc/ssl/xx/ca.crt
SSLVerifyClient optional
ErrorDocument 403 /errors/certneeded.html
Alias /errors /usr/local/etc/apache22/xxerrors
LocationMatch ^(?!/errors/)
SSLRequire %{SSL_CLIENT_VERIFY} eq SUCCESS
SSLVerifyClient optional
/LocationMatch
SSLVerifyDepth 1
SSLCARevocationFile /etc/ssl/xx/ca.crl
SSLUserName SSL_CLIENT_S_DN_Email
SSLOptions +StdEnvVars
RequestHeader set X-SSL-Enabled 1
DocumentRoot /var/empty
Directory /var/empty
Order allow,deny
Allow from all
/Directory
ProxyPass /errors !
ProxyPass / http://ethan.xx.com:8085/sabnzbd/ retry=0
ProxyPassReverse / http://ethan.xx.com:8085/sabnzbd/
SetEnv proxy-nokeepalive 1
/VirtualHost
VirtualHost *:443
ServerName svn.xx.com
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/xx/star.xx.com/apache.crt
SSLCertificateKeyFile /etc/ssl/xx/star.xx.com/apache.key
SSLCACertificateFile /etc/ssl/xx/ca.crt
SSLVerifyClient optional
ErrorDocument 403 /errors/certneeded.html
Alias /errors /usr/local/etc/apache22/xxerrors
Location /
DAV svn
SVNPath /tank/svn/repos/devel
/Location
LocationMatch ^(?!/errors/)
SSLRequire %{SSL_CLIENT_VERIFY} eq SUCCESS
SSLVerifyClient optional
/LocationMatch
SSLVerifyDepth 1
SSLCARevocationFile /etc/ssl/xx/ca.crl
SSLUserName SSL_CLIENT_S_DN_Email
/VirtualHost
This is httpd 2.2.21 btw
Cheers
Tom
Re: Why aren't name-based vhosts not working properly under SSL?
On Mon, Apr 16, 2012 at 5:25 PM, Issac Goldstand mar...@beamartyr.net wrote: Are you sure that your client supports SNI? This is not reliant on SNI. Cheers Tom
Re: Why aren't name-based vhosts not working properly under SSL?
On 16.04.2012 12:24, Plüm, Rüdiger, Vodafone Group wrote: Without a NameVirtualHost directive this cannot work as you intend. Add NameVirtualHost *:433 I see... I thought, I'm already giving Apache all the information it needs, though (with ServerAlias directives)... But if spelling-out the NameVirtualHost is all I need to add, that works for me... Thank you! Yours, -mi
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy
Hi Tom, On Mon, Apr 16, 2012 at 04:02:00PM +0100, Tom Evans wrote: This could be a side-effect of ProxyPreserveHost On since only with ProxyPreserveHost On does it make any sense anyways. With ProxyPreserveHost Off, the SNI data should contain the hostname from the ProxyPassReverse directive. Er, surely you mean ProxyPass directive here. The ProxyPassReverse directive is only used for rewriting response headers, it has nothing to do with altering the proxied request. To be honest, I'm making this all up as I go along. Thanks for pointing me in the right direction. -- Thanks, Micha
