Re: Listen 443 https

[Daniel]

I have to admit my point of view focuses on more generic cases rather
than extreme cases like the one you describe with "hundreds of
virtualhosts".



2017-09-18 20:03 GMT+02:00 Reindl Harald :
>
>
> Am 18.09.2017 um 19:28 schrieb Daniel:
>>
>> I see
>>
>> But we already have a handy directive to avoid repetition when
>> necessary, a directive that btw many distros abuse, "Include". You
>> define the common parts in a single file and Include the appropiate
>> file.
>
>
> that scales bad when the vhost itself is already one of hundrets of Includes
>


> i have currently written/refactored a "config parser" for vhosts with
> support of some comments to configure Letsencrypt tasks as well as generate
> the remap/ssl config of a reverse proxy, based on some Alias-statements
> webstats shellscripts are generated and the whole hosting database is feeded
> with that data too
>
> that works independent of the number of hosts, a shellscript on the
> admin-servers fetchs all config file sof all webservers and from there the
> central proxy configuration is feeded
>
> well, in other word, with some lines of code based on apache vhost includes
> the whole company is driven and implement includs support here would be at
> least dangerous and hard to test since that all runs over many machines and
> testing environments
>

Re: Listen 443 https

[Reindl Harald]

Am 18.09.2017 um 19:28 schrieb Daniel:

I see

But we already have a handy directive to avoid repetition when
necessary, a directive that btw many distros abuse, "Include". You
define the common parts in a single file and Include the appropiate
file.


that scales bad when the vhost itself is already one of hundrets of 
Includes


i have currently written/refactored a "config parser" for vhosts with 
support of some comments to configure Letsencrypt tasks as well as 
generate the remap/ssl config of a reverse proxy, based on some 
Alias-statements webstats shellscripts are generated and the whole 
hosting database is feeded with that data too


that works independent of the number of hosts, a shellscript on the 
admin-servers fetchs all config file sof all webservers and from there 
the central proxy configuration is feeded


well, in other word, with some lines of code based on apache vhost 
includes the whole company is driven and implement includs support here 
would be at least dangerous and hard to test since that all runs over 
many machines and testing environments



2017-09-18 19:18 GMT+02:00 Reindl Harald :


Am 18.09.2017 um 17:56 schrieb Daniel:


I tried to read and understand the whole thread and what we are trying
to solve here, but I can't help to think this is an attempt at a new
".htaccess" wildcard thing for SSL that will end in greater confusion.

in Freenode #httpd we generally try to teach people to not be afraid
of defining the necessary virtualhosts. Everyone seems inclined, due
to the amount of trash they have found through google, to define a
single .htaccess files that will solve all their cases, redirections,
and whatnot, and 90% are frustrated on how complicated it is.

The generic solution we give is, (the iconic simplest way), one
virtualhost for each:


ServerName whatever.example.com
Redirect / https://whatever.example.com/



ServerName whatever.example.com
SSLEngine on
etc..


Isn't this much better than any other attempt at reducing it to
"another minimum expression" in a complicated kind of way?



no it is not - have fun define two hosts with all options and i would have
much more samples with much more php-options which needs to be included in
both in doubt

yes, the software fetching lyrics likely had a problem with self-signed
certificates which was the case until short ago but that don't make the
config unreasonable exclude specific locations from enforced https

the only problem cuurently is that $_SERVER['HTTP_PORT'] is wrong for such a
vhost with 80 while it should be 443 in case of a https-connection


  DocumentRoot "/mnt/data/www/example.rhsoft.net"
  ServerName example.rhsoft.net
  ServerAlias example.test.rh example example.rh.thelounge.net
  Alias "/usage" "/var/www/usage/example"
  CustomLog "/var/log/apache_example.log" combined
  
  php_admin_value open_basedir
"/mnt/data/www/example.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/usr/share/php:/usr/share/pear:/mnt/data/audio:/media/WALKMAN/music"
  php_admin_value upload_tmp_dir
"/mnt/data/www/example.rhsoft.net/uploadtemp"
  php_admin_value soap.wsdl_cache_dir
"/mnt/data/www/example.rhsoft.net/uploadtemp"
  php_flag session.cookie_secure "1"
  Require all granted
  
  
  Require all denied
  
  
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !lyrics.php
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
  
  
  SetOutputFilter RATE_LIMIT
  SetEnv rate-limit 2800
  
  RedirectMatch 404 ^/modules/karaoke\-download\.php$
  RedirectMatch 404 ^/modules/music/copy\-cli\.php$
  RedirectMatch 404 ^/modules/music/validate\-all\-id3\-tags\.php$
  SSLEngine Optional
  SSLUseStapling On
  SSLCertificateFile "/var/lib/letsencrypt/certs/rhsoft-example.conf_rsa.pem"
  SSLCertificateFile
"/var/lib/letsencrypt/certs/rhsoft-example.conf_ecdsa.pem"

Re: Listen 443 https

[Stefan Eissing]

Thanks for you feedback, Daniel. Very much appreciated! You describe
the approach I suggest as "confusing" and "complicated", while for me
it is the opposite. ;-)

But there are really two separate things here. The SSLEngine addition
and the multi-port vhost. I'll argue that the first make sense, even if
you do not want to use the second one.

SSLEngine addr-list
-
The case I would like to make for "SSLEngine addr-list" is that it allows an
admin to define use of TLS on a port (for all or a specific address) in
one line. It is my understanding that all VirtualHosts on the same port
either need to do TLS or none should.

If a server has 100 vhosts on *:443, the admin needs to "SSLEngine on"
in each and every one of them. The task to do that is certainly manageable
for an admin, but why does it have to be that way? Why give the admin
the option to screw up and forget the 99th and see the error only when
someone accesses that host? With an implicit port match on SSLEngine,
 a VirtualHost without certifcates fails the config immediately.

So, I'd argue that for a very common case, "SSLEngine *:443" makes
the configuration easier and offers better fail-safes.

This all holds true if one "folds" virtualhosts on a address/port list
or keeps separate ones for each address, as you think is superior.


VirtualHost addr-list
--
This is a feature that is already there. The new "SSLEngine addr" makes
it usable for http: and https: access. That is new. I think for someone
migrating a site to https:, it is a good approach, but YMMV.

In https://github.com/icing/mod_md/wiki/Migration I describe how
one ca go from a *:80 vhost, add Let's Encrypt certs, serve 80
and 443 both until everything is working as planned and then switch over
with permanent redirects and HSTS to the https: presence.

I recommend to duplicate VirtualHost initially, so that the *:80 can
be left unchanged during migration. But propose - with the help of
the trunk changes, if we decide to backport them - to end up with
a configuration *very* similar to the start one. To be exact, the
config has 5 lines added and 1 edited to add *:443. Migrating a 2nd
vhost on that server would add only 1 new line and 1 edit.

So, from *that* perspective I hope the admin of such a site sees it
as not confusing and not complicate to migrate to https:.

We need to keep in mind that browser will distrust http: *very* soon
and that admins will look for an easy way to offer https:. I hope that
the proposed way is attractive and will help. But it certainly is not
the only way. And there are certainly configurations where it is not
even a good way.

Cheers,

Stefan

Am 18.09.2017 um 17:56 schrieb Daniel:

I tried to read and understand the whole thread and what we are trying
to solve here, but I can't help to think this is an attempt at a new
".htaccess" wildcard thing for SSL that will end in greater confusion.

in Freenode #httpd we generally try to teach people to not be afraid
of defining the necessary virtualhosts. Everyone seems inclined, due
to the amount of trash they have found through google, to define a
single .htaccess files that will solve all their cases, redirections,
and whatnot, and 90% are frustrated on how complicated it is.

The generic solution we give is, (the iconic simplest way), one
virtualhost for each:


ServerName whatever.example.com
Redirect / https://whatever.example.com/



ServerName whatever.example.com
SSLEngine on
etc..


Isn't this much better than any other attempt at reducing it to
"another minimum expression" in a complicated kind of way?

Is it really neccessary to have  and try to
do the same thing as above in a new more confusing complicated way?

Of course users may not be admins, but still they can have virtualhost
for both ports (SSL and not SSL) and use .htaccess and all the
RewriteCond %{HTTPS} !on  etc..

But the way I see it.. Are we really going to complicate virtualhosts
too? Do we really need to offer added functionality to do the same
thing that is already being offered now in the simple starting example
I provided of two single virtualhosts, one for each? Obviously one can
complicate it already as needed using If, or RewriteCond, etc.. but
shouldn't we strive to make virtualhosts as simple to understand as
possible?


To me a single virtualhost which handles both SSL and non-SSL
connection seems like doing the opposite, adding a new way for user
confusion.

Perhaps we need to stop for a minute if we wand to add more
complicated ways to do the same thing we can already do (and probably
many should do) in a very simple way?

Regarding the SSL changes, SSLPolicy and such are great additions and
they belong in server config, we should stop there for the moment and
leave Virtualhost as simple as possible.

