[users@httpd] Apache 2.4.23 and h2spec

[Michael Johnson]

Hi there,I am trying to use h2spec (https://github.com/summerwind/h2spec) with apache 2.4.23 but pretty much at the beginning it stops the test with following error:3.5. HTTP/2 Connection Preface    ✓ Sends invalid connection preface  4.2. Frame Size  Sends large size frame that exceeds the SETTINGS_MAX_FRAME_SIZE    ERROR: HTTP/2 settings negotiation failedI tried it with ubuntu 16.04 and 14.04 but the error stays the same.To make sure that h2spec works properly, I tested it with other Http/2 webservers (nghttp2 and nginx) and the tests finished successfully.In the error log I found this:--[Thu Sep 08 16:57:55.283025 2016] [http2:debug] [pid 14649] mod_http2.c(101): AH03089: initializing post config dry run[Thu Sep 08 16:57:55.303927 2016] [http2:info] [pid 14650] AH03090: mod_http2 (v1.5.11, feats=CHPRIO+SHA256, nghttp2 1.12.0-DEV), initializing...[Thu Sep 08 16:57:55.325803 2016] [mpm_prefork:notice] [pid 14650] AH00163: Apache/2.4.23 (Ubuntu) OpenSSL/1.0.2h PHP/5.5.9-1ubuntu4.19 configured -- resuming normal operations[Thu Sep 08 16:57:55.325867 2016] [core:notice] [pid 14650] AH00094: Command line: '/usr/sbin/apache2'[Thu Sep 08 16:57:55.325875 2016] [core:debug] [pid 14650] log.c(1546): AH02639: Using SO_REUSEPORT: yes (1)[Thu Sep 08 16:58:09.226055 2016] [core:debug] [pid 14654] protocol.c(1893): [client 10.0.0.4:47316] AH03155: select protocol from h2, choices=h2-14,h2-15,h2-16,h2 for server localhost[Thu Sep 08 16:58:09.226091 2016] [core:debug] [pid 14654] protocol.c(1938): [client 10.0.0.4:47316] AH03156: select protocol, proposals=h2 preferences=h2 configured=h2[Thu Sep 08 16:58:09.226107 2016] [core:debug] [pid 14654] protocol.c(1956): [client 10.0.0.4:47316] AH03157: selected protocol=h2[Thu Sep 08 16:58:09.231781 2016] [http2:debug] [pid 14654] h2_session.c(956): [client 10.0.0.4:47316] AH03200: h2_session(1) created, max_streams=100, stream_mem=65536, workers_limit=4, workers_max=1, push_diary(type=1,N=256)[Thu Sep 08 16:58:09.231879 2016] [http2:debug] [pid 14654] h2_session.c(1058): [client 10.0.0.4:47316] AH03201: h2_session(1): start, INITIAL_WINDOW_SIZE=65535, MAX_CONCURRENT_STREAMS=100[Thu Sep 08 16:58:09.231907 2016] [http2:debug] [pid 14654] h2_session.c(2081): [client 10.0.0.4:47316] AH03079: h2_session(1): started on localhost:443[Thu Sep 08 16:58:09.231923 2016] [http2:debug] [pid 14654] h2_session.c(1703): [client 10.0.0.4:47316] AH03078: h2_session(1): transit [INIT] -- init --> [BUSY][Thu Sep 08 16:58:09.232044 2016] [http2:debug] [pid 14654] h2_session.c(1806): [client 10.0.0.4:47316] AH03402: h2_session(1): proto error -> shutdown[Thu Sep 08 16:58:09.232083 2016] [http2:debug] [pid 14654] h2_session.c(655): [client 10.0.0.4:47316] AH03068: h2_session(1): sent FRAME[SETTINGS[length=6, stream=0]], frames=0/0 (r/s)[Thu Sep 08 16:58:09.232116 2016] [http2:debug] [pid 14654] h2_session.c(655): [client 10.0.0.4:47316] AH03068: h2_session(1): sent FRAME[WINDOW_UPDATE[stream=0, incr=2147418112]], frames=0/1 (r/s)[Thu Sep 08 16:58:09.232135 2016] [http2:debug] [pid 14654] h2_session.c(655): [client 10.0.0.4:47316] AH03068: h2_session(1): sent FRAME[GOAWAY[error=-903, reason='Received bad client magic byte string', last_stream=0]], frames=0/2 (r/s)[Thu Sep 08 16:58:09.232242 2016] [http2:debug] [pid 14654] h2_session.c(752): [client 10.0.0.4:47316] AH03069: session(1): sent GOAWAY, err=-903, msg=Received bad client magic byte string[Thu Sep 08 16:58:09.232263 2016] [http2:debug] [pid 14654] h2_session.c(1703): [client 10.0.0.4:47316] AH03078: h2_session(1): transit [BUSY] -- local goaway --> [LSHUTDOWN][Thu Sep 08 16:58:09.232292 2016] [http2:debug] [pid 14654] h2_session.c(1595): (20014)Internal error (specific information not available): [client 10.0.0.4:47316] AH02950: h2_session(1): error reading, terminating[Thu Sep 08 16:58:09.232308 2016] [http2:debug] [pid 14654] h2_session.c(1703): [client 10.0.0.4:47316] AH03078: h2_session(1): transit [LSHUTDOWN] -- conn error --> [DONE][Thu Sep 08 16:58:09.232397 2016] [http2:debug] [pid 14654] h2_conn.c(215): (70014)End of file found: [client 10.0.0.4:47316] AH03045: h2_session(1): process, closing conn[Thu Sep 08 16:58:09.234124 2016] [core:debug] [pid 14653] protocol.c(1893): [client 10.0.0.4:47318] AH03155: select protocol from h2, choices=h2-14,h2-15,h2-16,h2 for server localhost[Thu Sep 08 16:58:09.234150 2016] [core:debug] [pid 14653] protocol.c(1938): [client 10.0.0.4:47318] AH03156: select protocol, proposals=h2 preferences=h2 configured=h2[Thu Sep 08 16:58:09.234164 2016] [core:debug] [pid 14653] protocol.c(1956): [client 10.0.0.4:47318] AH03157: selected protocol=h2[Thu Sep 08 16:58:09.236972 2016] [http2:debug] [pid 14653] h2_session.c(956): [client 10.0.0.4:47318] AH03200: h2_session(0) created, max_streams=100, stream_mem=65536, workers_limit=4, workers_max=1, push_diary(type=1,N=256)[Thu Sep 08 16:58:09.236990 2016] [http2:debug] [pid 14653] 

Re: [users@httpd] SNI SSL per domain?

[Felipe Gasper]

> On 8 Sep 2016, at 2:26 AM, Marat Khalili  wrote:
> 
>> It works beautifully and requires no restart of the server to 
>> add/remove/update certificates.
> I am not an Apache developer, but it does not sound like a difficult patch. 
> Although I'd cache certificates in memory, not check filesystem every time. 
> It is not hard to type service apache2 reload when you need it.
> 

Oh yes, definitely cache the certificates. :)

