SSL with parallel support of two ports not working in statically compiled Apache2 binary

Question

I am observing the following issue:

Apache2 was compiled with the following flags:

./configure \
  --prefix=/usr \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --host=arm-cortexa9-linux-gnueabi \
  --build=i686-host-linux-gnu \
  --includedir=/usr/include/apache2 \
  --enable-ssl \
  --with-ssl \
  --enable-ssl-staticlib-deps \
  --enable-mods-static="headers rewrite gd log_config mime alias actions unixd access_compat authn_core authz_core cgi ssl http2" \
  --with-apr=/opt/PHYTEC_BSPs/PTXDist/platform-phyFLEX-i.MX6/sysroot-target/usr/bin/apr-1-config \
  --with-apr-util=/opt/PHYTEC_BSPs/PTXDist/platform-phyFLEX-i.MX6/sysroot-target/usr/bin/apu-1-config \
  BUILDCC=/usr/bin/gcc \
  --with-mpm=prefork 

This leads to a binary that has the following modules compiled in

Compiled in modules:
  core.c
  mod_authn_core.c
  mod_authz_core.c
  mod_access_compat.c
  mod_so.c
  http_core.c
  mod_mime.c
  mod_log_config.c
  mod_headers.c
  mod_ssl.c
  mod_http2.c
  prefork.c
  mod_unixd.c
  mod_cgi.c
  mod_actions.c
  mod_alias.c
  mod_rewrite.c

The ports.conf enables listening on port 443 and 80:

Listen 80

<IfModule ssl_module>
    Listen 443
</IfModule>

The simplest configuration for a site is the following:

<VirtualHost *:443>
    <IfModule ssl_module>
      SSLEngine On
       SSLCertificateFile /etc/ssl/certs/cert.crt
       SSLCertificateKeyFile /etc/ssl/private/key.pem
    </IfModule>
</VirtualHost>

We will use the second port 80 for an automated redirect to the https page. For the problem at hand the corresponding VirtualHost is not necessary.

Actually a request to the https page ( https://192.168.2.3:443 ) is working if Listen 80 is removed from ports.conf . That means that the ssl support is properly compiled into the binary. If both Listen directives are present in the ports.conf the request to the https page ( https://192.168.2.3:443 ) remains without a response. Not even an ERR_* response.

Several different searches regarding ports, apache2, ssl did not help to narrow the problem down. The same configuration with a standard apache2 binary works flawless. Increasing the LogLevel to debug gives for both afforementioned scenarios the same output:

[ssl:info] [pid 1583025418028449792] [client 192.168.2.82:51478] AH01964: Connection to child 0 established (server localhost:443)
[ssl:debug] [pid 9122084304870461440] ssl_engine_kernel.c(2143): [client 192.168.2.82:51478] AH02645: Server name not provided via TLS extension (using default/first virtual host)
[ssl:debug] [pid 9122084442309416064] ssl_engine_kernel.c(2143): [client 192.168.2.82:51478] AH02645: Server name not provided via TLS extension (using default/first virtual host)
[core:debug] [pid 4294967296] protocol.c(1893): [client 192.168.2.82:51478] AH03155: select protocol from , choices=h2,http/1.1 for server localhost
[ssl:debug] [pid 7159351466806950200] ssl_engine_kernel.c(2042): [client 192.168.2.82:51478] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[ssl:debug] [pid 3905800881399477553] ssl_engine_kernel.c(366): [client 192.168.2.82:51478] AH02034: Initial (No.1) HTTPS request received for child 0 (server localhost:443)
[authz_core:debug] [pid 3358932565584236] mod_authz_core.c(809): [client 192.168.2.82:51478] AH01626: authorization result of Require all denied: denied
[authz_core:debug] [pid 30064771072] mod_authz_core.c(809): [client 192.168.2.82:51478] AH01626: authorization result of <RequireAny>: denied
[authz_core:error] [pid 30064771072] [client 192.168.2.82:51478] AH01630: client denied by server configuration: /var/www/
[ssl:debug] [pid 2113123909637] ssl_engine_io.c(1033): [client 192.168.2.82:51478] AH02001: Connection closed to child 0 with standard shutdown (server localhost:443)

Has anybody an idea if maybe a module should be added to the binary? Any help would be very much appreciated.

Answer 1

set ac_cv_o_nonblock_inherited=no in configuration options of APR Package.

Cross compiling causes multiple Listen directives to not work properly