Hope I don't sound impolite or anything like that, the ideas thrown
and your work (@Stefan) is amazing!

2017-08-10 15:28 GMT+02:00 Stefan Eissing 

Re: Listen 443 https

[Daniel]

I see

But we already have a handy directive to avoid repetition when
necessary, a directive that btw many distros abuse, "Include". You
define the common parts in a single file and Include the appropiate
file.


2017-09-18 19:18 GMT+02:00 Reindl Harald :
>
> Am 18.09.2017 um 17:56 schrieb Daniel:
>>
>> I tried to read and understand the whole thread and what we are trying
>> to solve here, but I can't help to think this is an attempt at a new
>> ".htaccess" wildcard thing for SSL that will end in greater confusion.
>>
>> in Freenode #httpd we generally try to teach people to not be afraid
>> of defining the necessary virtualhosts. Everyone seems inclined, due
>> to the amount of trash they have found through google, to define a
>> single .htaccess files that will solve all their cases, redirections,
>> and whatnot, and 90% are frustrated on how complicated it is.
>>
>> The generic solution we give is, (the iconic simplest way), one
>> virtualhost for each:
>>
>> 
>> ServerName whatever.example.com
>> Redirect / https://whatever.example.com/
>> 
>>
>> 
>> ServerName whatever.example.com
>> SSLEngine on
>> etc..
>> 
>>
>> Isn't this much better than any other attempt at reducing it to
>> "another minimum expression" in a complicated kind of way?
>
>
> no it is not - have fun define two hosts with all options and i would have
> much more samples with much more php-options which needs to be included in
> both in doubt
>
> yes, the software fetching lyrics likely had a problem with self-signed
> certificates which was the case until short ago but that don't make the
> config unreasonable exclude specific locations from enforced https
>
> the only problem cuurently is that $_SERVER['HTTP_PORT'] is wrong for such a
> vhost with 80 while it should be 443 in case of a https-connection
>
> 
>  DocumentRoot "/mnt/data/www/example.rhsoft.net"
>  ServerName example.rhsoft.net
>  ServerAlias example.test.rh example example.rh.thelounge.net
>  Alias "/usage" "/var/www/usage/example"
>  CustomLog "/var/log/apache_example.log" combined
>  
>  php_admin_value open_basedir
> "/mnt/data/www/example.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/usr/share/php:/usr/share/pear:/mnt/data/audio:/media/WALKMAN/music"
>  php_admin_value upload_tmp_dir
> "/mnt/data/www/example.rhsoft.net/uploadtemp"
>  php_admin_value soap.wsdl_cache_dir
> "/mnt/data/www/example.rhsoft.net/uploadtemp"
>  php_flag session.cookie_secure "1"
>  Require all granted
>  
>  
>  Require all denied
>  
>  
>  RewriteEngine On
>  RewriteCond %{REQUEST_FILENAME} !lyrics.php
>  RewriteCond %{HTTPS} off
>  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
>  
>  
>  SetOutputFilter RATE_LIMIT
>  SetEnv rate-limit 2800
>  
>  RedirectMatch 404 ^/modules/karaoke\-download\.php$
>  RedirectMatch 404 ^/modules/music/copy\-cli\.php$
>  RedirectMatch 404 ^/modules/music/validate\-all\-id3\-tags\.php$
>  SSLEngine Optional
>  SSLUseStapling On
>  SSLCertificateFile "/var/lib/letsencrypt/certs/rhsoft-example.conf_rsa.pem"
>  SSLCertificateFile
> "/var/lib/letsencrypt/certs/rhsoft-example.conf_ecdsa.pem"
> 



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: Listen 443 https

[Reindl Harald]

Am 18.09.2017 um 17:56 schrieb Daniel:

I tried to read and understand the whole thread and what we are trying
to solve here, but I can't help to think this is an attempt at a new
".htaccess" wildcard thing for SSL that will end in greater confusion.

in Freenode #httpd we generally try to teach people to not be afraid
of defining the necessary virtualhosts. Everyone seems inclined, due
to the amount of trash they have found through google, to define a
single .htaccess files that will solve all their cases, redirections,
and whatnot, and 90% are frustrated on how complicated it is.

The generic solution we give is, (the iconic simplest way), one
virtualhost for each:


ServerName whatever.example.com
Redirect / https://whatever.example.com/



ServerName whatever.example.com
SSLEngine on
etc..


Isn't this much better than any other attempt at reducing it to
"another minimum expression" in a complicated kind of way?


no it is not - have fun define two hosts with all options and i would 
have much more samples with much more php-options which needs to be 
included in both in doubt


yes, the software fetching lyrics likely had a problem with self-signed 
certificates which was the case until short ago but that don't make the 
config unreasonable exclude specific locations from enforced https


the only problem cuurently is that $_SERVER['HTTP_PORT'] is wrong for 
such a vhost with 80 while it should be 443 in case of a https-connection



 DocumentRoot "/mnt/data/www/example.rhsoft.net"
 ServerName example.rhsoft.net
 ServerAlias example.test.rh example example.rh.thelounge.net
 Alias "/usage" "/var/www/usage/example"
 CustomLog "/var/log/apache_example.log" combined
 
 php_admin_value open_basedir 
"/mnt/data/www/example.rhsoft.net:/Volumes/dune/www-servers/phpincludes:/usr/share/php:/usr/share/pear:/mnt/data/audio:/media/WALKMAN/music"
 php_admin_value upload_tmp_dir 
"/mnt/data/www/example.rhsoft.net/uploadtemp"
 php_admin_value soap.wsdl_cache_dir 
"/mnt/data/www/example.rhsoft.net/uploadtemp"

 php_flag session.cookie_secure "1"
 Require all granted
 
 
 Require all denied
 
 
 RewriteEngine On
 RewriteCond %{REQUEST_FILENAME} !lyrics.php
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 
 
 SetOutputFilter RATE_LIMIT
 SetEnv rate-limit 2800
 
 RedirectMatch 404 ^/modules/karaoke\-download\.php$
 RedirectMatch 404 ^/modules/music/copy\-cli\.php$
 RedirectMatch 404 ^/modules/music/validate\-all\-id3\-tags\.php$
 SSLEngine Optional
 SSLUseStapling On
 SSLCertificateFile 
"/var/lib/letsencrypt/certs/rhsoft-example.conf_rsa.pem"
 SSLCertificateFile 
"/var/lib/letsencrypt/certs/rhsoft-example.conf_ecdsa.pem"

Re: Listen 443 https

[Daniel]

I tried to read and understand the whole thread and what we are trying
to solve here, but I can't help to think this is an attempt at a new
".htaccess" wildcard thing for SSL that will end in greater confusion.

in Freenode #httpd we generally try to teach people to not be afraid
of defining the necessary virtualhosts. Everyone seems inclined, due
to the amount of trash they have found through google, to define a
single .htaccess files that will solve all their cases, redirections,
and whatnot, and 90% are frustrated on how complicated it is.

The generic solution we give is, (the iconic simplest way), one
virtualhost for each:


ServerName whatever.example.com
Redirect / https://whatever.example.com/



ServerName whatever.example.com
SSLEngine on
etc..


Isn't this much better than any other attempt at reducing it to
"another minimum expression" in a complicated kind of way?

Is it really neccessary to have  and try to
do the same thing as above in a new more confusing complicated way?

Of course users may not be admins, but still they can have virtualhost
for both ports (SSL and not SSL) and use .htaccess and all the
RewriteCond %{HTTPS} !on  etc..

But the way I see it.. Are we really going to complicate virtualhosts
too? Do we really need to offer added functionality to do the same
thing that is already being offered now in the simple starting example
I provided of two single virtualhosts, one for each? Obviously one can
complicate it already as needed using If, or RewriteCond, etc.. but
shouldn't we strive to make virtualhosts as simple to understand as
possible?


To me a single virtualhost which handles both SSL and non-SSL
connection seems like doing the opposite, adding a new way for user
confusion.

Perhaps we need to stop for a minute if we wand to add more
complicated ways to do the same thing we can already do (and probably
many should do) in a very simple way?

Regarding the SSL changes, SSLPolicy and such are great additions and
they belong in server config, we should stop there for the moment and
leave Virtualhost as simple as possible.

Hope I don't sound impolite or anything like that, the ideas thrown
and your work (@Stefan) is amazing!

2017-08-10 15:28 GMT+02:00 Stefan Eissing :
> Now that mod_md has landed in trunk, I am looking at more ways
> to simplify a SSL configuration. Looking at the Listen directive,
> it has an optional 2nd protocol parameter.
>
> Would it be unreasonable to assume that a
> Listen NNN https
>
> means that "SSLEngine on" should be the default in all
> 
>ServerName xxx.yyy
>...
> 
>
> sections? Would we expect breakage by such a change?
>
> What about name-based virtual hosts that apply to _all_
> addresses and ports? E.g. something like:
> 
>ServerName xxx.yyy
>...
>
>   Redirect permanent "/" "https://xxx.yyy/;
>
>...
> 
>
> Do you find that ugly/feasible/desirable?
>
> -Stefan



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: Listen 443 https (SSLEngine Optional - dual host)