My sense is that many admins of large Apache installs prefer to minimize server 
restarts. It also simplifies the automation a bit not to need the restart.

-FG

> --
> 
> With Best Regards,
> Marat Khalili
> 
> On 08/09/16 06:04, Felipe Gasper wrote:
>>> On 7 Sep 2016, at 9:43 PM, Marat Khalili  wrote:
>>> 
>>> Did you consider having two instances of Apache: one for handling SSL with 
>>> vhost per certificate, and one for actual web sites with vhost per site? 
>>> First one will proxy requests to the second. Some people do it this way for 
>>> performance reasons, but it lets you be more flexible with certificates too.
>>> 
>> I never considered this, but I would think the memory consumption of two 
>> Apache instances would be undesirable. Worth investigating, though. HAProxy 
>> may also work toward this end.
>> 
 All the same, would it not make sense to decouple the SNI logic from the 
 vhosts? Just thinking at a conceptual level, there seems no particular 
 reason why these entities are combined in the configuration.
>>> Except for the fact that in 99.999% of use cases SNI determines vhost and 
>>> non-canonical domains are just redirects.
>>> 
>> What do you mean by “non-canonical domain”?
>> 
>> Do you mean something in the ServerAlias? That seems more an implementation 
>> detail of Apache’s particular configuration format; both conceptually and in 
>> practice all domains that point to a vhost are coequal in status, right?
>> 
>>> OTOH, since every certificate contains domain names it is valid for, why 
>>> cannot Apache pick certificate from a list or directory automatically 
>>> before even considering virtualhosts? Isn't certificate-domain relationship 
>>> in Apache configuration redundant (in most cases) and error-prone?
>> ^^^ Ding, ding, ding, ding, ding!!! :)
>> 
>> This is how we’ve set up our own SNI-capable daemons: they load the cert 
>> chain and key from files named for the relevant domain. The service knows 
>> where the certs and key are as a function of the domain name; there’s no 
>> configuration besides filesystem setup. It works beautifully and requires no 
>> restart of the server to add/remove/update certificates.
>> 
>> -FG
>> 
>> 
>> 
>>> -- 
>>> 
>>> With Best Regards,
>>> Marat Khalili
>>> 
>>> On September 8, 2016 3:03:35 AM GMT+03:00, Felipe Gasper 
>>>  wrote:
>>> Reviving this thread …
>>> 
>>> This would mean that every vhost will needs its own common.conf file, 
>>> which, on a server with thousands of vhosts, will make for expensive loads 
>>> of the configuration file.
>>> 
>>> mod_macro in 2.4 is another route we may explore, but we have some really 
>>> complex vhost templating logic that would be difficult to port.
>>> 
>>> All the same, would it not make sense to decouple the SNI logic from the 
>>> vhosts? Just thinking at a conceptual level, there seems no particular 
>>> reason why these entities are combined in the configuration.
>>> 
>>> Are there plugin controls that would facilitate control of the SSL 
>>> certificate sent to the browser? Or would a change like this really need to 
>>> be in Apache itself?
>>> 
>>> Thank you!
>>> 
>>> -FG
>>> 
>>>  On 3 Feb 2016, at 5:54 AM, Stefan Eissing  
>>> wrote:
>>>common.conf:
>>>>>  ...
>>>  ...
>>>  ---
>>>
>>>   ServerName foo.tld
>>> SSLCertificateFile foo.pem
>>> Include common.con
>>>  
>>>  
>>>   ServerName bar.tld
>>> SSLCertificateFile bar.pem
>>> Include common.con
>>>  
>>>  Am 03.02.2016 um 11:45 schrieb Felipe Gasper :
>>>What if I have a vhost with:
>>>ServerName foo.tld
>>>  ServerAlias bar.tld
>>>… but I have two separate SSL certificates for these domains? Is there 
>>> any way to accommodate this without either splitting the domains onto 
>>> separate vhosts or buying a new certificate that covers both domains?
>>>-FG
>>>On 3 Feb 2016 12:26 AM, William A Rowe Jr wrote:
>>>  Sounds like you have mis-structured the config.  Per servername - each
>>>  can and should have its own cert and will be selected via SNI.  If there
>>>  are subadmins beneath each vhost section #include those snippets and
>>>  they all still fall within the given host name.
>>>On Feb 1, 2016 11:21 AM, "Felipe Gasper" >>  > wrote:
>>>  On 1 Feb 2016 12:16 PM, Oscar Knorn wrote:
>>>  On 2016/02/01 Felipe Gasper wrote:
>>>  

