Re: [users@httpd] [httpd2.4.57]Possible conflicts between VHosts with SSL and LimitRequestLine

2024-01-21 Thread Florent Thomas
Great thanks for your quick answer. 

If I understand well setting LimitRequestLine 10240 in name based virtualhost ? 
So what is your recommendation. 

Anyway, thanks for the time already spent on this. 

Regards 



Florent THOMAS 

☎ +33 972 457 755 
✉ [ mailto:florent.tho...@mind-and-go.com | florent.tho...@mind-and-go.com ] 


Mind & Go 
14, Rue Pierre Cartelet | 66000 PERPIGNAN [ https://mind-and-go.com/ |   ] [ 
https://www.facebook.com/Mind-And-Go-296462057466508/ ] [ 
https://twitter.com/MindAndGo |   ] [ 
https://www.linkedin.com/company/mind-and-go |   ] 


De: "Eric Covener"  
À: "users"  
Envoyé: Dimanche 21 Janvier 2024 14:48:03 
Objet: Re: [users@httpd] [httpd2.4.57]Possible conflicts between VHosts with 
SSL and LimitRequestLine 

The hostname, normally in the Host header, is not read until after the request 
line. So it cannot be effectively set in name based vhosts. 

The manual already warns about it 

On Sun, Jan 21, 2024, 9:26 AM Florent Thomas 
 wrote: 



Hi everyone, 

I'm running : 
Server version: Apache/2.4.57 (Debian) 
Server built: 2023-04-13T03:26:51 
Server's Module Magic Number: 20120211:127 
Server loaded: APR 1.7.2, APR-UTIL 1.6.3, PCRE 10.42 2022-12-11 
Compiled using: APR 1.7.2, APR-UTIL 1.6.3, PCRE 10.42 2022-12-11 
Architecture: 64-bit 
Server MPM: event 
threaded: yes (fixed thread count) 
forked: yes (variable process count) 
Server compiled with 
-D APR_HAS_SENDFILE 
-D APR_HAS_MMAP 
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) 
-D APR_USE_PROC_PTHREAD_SERIALIZE 
-D APR_USE_PTHREAD_SERIALIZE 
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D APR_HAS_OTHER_CHILD 
-D AP_HAVE_RELIABLE_PIPED_LOGS 
-D DYNAMIC_MODULE_LIMIT=256 
-D HTTPD_ROOT="/etc/apache2" 
-D SUEXEC_BIN="/usr/lib/apache2/suexec" 
-D DEFAULT_PIDLOG="/var/run/apache2.pid" 
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status" 
-D DEFAULT_ERRORLOG="logs/error_log" 
-D AP_TYPES_CONFIG_FILE="mime.types" 
-D SERVER_CONFIG_FILE="apache2.conf" 

I've been struggling for almost 2 weeks on this weird issue. 
I have multiple vhosts working perfectly either in http and httpS with let's 
encrypt. 

Yet for one vhost we need to set limitrequestline to a higher value. I'm 
familiar with the procedure and I changed the value in the vhost. Sadly it 
didn't worked as expected. 
After searching in any place, enabling/disabling securities, modules etc... I 
found another conf conflicting with mine. 

The ssl.conf vhost placed in conf-enabled is causing troubles. However its 
content is not really complicated : 

LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so 
Listen 443 
 
ServerName publicdomainname.tld 
SSLEngine on 
SSLCertificateFile "/etc/ssl/certs/apache-httpd.crt" 
SSLCertificateKeyFile "/etc/ssl/private/apache-httpd.key" 
 

My other vhost is as follows : 

 
ServerName otherdomain.tld 
.../... 
 
RequestHeader set X-Forwarded-Proto "https" 
 
.../ 
LimitRequestLine 10240 
.../... 
Include /etc/letsencrypt/options-ssl-apache.conf 
 

When both are enabled, the LimitRequestLine is not considered when reaching 
htps://otherdomain.tld . When I comment the Vhost in ssl.conf everything works 
fine. 

Is there any "permeability" between vhosts ? is there any precedence that could 
cause this vhost to be considered as the "master" of some options? Could anyone 
lead me to wha I am doing wrong? 

Sorry if I'm not clear, any question and/or feedback would be appreciated. 

Regards, 

Florent THOMAS 






Re: [users@httpd] Nginx to Apache

2024-01-21 Thread Yehuda Katz
OpenVPN port-share has nothing to do with which HTTP server is running
behind it. You should have a completely working Apache configuration
separate from anything connected to OpenVPN, then you can change the
listening port for HTTPD and have OpenVPN forward traffic to it.