[Yann Ylavic]

Come on, let's keep technical once again. Personal grudges ended!

On Sun, Sep 17, 2017 at 3:20 AM, Reindl Harald  wrote:
>
>
> Am 17.09.2017 um 03:07 schrieb Nick Edwards:
>>
>> phpmyadmin 4.4.15  is YEARS old
>
>
> and how does that change the fact that
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c1 "SERVER_PORT 80" in
> case of a https-connection is plain wrong?
>
>> we using 4.7 for nearly a year, 4.7.2 is current
>
>
> nice for you when you don't have to support older PHP (sync the package to a
> RHEL 7 host with PHP 5.4 - my whole own software is PHP 7.1 only with
> strict-types but that's not related to the topic at all)
>
>> this from a troll who verbally abuses the hell out of people on other
>> lists for posting similar comments using very outdated softwares   HAH, this
>> ones in google for life.
>
>
> the only troll in this thread is you and nobody asked you, just because i
> have never seen anything useful on any list since you only post if you face
> something from me and otherwise you are a silent lurker everywhere!
>
>> On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald > > wrote:
>>
>>
>> that's even more worse - phpMyAdmin 4.4.15.10 seems to handle
>> something wrong because $_SERVER['SERVER_PORT'] is wrong - and i had
>> myself some bad code using that var instead of $_SERVER['HTTPS']
>> which again leaded in a endless loop
>>
>> in case of phpMyAdmin it redirects to https://hostname:80/path/
>> after enter username/password - the workaround below in the config
>> file seems to solve that for now, but all in all that leaves a very
>> bad taste
>>
>> if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
>> {
>>   $cfg['ForceSSL'] = false;
>> }
>> else
>> {
>>   $cfg['ForceSSL'] = true;
>> }
>>
>>
>> Am 14.09.2017 um 18:16 schrieb Reindl Harald:
>>
>> Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
>>
>> Ok, as I read the code a bit more, there is a tangle of
>> things that can influence port/scheme selection. But what I
>> can see, the version in *trunk* should do the right thing
>> *iff*
>>
>> a) you use "SSLEngine *:443" instead of "Optional"
>> b) you use "ServerName xxx.yyy" *without* a port name
>>
>> the a
>> 
>> ServerName xxx.yyy
>> SSLEngine *:443
>>  ...
>> 
>>
>> should do the right thing here. Internal methods used to
>> generator Redirect Location headers, namely
>> ap_construct_url()
>> ap_get_server_port()
>> ap_http_scheme()
>> should give back the correct values for each connection and
>> als fill the Env Variables with the correct values.
>>
>>
>> what means "trunk" here?
>> a future 2.5/2.6/3.0 or a 2.4.x in the near future?
>>
>> within 2 weeks you need TLS on each and every host since Chrome
>> starts to warn about every page with a form tag and no TLS
>>
>> [root@srv-rhsoft:~]$ apachectl -t
>> AH00526: Syntax error on line 29 of
>> /etc/httpd/conf/sites_enabled/contentlounge.conf:
>> Argument must be On, Off, or Optional
>>
>> Am 14.09.2017 um 15:46 schrieb Reindl Harald
>> >:
>>
>>
>>
>> Am 14.09.2017 um 15:40 schrieb Stefan Eissing:
>>
>> Harald,
>> could you check if a configuration like:
>> UseCanonicalPhysicalPort on
>> in the server or vhost mitigates the problem?
>>
>>
>> it makes it even more terrible and the resulting http://
>> protocol instead https// on port 443 here even tiggers
>> mod_security
>>
>> even if it would mitigate that issue - having ports in
>> redirect urls easily leads to a lot of other problems
>> when proxy-servers are part of the game
>>
>> [harry@srv-rhsoft:/mnt/data/downloads]$ curl --head
>> --insecure https://contentlounge/cms
>> HTTP/1.1 301 Moved Permanently
>> Date: Thu, 14 Sep 2017 13:43:06 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=1561 us
>> Location: http://contentlounge:443/cms/
>> Cache-Control: max-age=0
>> Expires: Thu, 14 Sep 2017 13:43:06 GMT
>> Content-Type: text/html; charset=iso-8859-1
>>
>> Am 14.09.2017 um 12:00 schrieb Reindl Harald
>> > 

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

Am 17.09.2017 um 03:07 schrieb Nick Edwards:

phpmyadmin 4.4.15  is YEARS old


and how does that change the fact that 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519#c1 "SERVER_PORT 80" 
in case of a https-connection is plain wrong?



we using 4.7 for nearly a year, 4.7.2 is current


nice for you when you don't have to support older PHP (sync the package 
to a RHEL 7 host with PHP 5.4 - my whole own software is PHP 7.1 only 
with strict-types but that's not related to the topic at all)


this from a troll who verbally abuses the hell out of people on other 
lists for posting similar comments using very outdated softwares   HAH, 
this ones in google for life.


the only troll in this thread is you and nobody asked you, just because 
i have never seen anything useful on any list since you only post if you 
face something from me and otherwise you are a silent lurker everywhere!


On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald > wrote:



that's even more worse - phpMyAdmin 4.4.15.10 seems to handle
something wrong because $_SERVER['SERVER_PORT'] is wrong - and i had
myself some bad code using that var instead of $_SERVER['HTTPS']
which again leaded in a endless loop

in case of phpMyAdmin it redirects to https://hostname:80/path/
after enter username/password - the workaround below in the config
file seems to solve that for now, but all in all that leaves a very
bad taste