Re: [users@httpd] SNI SSL per domain?

[Marat Khalili]

What do you mean by “non-canonical domain”? Do you mean something in the 
ServerAlias?
I mean canonical from user/marketing point of view. These days if you 
have, say, www.theregister.co.uk, theregister.co.uk, 
www.theregister.com, theregister.com etc., usually only the first one 
contains real site, and all the rest just return 301 Moved Permanently. 
Because of caching, cookie/javascript domains etc.



It works beautifully and requires no restart of the server to add/remove/update 
certificates.
I am not an Apache developer, but it does not sound like a difficult 
patch. Although I'd cache certificates in memory, not check filesystem 
every time. It is not hard to type service apache2 reload when you need it.


--

With Best Regards,
Marat Khalili

On 08/09/16 06:04, Felipe Gasper wrote:

On 7 Sep 2016, at 9:43 PM, Marat Khalili  wrote:

Did you consider having two instances of Apache: one for handling SSL with 
vhost per certificate, and one for actual web sites with vhost per site? First 
one will proxy requests to the second. Some people do it this way for 
performance reasons, but it lets you be more flexible with certificates too.


I never considered this, but I would think the memory consumption of two Apache 
instances would be undesirable. Worth investigating, though. HAProxy may also 
work toward this end.


All the same, would it not make sense to decouple the SNI logic from the 
vhosts? Just thinking at a conceptual level, there seems no particular reason 
why these entities are combined in the configuration.