The sites-enabled folder is part of the way some distributions (I think
mainly Debian-based) like to set up HTTPD, but there is nothing special
about it. If you install the Debian/Ubuntu/etc. package on the same OS, you
will probably have /etc/apache2/sites-enabled/default also.

Either way, unless you have absolutely no other choice, don't do this. It
slows down your OpenVPN and HTTPS traffic and it does not provide any
additional security benefits.

- Y

On Sun, Jan 21, 2024 at 12:16 PM Jason Long 
wrote:

> Hello,
> The following article shows how to set up OpenVPN with Nginx:
>
> https://snikt.net/blog/2016/12/01/how-not-to-hide-openvpn-behind-https/ssl/
>
> I want to use Apache for this. Is /etc/nginx/sites-enabled/default
> equivalent to /etc/apache2/httpd.conf?
>
>
> Thank you.
>


[users@httpd] Nginx to Apache

2024-01-21 Thread Jason Long
Hello,The following article shows how to set up OpenVPN with Nginx:
https://snikt.net/blog/2016/12/01/how-not-to-hide-openvpn-behind-https/ssl/

I want to use Apache for this. Is /etc/nginx/sites-enabled/default equivalent 
to /etc/apache2/httpd.conf?


Thank you.

Re: [users@httpd] [httpd2.4.57]Possible conflicts between VHosts with SSL and LimitRequestLine

2024-01-21 Thread Eric Covener
>
>
>>
>> Is there any "permeability" between vhosts ? is there any precedence that
>> could cause this vhost to be considered as the "master" of some options?
>> Could anyone lead me to wha I am doing wrong?
>>
>
Yes, the "default vhost" for a set of name based hosts has its
configuration applied as soon as connection level details are known (rather
than request level details)

>


Re: [users@httpd] [httpd2.4.57]Possible conflicts between VHosts with SSL and LimitRequestLine

2024-01-21 Thread Eric Covener
The hostname, normally in the Host header, is not read until after the
request line. So it cannot be effectively set in name based vhosts.

The manual already warns about it

On Sun, Jan 21, 2024, 9:26 AM Florent Thomas
 wrote:

> Hi everyone,
>
> I'm running :
> *Server version: Apache/2.4.57 (Debian)*
> *Server built:   2023-04-13T03:26:51*
> *Server's Module Magic Number: 20120211:127*
> *Server loaded:  APR 1.7.2, APR-UTIL 1.6.3, PCRE 10.42 2022-12-11*
> *Compiled using: APR 1.7.2, APR-UTIL 1.6.3, PCRE 10.42 2022-12-11*
> *Architecture:   64-bit*
> *Server MPM: event*
> *  threaded: yes (fixed thread count)*
> *forked: yes (variable process count)*
> *Server compiled with*
> * -D APR_HAS_SENDFILE*
> * -D APR_HAS_MMAP*
> * -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)*
> * -D APR_USE_PROC_PTHREAD_SERIALIZE*
> * -D APR_USE_PTHREAD_SERIALIZE*
> * -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT*
> * -D APR_HAS_OTHER_CHILD*
> * -D AP_HAVE_RELIABLE_PIPED_LOGS*
> * -D DYNAMIC_MODULE_LIMIT=256*
> * -D HTTPD_ROOT="/etc/apache2"*
> * -D SUEXEC_BIN="/usr/lib/apache2/suexec"*
> * -D DEFAULT_PIDLOG="/var/run/apache2.pid"*
> * -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"*
> * -D DEFAULT_ERRORLOG="logs/error_log"*
> * -D AP_TYPES_CONFIG_FILE="mime.types"*
> * -D SERVER_CONFIG_FILE="apache2.conf"*
>
> I've been struggling for almost 2 weeks on this weird issue.
> I have multiple vhosts working perfectly either in http and httpS with
> let's encrypt.
>
> Yet for one vhost we need to set limitrequestline to a higher value. I'm
> familiar with the procedure and I changed the value in the vhost. Sadly it
> didn't worked as expected.
> After searching in any place, enabling/disabling securities, modules
> etc... I found another conf conflicting with mine.
>
> The *ssl.conf* vhost placed in conf-enabled is causing troubles. However
> its content is not really complicated :
>
> *LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so*
> *Listen 443*
> **
> *ServerName publicdomainname.tld*
> *SSLEngine on*
> *SSLCertificateFile "/etc/ssl/certs/apache-httpd.crt"*
> *SSLCertificateKeyFile "/etc/ssl/private/apache-httpd.key"*
> **
>
> My other vhost is as follows :
>
> **
> *ServerName otherdomain.tld*
> *.../...*
> **
> *RequestHeader set X-Forwarded-Proto "https"*
> **
> *   .../ *
> *LimitRequestLine 10240*
> *.../...*
> *Include /etc/letsencrypt/options-ssl-apache.conf*
> **
>
> When both are enabled, the LimitRequestLine is not considered when
> reaching htps://otherdomain.tld . When I comment the Vhost in ssl.conf
> everything works fine.
>
> Is there any "permeability" between vhosts ? is there any precedence that
> could cause this vhost to be considered as the "master" of some options?
> Could anyone lead me to wha I am doing wrong?
>
> Sorry if I'm not clear, any question and/or feedback would be appreciated.
>
> Regards,
>
> Florent THOMAS
>