if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
  $cfg['ForceSSL'] = false;
}
else
{
  $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:

Ok, as I read the code a bit more, there is a tangle of
things that can influence port/scheme selection. But what I
can see, the version in *trunk* should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

    ServerName xxx.yyy
    SSLEngine *:443
     ...


should do the right thing here. Internal methods used to
generator Redirect Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and
als fill the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome
starts to warn about every page with a form tag and no TLS

[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of
/etc/httpd/conf/sites_enabled/contentlounge.conf:
Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald
>:



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
    UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http://
protocol instead https// on port 443 here even tiggers
mod_security

even if it would mitigate that issue - having ports in
redirect urls easily leads to a lot of other problems
when proxy-servers are part of the game

[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head
--insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

Am 14.09.2017 um 12:00 schrieb Reindl Harald
>:



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and
"SSLCertificateFile" configured non-https no
longer would work


OK, figured it out

Re: Listen 443 https (SSLEngine Optional - dual host)

[Nick Edwards]

phpmyadmin 4.4.15  is YEARS old

we using 4.7 for nearly a year, 4.7.2 is current

this from a troll who verbally abuses the hell out of people on other lists
for posting similar comments using very outdated softwares   HAH, this ones
in google for life.


On Sun, Sep 17, 2017 at 10:24 AM, Reindl Harald 
wrote:

>
> that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something
> wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some bad
> code using that var instead of $_SERVER['HTTPS'] which again leaded in a
> endless loop
>
> in case of phpMyAdmin it redirects to https://hostname:80/path/ after
> enter username/password - the workaround below in the config file seems to
> solve that for now, but all in all that leaves a very bad taste
>
> if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
> {
>  $cfg['ForceSSL'] = false;
> }
> else
> {
>  $cfg['ForceSSL'] = true;
> }
>
>
> Am 14.09.2017 um 18:16 schrieb Reindl Harald:
>
>> Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
>>
>>> Ok, as I read the code a bit more, there is a tangle of things that can
>>> influence port/scheme selection. But what I can see, the version in *trunk*
>>> should do the right thing *iff*
>>>
>>> a) you use "SSLEngine *:443" instead of "Optional"
>>> b) you use "ServerName xxx.yyy" *without* a port name
>>>
>>> the a
>>> 
>>>ServerName xxx.yyy
>>>SSLEngine *:443
>>> ...
>>> 
>>>
>>> should do the right thing here. Internal methods used to generator
>>> Redirect Location headers, namely
>>> ap_construct_url()
>>> ap_get_server_port()
>>> ap_http_scheme()
>>> should give back the correct values for each connection and als fill the
>>> Env Variables with the correct values.
>>>
>>
>> what means "trunk" here?
>> a future 2.5/2.6/3.0 or a 2.4.x in the near future?
>>
>> within 2 weeks you need TLS on each and every host since Chrome starts to
>> warn about every page with a form tag and no TLS
>>
>> [root@srv-rhsoft:~]$ apachectl -t
>> AH00526: Syntax error on line 29 of /etc/httpd/conf/sites_enabled/
>> contentlounge.conf:
>> Argument must be On, Off, or Optional
>>
>>> Am 14.09.2017 um 15:46 schrieb Reindl Harald :



 Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

> Harald,
> could you check if a configuration like:
>UseCanonicalPhysicalPort on
> in the server or vhost mitigates the problem?
>

 it makes it even more terrible and the resulting http:// protocol
 instead https// on port 443 here even tiggers mod_security

 even if it would mitigate that issue - having ports in redirect urls
 easily leads to a lot of other problems when proxy-servers are part of the
 game

 [harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure
 https://contentlounge/cms
 HTTP/1.1 301 Moved Permanently
 Date: Thu, 14 Sep 2017 13:43:06 GMT
 X-DNS-Prefetch-Control: off
 X-Content-Type-Options: nosniff
 X-Response-Time: D=1561 us
 Location: http://contentlounge:443/cms/
 Cache-Control: max-age=0
 Expires: Thu, 14 Sep 2017 13:43:06 GMT
 Content-Type: text/html; charset=iso-8859-1

 Am 14.09.2017 um 12:00 schrieb Reindl Harald :
>>
>>
>>
>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>
>>> If you want to experiment...
 
 is already recognized

>>> but with "SSLEngine On" and "SSLCertificateFile" configured
>>> non-https no longer would work
>>>
>>
>> OK, figured it out
>>
>> * you need the *first* vhost with "SSLEngine On"
>> * others can have "SSLEngine optional" and listen to 80 and 443
>>
>> but there is a bug: https://bz.apache.org/bugzilla
>> /show_bug.cgi?id=61519
>>
>> if the trailing slash is missing in the url the automatic redirect to
>> the full qualified folder-path points to http:// instead https://
>> and that does not happen within a vhost dedicated to :443 and "SSLEngine 
>> On"
>>
>> i was trapped in a endless loop because the php script making a
>> redirect to https:// had a bug and missed the traling / too
>>
>> 
>> DocumentRoot "/www/contentlounge"
>> ServerName contentlounge.rhsoft.net
>> SSLEngine optional
>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>> 
>>
>> [harry@srv-rhsoft:~]$ curl --head --insecure
>> https://contentlounge/cms
>> HTTP/1.1 301 Moved Permanently
>> Date: Thu, 14 Sep 2017 09:40:27 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=1311 us
>> Location: http://contentlounge/cms/
>> Cache-Control: max-age=0
>> Expires: Thu, 14 Sep 2017 09:40:27 GMT
>> Content-Type: text/html; charset=iso-8859-1
>>
>

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

assumption confirmed - and my connection is for sure https:// because of 
the mod_rewrite and finally HSTS


https://bz.apache.org/bugzilla/show_bug.cgi?id=61519 updated too

phpinfo():
SERVER_PORT 80


 ServerName www.rhsoft.net
 SSLEngine Optional
 SSLUseStapling On
 SSLCertificateFile "certs/rhsoft-www.conf_rsa.pem"
 SSLCertificateFile "certs/rhsoft-www.conf_ecdsa.pem"
 
  RewriteEngine on
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
 
 
  Header always set "Strict-Transport-Security" "max-age=31536000"
 


Am 17.09.2017 um 02:24 schrieb Reindl Harald:


that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something 
wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some 
bad code using that var instead of $_SERVER['HTTPS'] which again leaded 
in a endless loop


in case of phpMyAdmin it redirects to https://hostname:80/path/ after 
enter username/password - the workaround below in the config file seems 
to solve that for now, but all in all that leaves a very bad taste


if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
  $cfg['ForceSSL'] = false;
}
else
{
  $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
Ok, as I read the code a bit more, there is a tangle of things that 
can influence port/scheme selection. But what I can see, the version 
in *trunk* should do the right thing *iff*


a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
    ...


should do the right thing here. Internal methods used to generator 
Redirect Location headers, namely

ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill 
the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald :



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part 
of the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

Am 14.09.2017 um 12:00 schrieb Reindl Harald 
:




Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized
but with "SSLEngine On" and "SSLCertificateFile" configured 
non-https no longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519


if the trailing slash is missing in the url the automatic redirect 
to the full qualified folder-path points to http:// instead 
https:// and that does not happen within a vhost dedicated to :443 
and "SSLEngine On"


i was trapped in a endless loop because the php script making a 
redirect to https:// had a bug and missed the traling / too



DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https (SSLEngine Optional - dual host)

[Reindl Harald]

that's even more worse - phpMyAdmin 4.4.15.10 seems to handle something 
wrong because $_SERVER['SERVER_PORT'] is wrong - and i had myself some 
bad code using that var instead of $_SERVER['HTTPS'] which again leaded 
in a endless loop


in case of phpMyAdmin it redirects to https://hostname:80/path/ after 
enter username/password - the workaround below in the config file seems 
to solve that for now, but all in all that leaves a very bad taste


if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === 'off')
{
 $cfg['ForceSSL'] = false;
}
else
{
 $cfg['ForceSSL'] = true;
}


Am 14.09.2017 um 18:16 schrieb Reindl Harald:

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:
Ok, as I read the code a bit more, there is a tangle of things that 
can influence port/scheme selection. But what I can see, the version 
in *trunk* should do the right thing *iff*


a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
    ...


should do the right thing here. Internal methods used to generator 
Redirect Location headers, namely

ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill 
the Env Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald :



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part 
of the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald :



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized
but with "SSLEngine On" and "SSLCertificateFile" configured 
non-https no longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61519


if the trailing slash is missing in the url the automatic redirect 
to the full qualified folder-path points to http:// instead 
https:// and that does not happen within a vhost dedicated to :443 
and "SSLEngine On"


i was trapped in a endless loop because the php script making a 
redirect to https:// had a bug and missed the traling / too



DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Reindl Harald]

Am 14.09.2017 um 16:08 schrieb Stefan Eissing:

Ok, as I read the code a bit more, there is a tangle of things that can 
influence port/scheme selection. But what I can see, the version in *trunk* 
should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
...


should do the right thing here. Internal methods used to generator Redirect 
Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill the Env 
Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald :



Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,
could you check if a configuration like:
   UseCanonicalPhysicalPort on
in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol instead 
https// on port 443 here even tiggers mod_security

even if it would mitigate that issue - having ports in redirect urls easily 
leads to a lot of other problems when proxy-servers are part of the game

[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald :



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer 
would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to the full qualified 
folder-path points to http:// instead https:// and that does not happen within a vhost 
dedicated to :443 and "SSLEngine On"

i was trapped in a endless loop because the php script making a redirect to 
https:// had a bug and missed the traling / too


DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Stefan Eissing]

> Am 14.09.2017 um 16:19 schrieb Eric Covener :
> 
>> To recap: I am looking for an easy way to instruct someone to enable https: 
>> for
>> 
>> Listen 80
>> 
>> 
>>   ServerName blabla.org
>>   ...lots of stuff...
>> 
>> 
>> and with the current trunk, she can change this to:
>> 
>> Listen 80
>> Listen 443
>> SSLEngine *:443
>> 
>> ManagedDomain blabla.org
>> 
>>   ServerName blabla.org
>>   ...lots of stuff...
>> 
>> 
>> Hey, it's not that I *want* to define this on my own. I am asking since 
>> March for feedback on these things here. I am not sure how to react to 
>> "Don't like this so much." now.
> 
> It's a bit hard for me to understand the contrast points in this
> thread, even with the followups, especially as a non-mod_ssl user. So
> take my earlier feedback from today with a grain of salt.My
> personal preference is to give someone directives with expressive
> names if the objective is to make the basic configuration easier.

Understood. I can totally agree to the point about descriptive names. I am not 
a big fan of "SSLEngine" myself. I chose it because:

a) it already is the central directive to enable mod_ssl
b) there are other *Engine configs similar, so it is a common pattern in httpd.
c) A new directive would need to describe how it interacts with SSLEngine and 
what has precedence where.

But we could use a different name. I would, no matter the name, like a 
directive that is one line in the global context. Editing the same directives 
in all virtual hosts is tedious, error-prone work *). 


One other way of providing more descriptive SSL setups would be a new 
"SSLPolicy" directives. We could pre-define


  SSLEngine *:443


and people just add

SSLPolicy auto-enable

to their httpd.conf (we need *some* new config, to make that happen in 2.4.x).

Cheers,
Stefan

*) I already got several people testing mod_md and forgetting "SSLEngine on". 
The problem is that clients often spew out a cryptic (haha!) error message 
about TLS record lengths or some such that does not really help people to 
discover their, easy to fix, mistake.

Re: Listen 443 https

[Eric Covener]

> To recap: I am looking for an easy way to instruct someone to enable https: 
> for
>
> Listen 80
>
> 
>ServerName blabla.org
>...lots of stuff...
> 
>
> and with the current trunk, she can change this to:
>
> Listen 80
> Listen 443
> SSLEngine *:443
>
> ManagedDomain blabla.org
> 
>ServerName blabla.org
>...lots of stuff...
> 
>
> Hey, it's not that I *want* to define this on my own. I am asking since March 
> for feedback on these things here. I am not sure how to react to "Don't like 
> this so much." now.

It's a bit hard for me to understand the contrast points in this
thread, even with the followups, especially as a non-mod_ssl user. So
take my earlier feedback from today with a grain of salt.My
personal preference is to give someone directives with expressive
names if the objective is to make the basic configuration easier.