Except for the fact that in 99.999% of use cases SNI determines vhost and 
non-canonical domains are just redirects.


What do you mean by “non-canonical domain”?

Do you mean something in the ServerAlias? That seems more an implementation 
detail of Apache’s particular configuration format; both conceptually and in 
practice all domains that point to a vhost are coequal in status, right?


OTOH, since every certificate contains domain names it is valid for, why cannot 
Apache pick certificate from a list or directory automatically before even 
considering virtualhosts? Isn't certificate-domain relationship in Apache 
configuration redundant (in most cases) and error-prone?

^^^ Ding, ding, ding, ding, ding!!! :)

This is how we’ve set up our own SNI-capable daemons: they load the cert chain 
and key from files named for the relevant domain. The service knows where the 
certs and key are as a function of the domain name; there’s no configuration 
besides filesystem setup. It works beautifully and requires no restart of the 
server to add/remove/update certificates.

-FG




--

With Best Regards,
Marat Khalili

On September 8, 2016 3:03:35 AM GMT+03:00, Felipe Gasper 
 wrote:
Reviving this thread …

This would mean that every vhost will needs its own common.conf file, which, on 
a server with thousands of vhosts, will make for expensive loads of the 
configuration file.

mod_macro in 2.4 is another route we may explore, but we have some really 
complex vhost templating logic that would be difficult to port.

All the same, would it not make sense to decouple the SNI logic from the 
vhosts? Just thinking at a conceptual level, there seems no particular reason 
why these entities are combined in the configuration.

Are there plugin controls that would facilitate control of the SSL certificate 
sent to the browser? Or would a change like this really need to be in Apache 
itself?

Thank you!

-FG

  On 3 Feb 2016, at 5:54 AM, Stefan Eissing  
wrote:
  
  common.conf:
  
  
  ...
  ...
  ---
  
  

   ServerName foo.tld
  
   SSLCertificateFile foo.pem
  
   Include common.con

  
  
   ServerName bar.tld
  
   SSLCertificateFile bar.pem
  
   Include common.con

  
  
  
  Am 03.02.2016 um 11:45 schrieb Felipe Gasper :
  
  What if I have a vhost with:
  
  ServerName foo.tld

  ServerAlias bar.tld
  
  … but I have two separate SSL certificates for these domains? Is there any way to accommodate this without either splitting the domains onto separate vhosts or buying a new certificate that covers both domains?
  
  -FG
  
  On 3 Feb 2016 12:26 AM, William A Rowe Jr wrote:

  Sounds like you have mis-structured the config.  Per servername - each
  can and should have its own cert and will be selected via SNI.  If there
  are subadmins beneath each vhost section #include those snippets and
  they all still fall within the given host name.
  
  On Feb 1, 2016 11:21 AM, "Felipe Gasper" > wrote:
  
On 1 Feb 2016 12:16 PM, Oscar Knorn wrote:
  
On 2016/02/01 Felipe Gasper wrote:
  
Hello,
  
  Is it possible to do SNI SSL per domain rather than

per vhost? If
not, is there a feature request in for this?
  
  Thank you!
  
-Felipe