[users@httpd] [httpd2.4.57]Possible conflicts between VHosts with SSL and LimitRequestLine

2024-01-21 Thread Florent Thomas
Hi everyone, 

I'm running : 
Server version: Apache/2.4.57 (Debian) 
Server built: 2023-04-13T03:26:51 
Server's Module Magic Number: 20120211:127 
Server loaded: APR 1.7.2, APR-UTIL 1.6.3, PCRE 10.42 2022-12-11 
Compiled using: APR 1.7.2, APR-UTIL 1.6.3, PCRE 10.42 2022-12-11 
Architecture: 64-bit 
Server MPM: event 
threaded: yes (fixed thread count) 
forked: yes (variable process count) 
Server compiled with 
-D APR_HAS_SENDFILE 
-D APR_HAS_MMAP 
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) 
-D APR_USE_PROC_PTHREAD_SERIALIZE 
-D APR_USE_PTHREAD_SERIALIZE 
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D APR_HAS_OTHER_CHILD 
-D AP_HAVE_RELIABLE_PIPED_LOGS 
-D DYNAMIC_MODULE_LIMIT=256 
-D HTTPD_ROOT="/etc/apache2" 
-D SUEXEC_BIN="/usr/lib/apache2/suexec" 
-D DEFAULT_PIDLOG="/var/run/apache2.pid" 
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status" 
-D DEFAULT_ERRORLOG="logs/error_log" 
-D AP_TYPES_CONFIG_FILE="mime.types" 
-D SERVER_CONFIG_FILE="apache2.conf" 

I've been struggling for almost 2 weeks on this weird issue. 
I have multiple vhosts working perfectly either in http and httpS with let's 
encrypt. 

Yet for one vhost we need to set limitrequestline to a higher value. I'm 
familiar with the procedure and I changed the value in the vhost. Sadly it 
didn't worked as expected. 
After searching in any place, enabling/disabling securities, modules etc... I 
found another conf conflicting with mine. 

The ssl.conf vhost placed in conf-enabled is causing troubles. However its 
content is not really complicated : 

LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so 
Listen 443 
 
ServerName publicdomainname.tld 
SSLEngine on 
SSLCertificateFile "/etc/ssl/certs/apache-httpd.crt" 
SSLCertificateKeyFile "/etc/ssl/private/apache-httpd.key" 
 

My other vhost is as follows : 

 
ServerName otherdomain.tld 
.../... 
 
RequestHeader set X-Forwarded-Proto "https" 
 
.../ 
LimitRequestLine 10240 
.../... 
Include /etc/letsencrypt/options-ssl-apache.conf 
 

When both are enabled, the LimitRequestLine is not considered when reaching 
htps://otherdomain.tld . When I comment the Vhost in ssl.conf everything works 
fine. 

Is there any "permeability" between vhosts ? is there any precedence that could 
cause this vhost to be considered as the "master" of some options? Could anyone 
lead me to wha I am doing wrong? 

Sorry if I'm not clear, any question and/or feedback would be appreciated. 

Regards, 

Florent THOMAS 


[users@httpd] Provider for AuthLDAPBind credentials

2024-01-21 Thread sebb
At present, the LDAP credentials (if needed) have to be provided in
each stanza. Whilst the password can be obtained from a central source
by using the exec: function, this is not available for the DN. Any
changes to the DN will have to be made everywhere it appears.

Would it be worth adding support for some kind of LDAP credentials provider?
In the simplest case, this could be a file.
This would make credential management easier.

Alternatively, it would help to enable exec: support for the DN, but a
generalised provider would be more flexible.

Sebb

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org