Re: Listen 443 https

[Stefan Eissing]

Ok, as I read the code a bit more, there is a tangle of things that can 
influence port/scheme selection. But what I can see, the version in *trunk* 
should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a 

  ServerName xxx.yyy
  SSLEngine *:443
   ...


should do the right thing here. Internal methods used to generator Redirect 
Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill the Env 
Variables with the correct values.

-Stefan

> Am 14.09.2017 um 15:46 schrieb Reindl Harald :
> 
> 
> 
> Am 14.09.2017 um 15:40 schrieb Stefan Eissing:
>> Harald,
>> could you check if a configuration like:
>>   UseCanonicalPhysicalPort on
>> in the server or vhost mitigates the problem?
> 
> it makes it even more terrible and the resulting http:// protocol instead 
> https// on port 443 here even tiggers mod_security
> 
> even if it would mitigate that issue - having ports in redirect urls easily 
> leads to a lot of other problems when proxy-servers are part of the game
> 
> [harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
> https://contentlounge/cms
> HTTP/1.1 301 Moved Permanently
> Date: Thu, 14 Sep 2017 13:43:06 GMT
> X-DNS-Prefetch-Control: off
> X-Content-Type-Options: nosniff
> X-Response-Time: D=1561 us
> Location: http://contentlounge:443/cms/
> Cache-Control: max-age=0
> Expires: Thu, 14 Sep 2017 13:43:06 GMT
> Content-Type: text/html; charset=iso-8859-1
> 
>>> Am 14.09.2017 um 12:00 schrieb Reindl Harald :
>>> 
>>> 
>>> 
>>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
> If you want to experiment...
> 
> is already recognized
 but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
 longer would work
>>> 
>>> OK, figured it out
>>> 
>>> * you need the *first* vhost with "SSLEngine On"
>>> * others can have "SSLEngine optional" and listen to 80 and 443
>>> 
>>> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519
>>> 
>>> if the trailing slash is missing in the url the automatic redirect to the 
>>> full qualified folder-path points to http:// instead https:// and that does 
>>> not happen within a vhost dedicated to :443 and "SSLEngine On"
>>> 
>>> i was trapped in a endless loop because the php script making a redirect to 
>>> https:// had a bug and missed the traling / too
>>> 
>>> 
>>> DocumentRoot "/www/contentlounge"
>>> ServerName contentlounge.rhsoft.net
>>> SSLEngine optional
>>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>>> 
>>> 
>>> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
>>> HTTP/1.1 301 Moved Permanently
>>> Date: Thu, 14 Sep 2017 09:40:27 GMT
>>> X-DNS-Prefetch-Control: off
>>> X-Content-Type-Options: nosniff
>>> X-Response-Time: D=1311 us
>>> Location: http://contentlounge/cms/
>>> Cache-Control: max-age=0
>>> Expires: Thu, 14 Sep 2017 09:40:27 GMT
>>> Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Reindl Harald]

Am 14.09.2017 um 15:40 schrieb Stefan Eissing:

Harald,

could you check if a configuration like:

   UseCanonicalPhysicalPort on

in the server or vhost mitigates the problem?


it makes it even more terrible and the resulting http:// protocol 
instead https// on port 443 here even tiggers mod_security


even if it would mitigate that issue - having ports in redirect urls 
easily leads to a lot of other problems when proxy-servers are part of 
the game


[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure 
https://contentlounge/cms

HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1


Am 14.09.2017 um 12:00 schrieb Reindl Harald :



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized

but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer 
would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to the full qualified 
folder-path points to http:// instead https:// and that does not happen within a vhost 
dedicated to :443 and "SSLEngine On"

i was trapped in a endless loop because the php script making a redirect to 
https:// had a bug and missed the traling / too


DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Stefan Eissing]

Harald,

could you check if a configuration like:

  UseCanonicalPhysicalPort on

in the server or vhost mitigates the problem?

Cheers,

Stefan

> Am 14.09.2017 um 12:00 schrieb Reindl Harald :
> 
> 
> 
> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>> If you want to experiment...
>>> 
>>> is already recognized
>> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
>> longer would work
> 
> OK, figured it out
> 
> * you need the *first* vhost with "SSLEngine On"
> * others can have "SSLEngine optional" and listen to 80 and 443
> 
> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519
> 
> if the trailing slash is missing in the url the automatic redirect to the 
> full qualified folder-path points to http:// instead https:// and that does 
> not happen within a vhost dedicated to :443 and "SSLEngine On"
> 
> i was trapped in a endless loop because the php script making a redirect to 
> https:// had a bug and missed the traling / too
> 
> 
> DocumentRoot "/www/contentlounge"
> ServerName contentlounge.rhsoft.net
> SSLEngine optional
> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
> 
> 
> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
> HTTP/1.1 301 Moved Permanently
> Date: Thu, 14 Sep 2017 09:40:27 GMT
> X-DNS-Prefetch-Control: off
> X-Content-Type-Options: nosniff
> X-Response-Time: D=1311 us
> Location: http://contentlounge/cms/
> Cache-Control: max-age=0
> Expires: Thu, 14 Sep 2017 09:40:27 GMT
> Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Stefan Eissing]

> Am 14.09.2017 um 12:00 schrieb Reindl Harald :
> 
> 
> 
> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>> If you want to experiment...
>>> 
>>> is already recognized
>> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
>> longer would work
> 
> OK, figured it out
> 
> * you need the *first* vhost with "SSLEngine On"
> * others can have "SSLEngine optional" and listen to 80 and 443
> 
> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

This seems what ap_get_server_port() does right now which is used by 
ap_construct_url(), which is used in the redirect.

As William pointed out already, server_rec->port is the culprit. Will look at 
it to see if it can be salvaged, at least for the standard ports.

-Stefan


> if the trailing slash is missing in the url the automatic redirect to the 
> full qualified folder-path points to http:// instead https:// and that does 
> not happen within a vhost dedicated to :443 and "SSLEngine On"
> 
> i was trapped in a endless loop because the php script making a redirect to 
> https:// had a bug and missed the traling / too
> 
> 
> DocumentRoot "/www/contentlounge"
> ServerName contentlounge.rhsoft.net
> SSLEngine optional
> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
> 
> 
> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
> HTTP/1.1 301 Moved Permanently
> Date: Thu, 14 Sep 2017 09:40:27 GMT
> X-DNS-Prefetch-Control: off
> X-Content-Type-Options: nosniff
> X-Response-Time: D=1311 us
> Location: http://contentlounge/cms/
> Cache-Control: max-age=0
> Expires: Thu, 14 Sep 2017 09:40:27 GMT
> Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Stefan Eissing]

> Am 14.09.2017 um 14:56 schrieb Eric Covener :
> 
> On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing
>  wrote:
>> 
>>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr :
>>> 
>>> Reminder, this will not work with the current server_rec, we have a 1:1 
>>> correspondence to the server port. We would need to stop looking at that 
>>> field and track the port entirely on the connection and the server rec 
>>> addresses array.
>> 
>> Urgs.
>> 
>> 1. Irregardless of multiple addresses in a VirtualHost, I still like the 
>> idea of
>> 
>>SSLEngine *:443 local_interface:8001
>> 
>> that is best used in the base server, once.
>> a) I think it is easy to understand what it does.
>> b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it
>> c) It causes required fails when a VirtualHost on a SSL port has no 
>> certificates
> 
> What do the parameters mean here?

Those are the addresses (same format as in VirtualHost) where "SSLEngine on" is 
implied, for all vhosts where no other SSLEngine is defined.

>> 
>> With that, we could advise people who want to start using SSL to include the 
>> following in their main conf:
>> 
>>  Listen 443
>>  # The following fails if your OpenSSL is not new enough.
>>  SSLPolicy modern
>>  SSLEngine *:443
> 
> I don't like this so much.

You mean, you will not use it? Or that you think this leads to 
misconfigurations? Or that there is an easier way?

> I'd rather a new directive altogether if it will live outside of the
> affected VH and that the name convey a little more of what it's doing.
> 
>> 2. For people *moving* from http: to https: for a VirtualHost, we'd advise
>> 
>>  
>>ServerName yourhostname
>>Redirect 301 "/" "https://yourhostname/;
>>  
>> 
>>  
>>ServerName yourhostname
>> ...the former http: config
>>  
>> 
> 
> The only difference from the as-is here is that the SSL config is
> implicit because of some global directive, right?

No, the SSL config is inherited, just as it is now. You can still overwrite it 
in the vhost.

> 
>> 
>> 3. For people wanting to offer both http: and https: for the same resources 
>> (maybe for a trial period), what would we tell them?
>> a) Copy to a new VirtualHost
>> b) Make separate file and Include in two VirtualHost?
>> c) Macros???
> 
> I think this leads back to 1 VH with directives like SSLRequireSSL and
> automatic SSL over 443 or opted in ports.
> Or, global configs w/ no VH at all that just work.

I am not sure what you mean and if you think it's positive or not.

To recap: I am looking for an easy way to instruct someone to enable https: for

Listen 80


   ServerName blabla.org
   ...lots of stuff...


and with the current trunk, she can change this to:

Listen 80
Listen 443
SSLEngine *:443

ManagedDomain blabla.org

   ServerName blabla.org
   ...lots of stuff...


Hey, it's not that I *want* to define this on my own. I am asking since March 
for feedback on these things here. I am not sure how to react to "Don't like 
this so much." now.


Cheers,

Stefan

Re: Listen 443 https

[Eric Covener]

On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing
 wrote:
>
>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr :
>>
>> Reminder, this will not work with the current server_rec, we have a 1:1 
>> correspondence to the server port. We would need to stop looking at that 
>> field and track the port entirely on the connection and the server rec 
>> addresses array.
>
> Urgs.
>
> 1. Irregardless of multiple addresses in a VirtualHost, I still like the idea 
> of
>
> SSLEngine *:443 local_interface:8001
>
> that is best used in the base server, once.
> a) I think it is easy to understand what it does.
> b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it
> c) It causes required fails when a VirtualHost on a SSL port has no 
> certificates

What do the parameters mean here?

>
> With that, we could advise people who want to start using SSL to include the 
> following in their main conf:
>
>   Listen 443
>   # The following fails if your OpenSSL is not new enough.
>   SSLPolicy modern
>   SSLEngine *:443

I don't like this so much.

I'd rather a new directive altogether if it will live outside of the
affected VH and that the name convey a little more of what it's doing.

> 2. For people *moving* from http: to https: for a VirtualHost, we'd advise
>
>   
> ServerName yourhostname
> Redirect 301 "/" "https://yourhostname/;
>   
>
>   
> ServerName yourhostname
>  ...the former http: config
>   
>

The only difference from the as-is here is that the SSL config is
implicit because of some global directive, right?

>
> 3. For people wanting to offer both http: and https: for the same resources 
> (maybe for a trial period), what would we tell them?
> a) Copy to a new VirtualHost
> b) Make separate file and Include in two VirtualHost?
> c) Macros???

I think this leads back to 1 VH with directives like SSLRequireSSL and
automatic SSL over 443 or opted in ports.
Or, global configs w/ no VH at all that just work.

Re: Listen 443 https

[Reindl Harald]

Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

is already recognized


but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
longer would work


OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to 
the full qualified folder-path points to http:// instead https:// and 
that does not happen within a vhost dedicated to :443 and "SSLEngine On"


i was trapped in a endless loop because the php script making a redirect 
to https:// had a bug and missed the traling / too



 DocumentRoot "/www/contentlounge"
 ServerName contentlounge.rhsoft.net
 SSLEngine optional
 SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1

Re: Listen 443 https

[Stefan Eissing]

> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr :
> 
> Reminder, this will not work with the current server_rec, we have a 1:1 
> correspondence to the server port. We would need to stop looking at that 
> field and track the port entirely on the connection and the server rec 
> addresses array.

Urgs.

1. Irregardless of multiple addresses in a VirtualHost, I still like the idea of

SSLEngine *:443 local_interface:8001

that is best used in the base server, once. 
a) I think it is easy to understand what it does.
b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it 
c) It causes required fails when a VirtualHost on a SSL port has no certificates

With that, we could advise people who want to start using SSL to include the 
following in their main conf:

  Listen 443
  # The following fails if your OpenSSL is not new enough. 
  SSLPolicy modern
  SSLEngine *:443


2. For people *moving* from http: to https: for a VirtualHost, we'd advise

  
ServerName yourhostname
Redirect 301 "/" "https://yourhostname/;
  

  
ServerName yourhostname
 ...the former http: config
  

?

3. For people wanting to offer both http: and https: for the same resources 
(maybe for a trial period), what would we tell them?
a) Copy to a new VirtualHost
b) Make separate file and Include in two VirtualHost?
c) Macros???

Cheers,

Stefan

---
Quick scan where we use server_rec->port:

core:
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
...
port = r->parsed_uri.port_str ? r->parsed_uri.port :
   r->server->port ? r->server->port :
   ap_default_port(r);

mod_log_config.c:
static const char *log_server_port(request_rec *r, char *a)
{
apr_port_t port;

if (*a == '\0' || !strcasecmp(a, "canonical")) {
port = r->server->port ? r->server->port : ap_default_port(r);
}


ssl_engine_init.c:
if ((sc->enabled == SSL_ENABLED_TRUE) && (s->port == 
DEFAULT_HTTP_PORT)) {

ssl_util.c:
char *ssl_util_vhostid(apr_pool_t *p, server_rec *s)
{
char *id;
SSLSrvConfigRec *sc;
char *host;
apr_port_t port;

host = s->server_hostname;
if (s->port != 0)
port = s->port;
else {

vhost.c:
/* the Port has to match now, because the rest don't have ports associated
 * with them. */
if (port != s->port) {
return 0;
}


> On Fri, Sep 1, 2017 at 10:12 AM, Eric Covener  wrote:
> > On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
> >  wrote:
> >> I get the first feedback from Apache users that want their http: only 
> >> hosts to also serve https:. This is nice feedback to improve usability of 
> >> mod_md.
> >>
> >> Ideally, what these people want - and that is purely my interpretation - 
> >> is to add a few lines to their config and - voila - https: is available. 
> >> And, honestly, why should they not expect that?
> >>
> >>
> >>
> >> Example: Duplication/Redirect
> >>
> >> They have something like:
> >> --
> >> Listen 80
> >> 
> >> ServerName xxx.yyy
> >> ...
> >> 
> >> --
> >>
> >> and want to also make that available on https:
> >> --
> >> Listen http://*:80
> >> Listen https://*:443
> >>
> >> 
> >> ServerName xxx.yyy
> >> AlternatePorts 443
> >> ...
> >> 
> >> --
> >>
> >> or redirect everyone to https:
> >> --
> >> Listen http://*:80
> >> Listen https://*:443
> >>
> >> 
> >> ServerName xxx.yyy
> >> RedirectPermanentFrom 80
> >> ...
> >> 
> >
> > I am not keen on the syntax because we already permit multiple
> > addresses in the VirtualHost tag.
> >
> > How about e.g.
> >
> > 
> 
> Again, fo

Re: Listen 443 https

[William A Rowe Jr]

Reminder, this will not work with the current server_rec, we have a 1:1
correspondence to the server port. We would need to stop looking at that
field and track the port entirely on the connection and the server rec
addresses array.

On Fri, Sep 1, 2017 at 10:12 AM, Eric Covener  wrote:
> On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
>  wrote:
>> I get the first feedback from Apache users that want their http: only
hosts to also serve https:. This is nice feedback to improve usability of
mod_md.
>>
>> Ideally, what these people want - and that is purely my interpretation -
is to add a few lines to their config and - voila - https: is available.
And, honestly, why should they not expect that?
>>
>>
>>
>> Example: Duplication/Redirect
>>
>> They have something like:
>> --
>> Listen 80
>> 
>> ServerName xxx.yyy
>> ...
>> 
>> --
>>
>> and want to also make that available on https:
>> --
>> Listen http://*:80
>> Listen https://*:443
>>
>> 
>> ServerName xxx.yyy
>> AlternatePorts 443
>> ...
>> 
>> --
>>
>> or redirect everyone to https:
>> --
>> Listen http://*:80
>> Listen https://*:443
>>
>> 
>> ServerName xxx.yyy
>> RedirectPermanentFrom 80
>> ...
>> 
>
> I am not keen on the syntax because we already permit multiple
> addresses in the VirtualHost tag.
>
> How about e.g.
>
> 

Again, fo

Re: Listen 443 https

[Stefan Eissing]

> Am 01.09.2017 um 17:12 schrieb Eric Covener :
> 
> On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
>  wrote:
>> I get the first feedback from Apache users that want their http: only hosts 
>> to also serve https:. This is nice feedback to improve usability of mod_md.
>> 
>> Ideally, what these people want - and that is purely my interpretation - is 
>> to add a few lines to their config and  - voila - https: is available. And, 
>> honestly, why should they not expect that?
>> 
>> 
>> 
>> Example: Duplication/Redirect
>> 
>> They have something like:
>> --
>> Listen 80
>> 
>>  ServerName xxx.yyy
>>  ...
>> 
>> --
>> 
>> and want to also make that available on https:
>> --
>> Listen http://*:80
>> Listen https://*:443
>> 
>> 
>>  ServerName xxx.yyy
>>  AlternatePorts 443
>>  ...
>> 
>> --
>> 
>> or redirect everyone to https:
>> --
>> Listen http://*:80
>> Listen https://*:443
>> 
>> 
>>  ServerName xxx.yyy
>>  RedirectPermanentFrom 80
>>  ...
>> 
> 
> I am not keen on the syntax because we already permit multiple
> addresses in the VirtualHost tag.
> 
> How about e.g.
> 
> 
>  # no protocol
>  ServerName example.com
>  # repurpose "optional" or pick something new
>  SSLEgine optional
>  # Extend SSLRequireSSL.  no-arg is deny. Default w/ "redirect" is
> 80, 443. For redirects, may need to not match TCP listening port
>  SSLRequireSSL ["redirect" [ from-port to-port ]]
> 

I like the SSLRequireSSL gist. I was thinking about this over the weekend and 
like the following a lot:

  SSLEngine *:443 10.0.0.1:8001
  SSLRequireSSL ["temporary"|"permanent" [ from-port to-port ]]

with "permanent" as default and port 443, or the first port in SSLEngine - if 
given - as default.

This can be specified in a  or, better even, in the base server. I 
think this can, together with multiple ports at , simplify 
configurations of TLS hosts. At least for people who want to offer the same 
resources on 80 and 443, or want to migrate existing *:80 hosts to TLS.

What do you think?

-Stefan

Re: Listen 443 https

[Eric Covener]

On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
 wrote:
> I get the first feedback from Apache users that want their http: only hosts 
> to also serve https:. This is nice feedback to improve usability of mod_md.
>
> Ideally, what these people want - and that is purely my interpretation - is 
> to add a few lines to their config and  - voila - https: is available. And, 
> honestly, why should they not expect that?
>
>
>
> Example: Duplication/Redirect
>
> They have something like:
> --
> Listen 80
> 
>   ServerName xxx.yyy
>   ...
> 
> --
>
> and want to also make that available on https:
> --
> Listen http://*:80
> Listen https://*:443
>
> 
>   ServerName xxx.yyy
>   AlternatePorts 443
>   ...
> 
> --
>
> or redirect everyone to https:
> --
> Listen http://*:80
> Listen https://*:443
>
> 
>   ServerName xxx.yyy
>   RedirectPermanentFrom 80
>   ...
> 

I am not keen on the syntax because we already permit multiple
addresses in the VirtualHost tag.

How about e.g.


  # no protocol
  ServerName example.com
  # repurpose "optional" or pick something new
  SSLEgine optional
  # Extend SSLRequireSSL.  no-arg is deny. Default w/ "redirect" is
80, 443. For redirects, may need to not match TCP listening port
  SSLRequireSSL ["redirect" [ from-port to-port ]]

Re: Listen 443 https

[Stefan Eissing]

I get the first feedback from Apache users that want their http: only hosts to 
also serve https:. This is nice feedback to improve usability of mod_md. 

Ideally, what these people want - and that is purely my interpretation - is to 
add a few lines to their config and  - voila - https: is available. And, 
honestly, why should they not expect that?



Example: Duplication/Redirect

They have something like:
--
Listen 80

  ServerName xxx.yyy
  ...

--

and want to also make that available on https:
--
Listen http://*:80
Listen https://*:443


  ServerName xxx.yyy
  AlternatePorts 443
  ...

--

or redirect everyone to https:
--
Listen http://*:80
Listen https://*:443


  ServerName xxx.yyy
  RedirectPermanentFrom 80
  ...

--

I am not hooked on the names, but I hope you understand the intent? Anyone with 
me on this?

Cheers,

Stefan


> Am 10.08.2017 um 16:19 schrieb Stefan Eissing :
> 
>> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr :
>> 
>> Let's break it down and consider the implications of Listen...
>> 
>> On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
>>  wrote:
>>> Now that mod_md has landed in trunk, I am looking at more ways
>>> to simplify a SSL configuration. Looking at the Listen directive,
>>> it has an optional 2nd protocol parameter.
>>> 
>>> Would it be unreasonable to assume that a
>>>   Listen NNN https
>>> 
>>> means that "SSLEngine on" should be the default in all
>>>   
>>>  ServerName xxx.yyy
>>>  ...
>>>   
>>> 
>>> sections?
>> 
>> Firstly, we have well understood protocols definitions, so there
>> are several shorthand flavors that could be introduced;
>> 
>> Listen https
>> 
>> has a very plain and obvious meaning. Thus, so would these;
>> 
>> Listen https://192.168.1.1
>> Listen https://xxx.yyy
>> Listen https://192.168.1.1:8443
>> Listen https://xxx.yyy:8443
> 
> I like this.



Coming back to this. If we - optionally - would support this in the 'Listen' 
directive

Re: Listen 443 https

[Reindl Harald]

Am 10.08.2017 um 17:57 schrieb William A Rowe Jr:


On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald
> wrote:
 >
 > 
 >  ServerName corecms.example.com 
 >  DocumentRoot "/www/corecms.example.com "
 >  

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your
certificate file
and your stapling choice from affecting h2 requests on port 80.

Another reason this will not work... Server/VHost config is static. All 
such directives are evaluated at config/startup time, global config is 
merged to per-vhost config. And that is the state of the host for that 
generation of the workers process.  will never be supported for 
those directives, it can work only on per-dir config options.


Final reason this won't be adopted as suggested; VirtualHost [:80] is 
implicit. I cannot see us ever changing this, it would break most 
configs. Maybe a port * feature?


If you want to experiment...

is already recognized


but with "SSLEngine On" and "SSLCertificateFile" configured non-https no 
longer would work, since H2 no longer supports mod_prefork i don't care 
about that part


for high traffic sites apache trafficserver is in front which scales 
much better and enbales H2 automatically but i want every backend vhost 
keep working as now independent and only DNS decides if it goes to the 
proxy - proxy which makes no sense for very small pages with no traffic 
all the time and only introdcues latency and wastes memory caches

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald 
wrote:
>
> 
>  ServerName corecms.example.com
>  DocumentRoot "/www/corecms.example.com"
>  

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your certificate file
and your stapling choice from affecting h2 requests on port 80.


Another reason this will not work... Server/VHost config is static. All
such directives are evaluated at config/startup time, global config is
merged to per-vhost config. And that is the state of the host for that
generation of the workers process.  will never be supported for those
directives, it can work only on per-dir config options.

Final reason this won't be adopted as suggested; VirtualHost [:80] is
implicit. I cannot see us ever changing this, it would break most configs.
Maybe a port * feature?

If you want to experiment...

is already recognized.

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald  wrote:
>
> it also would solve the chicken-egg-problem (again, without mod_md) that you
> first need the http-host working for the well-known verfication file and the
> path of the certificate could be easily pre-configured in the way of my
> example, just warn insteda a fatal error on reload when the certfile don't
> exist
> 
>
> 
>  ServerName corecms.example.com
>  DocumentRoot "/www/corecms.example.com"
>  
>   SSLEngine On
>   SSLUseStapling Off
>   SSLCertificateFile "conf/ssl/corecms.pem"
>  
>  
>   php_admin_value open_basedir "/www/corecms.example.com"
>   php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
>  
> 

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your certificate file
and your stapling choice from affecting h2 requests on port 80.

Re: Listen 443 https

[William A Rowe Jr]

On Thu, Aug 10, 2017 at 9:19 AM, Stefan Eissing
 wrote:
>
>> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr :
>>
>>> Would we expect breakage by such a change?
>>
>> I think that Listen *:NNN is maybe the most common misconfiguration
>> in general, on multihomed boxes (and Listen myhost:NNN not answering
>> the call of localhost being a most common point of confusion :)
>>
>> Your mention of ServerName is a little misleading. A corresponding
>> virtual host isn't needed at all. And mod_ssl handshake is always
>> controlled by the physical vhost (first matching named vhost, name
>> being ignored), which makes this a little more confusing to users.
>
> If understand you correctly, if the first matching (document order?)
> vhost for the address:port (with wildcards) has "SSLEngine on", we
> get mod_ssl engaged. If not, we try to parse a http: request?
>
> Hmmm. That...could be improved.

When the NamedVirtualHost still existed and was still documented,
this was all more obvious to the end-user

This is where it is all explained poorly as features such as '*' were
further modified, so the document is pretty muddy and partly wrong;

http://httpd.apache.org/docs/2.4/vhosts/name-based.html

The author here clearly misunderstood the role of virtual hosts for
directives which affect the initial establishment of the connection
in the read request behavior, prior to re-electing a more specific
name-based vhost match. This sentence in particular could be
corrected; "In first establishing the connection and reading the
request off the wire, and subsequently, If no matching ServerName
or ServerAlias is found in the set of virtual hosts containing the
most specific matching IP address and port combination, then
the first listed virtual host that matches that will be used."

That's more correct but still clumsy, better wordsmithing would
be appreciated. It's answered much better in
http://httpd.apache.org/docs/2.4/mod/core.html#virtualhost

"When a request is received, the server first maps it to the best
matching  based on the local IP address and port
combination only. Non-wildcards have a higher precedence. If no match
based on IP and port occurs at all, the "main" server configuration is
used."

"If multiple virtual hosts contain the best matching IP address and
port, the server selects from these virtual hosts the best match based
on the requested hostname. If no matching name-based virtual host is
found, then the first listed virtual host that matched the IP address
will be used. As a consequence, the first listed virtual host for a
given IP address and port combination is the default virtual host for
that IP and port combination."

But even here we could be more specific in the second para;
"Once the request is received"...

Back to the behavior of mod_ssl, the SSLProtocol directive is
obviously dictated by the physical vhost. But SSLHonorCipherOrder
and other post-SNI decisions? I'm unsure whether the handshake
is "completed" with the SNI name-based election or physical vhost.


>> What leads me to wonder, even with some easier-to-read Listen
>> directives, if the user wouldn't be confused by omission of the
>> SSLEngine on, when their other SSL directives aren't behaving
>> as expected. Because they placed them in the wrong ,
>> obviously. But not obvious to them. The need to toggle SSLEngine
>> may be an unintended usability feature.
>
> I think my gut feeling tells me that "SSLEngine on|off" is more
> part of the port and of the vhost. The vhost may add other SSL*
> configurations, once SNI has identified the correct one. But for
> a certain port (address:port) we either do TLS or not.
>
> So, I was looking for ways to express that and Listen seems a good start.

The protocol tag existed for only one reason, to imply a corresponding
AcceptFilter (e.g. data or no data or http ready on the wire before the
accept would recognize the connection.)

Each time we overload this meaning we are introducing an alternate
or alias to other httpd configuration, which might become confusing
to many users. I just suggest we tread carefully and this time, think
the potential confusion and side effects through.

The other issue IMO is multiple protocols on the given listener.
Already true of http / h2c / h2. A recent proposal suggested to add
PROXY protocol to that list, and the list of potential combinations
goes on.

Re: Listen 443 https

[Reindl Harald]

Am 10.08.2017 um 15:28 schrieb Stefan Eissing:

Now that mod_md has landed in trunk, I am looking at more ways
to simplify a SSL configuration. Looking at the Listen directive,
it has an optional 2nd protocol parameter.

Would it be unreasonable to assume that a
 Listen NNN https

means that "SSLEngine on" should be the default in all
 
ServerName xxx.yyy
...
 

sections? Would we expect breakage by such a change?

What about name-based virtual hosts that apply to _all_
addresses and ports? E.g. something like:
 
ServerName xxx.yyy
...

   Redirect permanent "/" "https://xxx.yyy/;

...
 

Do you find that ugly/feasible/desirable?


it makes it unflexible, something like port-specific options would solve 
the current problem that you need to define aecgh and every vhost with 
all it's options twice and that part is my biggest headache by implement 
letsencrypt (without mod_md) for hundrets of existing websites


it also would solve the chicken-egg-problem (again, without mod_md) that 
you first need the http-host working for the well-known verfication file 
and the path of the certificate could be easily pre-configured in the 
way of my example, just warn insteda a fatal error on reload when the 
certfile don't exist




 ServerName corecms.example.com
 DocumentRoot "/www/corecms.example.com"
 
  SSLEngine On
  SSLUseStapling Off
  SSLCertificateFile "conf/ssl/corecms.pem"
 
 
  php_admin_value open_basedir "/www/corecms.example.com"
  php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
 




 ServerName corecms.example.com
 DocumentRoot "/www/corecms.example.com"
 
  php_admin_value open_basedir "/www/corecms.example.com"
  php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
 



 ServerName corecms.example.com
 DocumentRoot "/www/corecms.example.com"
 SSLEngine On
 SSLUseStapling Off
 SSLCertificateFile "conf/ssl/corecms.pem"
 
  php_admin_value open_basedir "/www/corecms.example.com"
  php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
 

Re: Listen 443 https

[Stefan Eissing]

> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr :
> 
> Let's break it down and consider the implications of Listen...
> 
> On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
>  wrote:
>> Now that mod_md has landed in trunk, I am looking at more ways
>> to simplify a SSL configuration. Looking at the Listen directive,
>> it has an optional 2nd protocol parameter.
>> 
>> Would it be unreasonable to assume that a
>>Listen NNN https
>> 
>> means that "SSLEngine on" should be the default in all
>>
>>   ServerName xxx.yyy
>>   ...
>>
>> 
>> sections?
> 
> Firstly, we have well understood protocols definitions, so there
> are several shorthand flavors that could be introduced;
> 
>  Listen https
> 
> has a very plain and obvious meaning. Thus, so would these;
> 
>  Listen https://192.168.1.1
>  Listen https://xxx.yyy
>  Listen https://192.168.1.1:8443
>  Listen https://xxx.yyy:8443

I like this.

>> Would we expect breakage by such a change?
> 
> I think that Listen *:NNN is maybe the most common misconfiguration
> in general, on multihomed boxes (and Listen myhost:NNN not answering
> the call of localhost being a most common point of confusion :)
> 
> Your mention of ServerName is a little misleading. A corresponding
> virtual host isn't needed at all. And mod_ssl handshake is always
> controlled by the physical vhost (first matching named vhost, name
> being ignored), which makes this a little more confusing to users.

If understand you correctly, if the first matching (document order?)
vhost for the address:port (with wildcards) has "SSLEngine on", we
get mod_ssl engaged. If not, we try to parse a http: request?

Hmmm. That...could be improved.

> What leads me to wonder, even with some easier-to-read Listen
> directives, if the user wouldn't be confused by omission of the
> SSLEngine on, when their other SSL directives aren't behaving
> as expected. Because they placed them in the wrong ,
> obviously. But not obvious to them. The need to toggle SSLEngine
> may be an unintended usability feature.

I think my gut feeling tells me that "SSLEngine on|off" is more
part of the port and of the vhost. The vhost may add other SSL*
configurations, once SNI has identified the correct one. But for
a certain port (address:port) we either do TLS or not.

So, I was looking for ways to express that and Listen seems a good start.

>> What about name-based virtual hosts that apply to _all_
>> addresses and ports? E.g. something like:
>>
>>   ServerName xxx.yyy
>>   ...
>>   
>>  Redirect permanent "/" "https://xxx.yyy/;
>>   
>>   ...
>>
>> 
>> Do you find that ugly/feasible/desirable?
> 
> Definitely not a fan. Why isn't this rewrite simply given in the system
> global config?
> 
> A connection, later the request, maps to only VirtualHost declaration.
> That block would never fire if there is a matching VirtualHost. OTOH,
> if no VirtualHost matches, then we use the global host anyways.

I now tend to agree that it probably only adds to confusion rather than simpify 
things. 

-Stefan

Re: Listen 443 https

[William A Rowe Jr]

Let's break it down and consider the implications of Listen...

On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
 wrote:
> Now that mod_md has landed in trunk, I am looking at more ways
> to simplify a SSL configuration. Looking at the Listen directive,
> it has an optional 2nd protocol parameter.
>
> Would it be unreasonable to assume that a
> Listen NNN https
>
> means that "SSLEngine on" should be the default in all
> 
>ServerName xxx.yyy
>...
> 
>
> sections?

Firstly, we have well understood protocols definitions, so there
are several shorthand flavors that could be introduced;

  Listen https

has a very plain and obvious meaning. Thus, so would these;

  Listen https://192.168.1.1
  Listen https://xxx.yyy
  Listen https://192.168.1.1:8443
  Listen https://xxx.yyy:8443

> Would we expect breakage by such a change?

I think that Listen *:NNN is maybe the most common misconfiguration
in general, on multihomed boxes (and Listen myhost:NNN not answering
the call of localhost being a most common point of confusion :)

Your mention of ServerName is a little misleading. A corresponding
virtual host isn't needed at all. And mod_ssl handshake is always
controlled by the physical vhost (first matching named vhost, name
being ignored), which makes this a little more confusing to users.

What leads me to wonder, even with some easier-to-read Listen
directives, if the user wouldn't be confused by omission of the
SSLEngine on, when their other SSL directives aren't behaving
as expected. Because they placed them in the wrong ,
obviously. But not obvious to them. The need to toggle SSLEngine
may be an unintended usability feature.


> What about name-based virtual hosts that apply to _all_
> addresses and ports? E.g. something like:
> 
>ServerName xxx.yyy
>...
>
>   Redirect permanent "/" "https://xxx.yyy/;
>
>...
> 
>
> Do you find that ugly/feasible/desirable?

Definitely not a fan. Why isn't this rewrite simply given in the system
global config?

A connection, later the request, maps to only VirtualHost declaration.
That block would never fire if there is a matching VirtualHost. OTOH,
if no VirtualHost matches, then we use the global host anyways.

Listen 443 https

[Stefan Eissing]

Now that mod_md has landed in trunk, I am looking at more ways 
to simplify a SSL configuration. Looking at the Listen directive,
it has an optional 2nd protocol parameter.

Would it be unreasonable to assume that a
Listen NNN https

means that "SSLEngine on" should be the default in all

   ServerName xxx.yyy
   ...


sections? Would we expect breakage by such a change?

What about name-based virtual hosts that apply to _all_ 
addresses and ports? E.g. something like:

   ServerName xxx.yyy
   ...
   
  Redirect permanent "/" "https://xxx.yyy/;
   
   ...


Do you find that ugly/feasible/desirable?

-Stefan