Re: [VOTE] Release httpd-2.4.49-rc1 as httpd-2.4.49

[Bernard Spil]

ERR_GET_FUNC was blocking this for me on FreeBSD 13 with OpenSSL 3.0 from ports.
Warning in build logs, but failure at runtime

ssl_engine_init.c:1375:22: warning: implicit declaration of function
'ERR_GET_FUNC' is invalid in C99 [-Wimplicit-function-declaration]
 && (ERR_GET_FUNC(ERR_peek_last_error())

and the fix is https://svn.apache.org/viewvc?view=revision=1891138
as noted above.

All seems well with that r1891138 fix and OpenSSL 3.0.0 on FreeBSD
13.0-p4 amd64 / clang 11.0.1

[Sun Sep 12 11:48:50.820341 2021] [mpm_event:notice] [pid 80970:tid
34372395008] AH00489: Apache/2.4.49 (FreeBSD) OpenSSL/3.0.0 configured
-- resuming normal operations

On Sun, Sep 12, 2021 at 7:02 AM Dennis Clarke  wrote:
>
> On 9/12/21 02:36, Dennis Clarke wrote:
> > On 9/10/21 11:23, ste...@eissing.org wrote:
> >> Hi, all;
> >>Please find below the proposed release tarball and signatures:
> >> https://dist.apache.org/repos/dist/dev/httpd/
> >>
> >> I would like to call a VOTE over the next few days to release
> >> this candidate tarball httpd-2.4.49-rc1 as 2.4.49:
> >> [ ] +1: It's not just good, it's good enough!
> >> [ ] +0: Let's have a talk.
> >> [ ] -1: There's trouble in paradise. Here's what's wrong.
> >>
>
> * * * NOTE -1  There's trouble in paradise. Here's what's wrong. * * *
>
>
> Reply to self here ...
>
> I discovered in the OpenSSL 3.0.0 release notes:
>
>
>  * The ERR_GET_FUNC() function was removed.  With the loss
>of meaningful function codes, this function can only
>cause problems for calling applications.
>
>Paul Dale
>
>
> Thus ERR_GET_FUNC() was removed, but it looks like httpd is still
> trying to use it, which explains the error I'm seeing.  What I see
> is :
>
>
>
> beta #
> beta # /opt/bw/bin/httpd -V
> Server version: Apache/2.4.49 (Unix)
> Server built:   Sep 12 2021 03:54:11
> Server's Module Magic Number: 20120211:116
> Server loaded:  APR 1.7.0, APR-UTIL 1.6.1
> Compiled using: APR 1.7.0, APR-UTIL 1.6.1
> Architecture:   64-bit
> Server MPM: event
>   threaded: yes (fixed thread count)
> forked: yes (variable process count)
> Server compiled with
>  -D APR_HAS_SENDFILE
>  -D APR_HAS_MMAP
>  -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>  -D APR_USE_PROC_PTHREAD_SERIALIZE
>  -D APR_USE_PTHREAD_SERIALIZE
>  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>  -D APR_HAS_OTHER_CHILD
>  -D AP_HAVE_RELIABLE_PIPED_LOGS
>  -D DYNAMIC_MODULE_LIMIT=256
>  -D HTTPD_ROOT="/opt/bw"
>  -D SUEXEC_BIN="/opt/bw/bin/suexec"
>  -D DEFAULT_PIDLOG="var/apache/httpd/logs/httpd.pid"
>  -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>  -D DEFAULT_ERRORLOG="logs/error_log"
>  -D AP_TYPES_CONFIG_FILE="etc/apache/httpd/mime.types"
>  -D SERVER_CONFIG_FILE="etc/apache/httpd/httpd.conf"
> beta #
> beta #
> beta # /opt/bw/bin/apachectl start
> httpd: Syntax error on line 75 of /opt/bw/etc/apache/httpd/httpd.conf:
> Cannot load modules/mod_ssl.so into server: ld.so.1: httpd: fatal:
> relocation error: file /opt/bw/modules/mod_ssl.so: symbol ERR_GET_FUNC:
> referenced symbol not found
> beta #
>
> We see https://github.com/apache/httpd/pull/258 exists however I am
> only now looking at how to patch 2.4.49 based on those changes in
> trunk.
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional

Re: TLSv1.3 supprt for 2.4.x?

[Bernard Spil]

Just tested this branch with OpenSSL 1.1.1p9. Haven't found issues yet.

> Listen 42002 https
> SSLHonorCipherOrder on
> SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Server error.log
> AH00489: Apache/2.4.35-dev (FreeBSD) OpenSSL/1.1.1-pre9 configured -- 
> resuming normal operations

client `openssl s_client -connect localhost:42002`
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

I like the default server cipher selection!
On Wed, Sep 5, 2018 at 1:36 PM Stefan Eissing
 wrote:
>
> A member of the OpenSSL project gave me a "go ahead" and we now have branch:
>
> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x
>
> as a copy of 2.4.x with 
> 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946
>  merged in. If was not a clean merge as some feature from trunk are not 
> present in 2.4.x, so peer review/test is definitely desired.
>
> I put a backport proposal into 2.4.x/STATUS
>
> Cheers, Stefan
>
>
> > Am 03.09.2018 um 15:45 schrieb Jim Jagielski :
> >
> > +1! for backporting
> >
> >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing  
> >> wrote:
> >>
> >> Dear SSL care takers and stake holders,
> >>
> >> trunk has TLSv1.3 support for some time. I just now changed the 'all' 
> >> SSLProtocol selection, so that it does not include TLSv1.3. This means 
> >> that in order to enable it, admins must add an explicit '+TLSv1.3' to 
> >> their config (same for SSLProxyProtocl of course).
> >>
> >> With this, the added support is really an opt-in and we could backport it 
> >> to 2.4.x, if we want. We have been burned with backporting SSL features 
> >> just recently (by my mistake), so I would understand that people feel a 
> >> bit reluctant here. On the other hand, there is certainly interest by 
> >> users.
> >>
> >> So, what is your opinion?
> >>
> >> Cheers,
> >>
> >> Stefan
> >>
> >> PS. There are some combinations in renegotiation/client certs that are not 
> >> tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or 
> >> at least with a heavy caveat for those setups. But I see no issue with 
> >> using it for plain-vanilla https: setups.
> >
>

Re: TLSv1.3 supprt for 2.4.x?

[Bernard Spil]

Hi All,

I've received a patch from the LibreSSL devs via mail. That resolves
the renegotiation issue. Patch is awaiting review, I expect it to land
in the LibreSSL repo soon.

Cheers, Bernard.
On Mon, Sep 3, 2018 at 1:36 PM Stefan Eissing
 wrote:
>
> Speaking of SSL and rare renegotiation setups: Bernard and me are suspecting 
> that
> libressl has issues here for quite some time. At least it looks that way:
>
> https://github.com/libressl-portable/portable/issues/443
>
> Just FYI in case someone encounters such things.
>
> > Am 03.09.2018 um 13:32 schrieb Stefan Eissing 
> > :
> >
> >
> >
> >> Am 03.09.2018 um 13:19 schrieb Joe Orton :
> >>
> >> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote:
> >>> Dear SSL care takers and stake holders,
> >>>
> >>> trunk has TLSv1.3 support for some time. I just now changed the 'all' 
> >>> SSLProtocol selection, so that it does not include TLSv1.3. This means 
> >>> that in order to enable it, admins must add an explicit '+TLSv1.3' to 
> >>> their config (same for SSLProxyProtocl of course).
> >>>
> >>> With this, the added support is really an opt-in and we could backport it 
> >>> to 2.4.x, if we want. We have been burned with backporting SSL features 
> >>> just recently (by my mistake), so I would understand that people feel a 
> >>> bit reluctant here. On the other hand, there is certainly interest by 
> >>> users.
> >>>
> >>> So, what is your opinion?
> >>
> >> Yes, I just worked on a backport of that set for Fedora, so I'm on board
> >> for pushing & testing that in 2.4.x.  Possibly warrants a branch to work
> >> through the merge?
> >
> > We could do that. The patch, right now, is not that large, I think, but
> > a branch does not hurt.
> >
> >>> PS. There are some combinations in renegotiation/client certs that are
> >>> not tested well. Therefore, '+TLSv1.3' should be tagged as
> >>> 'experimental' or at least with a heavy caveat for those setups. But I
> >>> see no issue with using it for plain-vanilla https: setups.
> >>
> >> AIUI the various bits of new API added for TLS/1.3 are not necessarily
> >> stable until there is a final OpenSSL 1.1.1 release, so maybe we should
> >> wait for that first?
> >
> > I think they (or at least the parts we use) have been stable since pre3 in
> > spring. There have been fixes under the hood in timing of callbacks, AFAIK.
> > Since none of these are in any public part of httpd - apart from the
> > protocol config which we alaways be there - I think we could broaden the
> > test audience without much risk.
> >
> >> IMO there is no problem with supporting it by default (not needing
> >> explicit +TLSv1.3) in 2.4.  Since "bleeding edge OpenSSL" is needed to
> >> enable it at build time, this isn't going to break production users on
> >> current systems.
> >
> > Interesting. If that is consensus, I'd revert my change from earlier today.
> >
> > Cheers, Stefan
> >
> >> Regards, Joe
>

Re: TLSv1.3

[Bernard Spil]

Sorry William, didn't mean to disturb you. Just noticed some 2.5.1 and
2.5.1-dev strings appearing in commits.

Hope the project will roll another 2.5-dev soon. OpenSSL 1.1.1 is
nearing and a TLSv1.3 Apache server to go with that would be most
excellent!

Thanks! Bernard.

2018-04-10 17:35 GMT+02:00 William A Rowe Jr <wr...@rowe-clan.net>:
> On Sun, Apr 8, 2018 at 11:37 AM, Bernard Spil <br...@freebsd.org> wrote:
>> Hi Stefan, Mario,
>>
>> I saw that 2.5.1-dev was tagged, is another release coming some time soon?
>
> Worried me enough to look; http://svn.apache.org/repos/asf/httpd/httpd/tags/
>
> Thankfully nobody made such a tag. You'll note 2.5.0-alpha from a number
> of months ago; this was the first in development of new tag and release
> tooling, and as such it never made the cut. No word at this moment of the
> next 2.5.1-alpha attempt.

Re: TLSv1.3

[Bernard Spil]

Hi Stefan, Mario,

LibreSSL will hopefully add TLSv1.3 to the next version (ca. 6
months). So I can't test with that just yet.

Yes, it does work only with Firefox Nightly. :/ Google Chrome Beta
doesn't negotiate 1.3 either.
Using 1.1.1-pre4 at the moment.
The security.tls.version.max in about:config doesn't help... Neither
do the TLS settings in Chrome chrome://flags

To enable, you MUST add +TLSv1.3 to SSLProtocols? Otherwise it seems I
just get 1.2

I saw that 2.5.1-dev was tagged, is another release coming some time soon?

Cheers, Bernard.



2018-04-03 14:58 GMT+02:00 Stefan Eissing <stefan.eiss...@greenbytes.de>:
> Just added your patch for the latest libressl checks. Thanks!
>
> If I run that version against Firefox Nightly, it negotiates TLSv1.3. That
> is with OpenSSL 1.1.1-pre3; I have no test env for libressl.
>
> Chrome 65.0.3325.181 and FF 58.0.2 both do not on my MacOS desktop.
>
> Cheers,
>
> Stefan
>
>> Am 31.03.2018 um 22:42 schrieb Bernard Spil <br...@freebsd.org>:
>>
>> I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against
>> 1.1.1-pre3 from 2018-03-20 (AKA beta 1).
>>
>> If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3
>> connection. Qualys SSLLabs doesn't see the TLSv1.3 at all.
>> Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used
>> (SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519)
>> Negotiated connections default to x25519 which is not what I expect.
>>
>> From another host:
>>
>> % /usr/local/bin/openssl version
>> OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018
>>
>> % /usr/local/bin/openssl s_client -connect test.brnrd.eu:443
>> CONNECTED(0003)
>> depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
>> verify return:1
>> depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
>> verify return:1
>> depth=0 CN = test.brnrd.eu
>> verify return:1
>> 
>> ---
>> No client certificate CA names sent
>> Peer signing digest: SHA384
>> Peer signature type: ECDSA
>> Server Temp Key: X25519, 253 bits
>> ---
>> SSL handshake has read 2696 bytes and written 390 bytes
>> Verification: OK
>> ---
>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
>> Server public key is 384 bit
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> Early data was not sent
>> SSL-Session:
>>Protocol  : TLSv1.3
>>Cipher: TLS_AES_256_GCM_SHA384
>>Session-ID:
>>Session-ID-ctx:
>>Master-Key:
>>PSK identity: None
>>PSK identity hint: None
>>SRP username: None
>>Start Time: 1522528505
>>Timeout   : 7200 (sec)
>>Verify return code: 0 (ok)
>>Extended master secret: no
>> ---
>>
>> Firefox Nightly and Chrome don't negotiate TLSv1.3 either
>> Am I expecting things that I should not? (Entirely possible :D)
>>
>> Cheers, Bernard.
>>
>>
>>
>> 2018-03-29 16:11 GMT+02:00 Stefan Eissing <stefan.eiss...@greenbytes.de>:
>>> Done in r1827992.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>> Am 29.03.2018 um 12:56 schrieb Greg Stein <gst...@gmail.com>:
>>>>
>>>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing 
>>>> <stefan.eiss...@greenbytes.de> wrote:
>>>>> ...
>>>> That is the intention behind "SSLPolicy modern|intermediate|old" that 
>>>> configures the TLS stack according to the Mozilla server-side-tls 
>>>> recommendations. So, one does not have to mess with many directives to 
>>>> have a site with an "A" SSL Labs rating.
>>>>
>>>> Besides, except for data center setups, Apache will be used *only* with 
>>>> https: (and http: redirects to https:) very, very soon. That shifts the 
>>>> average expertise of an admin setting up a https: site.
>>>>
>>>> Back to TLSv1.3:
>>>>
>>>> I do not like to invent new config directives for a new TLS version 
>>>> either. The protocol on/off switch is now in "SSLProtocol" and that's 
>>>> where it should be. AFAIK, it's only the cipher list that needs special 
>>>> treatment (if one wants to override defaults or what SSLPolicy will do for 
>>>> it, once a recommendation is out).
>>>>
>>>> Gotcha.
>>>>
>>>>
>>>> So, looking at "SSLCipherSuite". It basically passes the string to the 
>>>> *SSL library. The manual page makes a big explanation and tables of 
>>>> ciphers, but the lists repeats basically how OpenSSL cipher strings work. 
>>>> It would be better to scrap that and replace it with a link to 
>>>> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl 
>>>> has nicer documentation)
>>>>
>>>> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to 
>>>> take more than 1 argument and look for optional prefixes to the suite 
>>>> strings given, so one could do
>>>>
>>>> Oooh! Yes. Looks great.
>>>>
>>>> +1
>>>>
>>>>> ...
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>>
>

Re: TLSv1.3

[Bernard Spil]

I'm running an Apache 2.5.1 snapshot from 2018-03-30 linked against
1.1.1-pre3 from 2018-03-20 (AKA beta 1).

If I connect to Apache with openssl 1.1.1 it makes a TLSv1.3
connection. Qualys SSLLabs doesn't see the TLSv1.3 at all.
Additionally, Apache doesn't start when SSLOpenSSLConfCmd is used
(SSLOpenSSLConfCmd groups secp521r1:secp384r1:x25519)
Negotiated connections default to x25519 which is not what I expect.

>From another host:

% /usr/local/bin/openssl version
OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018

% /usr/local/bin/openssl s_client -connect test.brnrd.eu:443
CONNECTED(0003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = test.brnrd.eu
verify return:1

---
No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2696 bytes and written 390 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1522528505
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---

Firefox Nightly and Chrome don't negotiate TLSv1.3 either
Am I expecting things that I should not? (Entirely possible :D)

Cheers, Bernard.



2018-03-29 16:11 GMT+02:00 Stefan Eissing :
> Done in r1827992.
>
> Cheers,
> Stefan
>
>> Am 29.03.2018 um 12:56 schrieb Greg Stein :
>>
>> On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing 
>>  wrote:
>> >...
>> That is the intention behind "SSLPolicy modern|intermediate|old" that 
>> configures the TLS stack according to the Mozilla server-side-tls 
>> recommendations. So, one does not have to mess with many directives to have 
>> a site with an "A" SSL Labs rating.
>>
>> Besides, except for data center setups, Apache will be used *only* with 
>> https: (and http: redirects to https:) very, very soon. That shifts the 
>> average expertise of an admin setting up a https: site.
>>
>> Back to TLSv1.3:
>>
>> I do not like to invent new config directives for a new TLS version either. 
>> The protocol on/off switch is now in "SSLProtocol" and that's where it 
>> should be. AFAIK, it's only the cipher list that needs special treatment (if 
>> one wants to override defaults or what SSLPolicy will do for it, once a 
>> recommendation is out).
>>
>> Gotcha.
>>
>>
>> So, looking at "SSLCipherSuite". It basically passes the string to the *SSL 
>> library. The manual page makes a big explanation and tables of ciphers, but 
>> the lists repeats basically how OpenSSL cipher strings work. It would be 
>> better to scrap that and replace it with a link to 
>> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl 
>> has nicer documentation)
>>
>> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to 
>> take more than 1 argument and look for optional prefixes to the suite 
>> strings given, so one could do
>>
>> Oooh! Yes. Looks great.
>>
>> +1
>>
>> >...
>>
>> Cheers,
>> -g
>>
>

Re: TLSv1.3

[Bernard Spil]

Hi Stefan,

Submitted a PR with changes required to build with LibreSSL 2.6 and
2.7 https://bz.apache.org/bugzilla/show_bug.cgi?id=62236

Cheers, Bernard.

2018-03-31 10:34 GMT+02:00 Bernard Spil <br...@freebsd.org>:
> Hi Stefan,
>
> Sure I'm here :D Have been the maintainer of the LibreSSL ports in
> FreeBSD for a good while and more recently joined the apache@ team.
>
> I'll let you know my results. I have an OpenSSL 1.1.1 port in the
> making so I can test all of this long before it lands in a release.
>
> Cheers, Bernard.
>
> 2018-03-28 17:49 GMT+02:00 Stefan Eissing <stefan.eiss...@greenbytes.de>:
>> Just added TLSv1.3 support in trunk. No fancy new early data features, just 
>> the basic.
>>
>> Open for discussion:
>>  - The Mozilla server-side-tls people are still thinking of what they will 
>> recommend, see:
>>
>> https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933
>>  - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will 
>> co-host 1.2 and 1.3
>>for some time, we need additional config directives, I think. Added 
>> "SSLCipherSuiteV1_3" and
>>am ashamed of the name.
>>  - The current handling of TLS versions that are not supported by the *SSL 
>> lib linked is not
>>super helpful. It more or less pretends that the version does not exist 
>> (unknown protocol),
>>but that is far from the truth. Shall we continue that or is this an 
>> opportunity to reconsider?
>>  - Should we allow the configuration of TLSv1_3 ciphers, even if the linked 
>> SSL does not support
>>it? This is different from SSLProtocol which of course needs to fail if 
>> it cannot enable the
>>version that is explicitly configured.
>>I think it is ok to take it into the config, even though it never 
>> activates.
>>
>> Cheers,
>>
>> Stefan
>>
>> PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if 
>> trunk compiles with it. I would not stop him.
>>

Re: TLSv1.3

[Bernard Spil]

Hi Stefan,

Sure I'm here :D Have been the maintainer of the LibreSSL ports in
FreeBSD for a good while and more recently joined the apache@ team.

I'll let you know my results. I have an OpenSSL 1.1.1 port in the
making so I can test all of this long before it lands in a release.

Cheers, Bernard.

2018-03-28 17:49 GMT+02:00 Stefan Eissing :
> Just added TLSv1.3 support in trunk. No fancy new early data features, just 
> the basic.
>
> Open for discussion:
>  - The Mozilla server-side-tls people are still thinking of what they will 
> recommend, see:
>
> https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933
>  - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will 
> co-host 1.2 and 1.3
>for some time, we need additional config directives, I think. Added 
> "SSLCipherSuiteV1_3" and
>am ashamed of the name.
>  - The current handling of TLS versions that are not supported by the *SSL 
> lib linked is not
>super helpful. It more or less pretends that the version does not exist 
> (unknown protocol),
>but that is far from the truth. Shall we continue that or is this an 
> opportunity to reconsider?
>  - Should we allow the configuration of TLSv1_3 ciphers, even if the linked 
> SSL does not support
>it? This is different from SSLProtocol which of course needs to fail if it 
> cannot enable the
>version that is explicitly configured.
>I think it is ok to take it into the config, even though it never 
> activates.
>
> Cheers,
>
> Stefan
>
> PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if 
> trunk compiles with it. I would not stop him.
>

Re: Poll: increase OpenSSL version requirement for trunk?

[Bernard Spil]

Naturally, there was something I saw in the archives I want to react
upon, even if not a vote...
I am also the maintainer of the OpenSSL (and LibreSSL) ports for
FreeBSD and am the author of many patches for LibreSSL, No-SSLv2,
No-SSLv3 for upstream projects.

I was searching for the rationale to provide a version of Apache which
is newer than what you get from your Operating System.

Obviously, there _is_ a need to have something newer than your OS,
e.g. Apache 2.4.6 on RHEL 7 is missing too many features.
When you are smart enough to be able to build your own Apache httpd,
are you not also smart enough to build all dependencies?
FWIW: I manage, to my dismay, 2 Apache front-end servers acting as
reverse proxy on RHEL7. When I ran into update problems with the
Base-OS I decided that I would just build the whole stack (from zlib
upwards) from the ground up.
If you would want mod_http2 you are in trouble on these old systems in
all cases, curl with HTTP/2 support? libnghttp2 in your repos?

Managing multiple versions of OpenSSL is already a head-ache. For 1.1
you need compat shims or lots of ifdefs, 1.1.1 (currently -pre2) will
only add to that...

I may be an odd-ball that I want to manage this kind of a setup but I
think that if you can build one application, you can build more. They
happily live separated into /usr/local on RHEL7...

Cheers, Bernard.

Introduction

[Bernard Spil]

Hi all,

Just subscribed to dev@.

I'm one of the team-members maintaining the Apache httpd ports, and
some modules, for the FreeBSD ports system.
https://wiki.freebsd.org/Apache

You may know me from previous interactions, mostly OpenSSL or
LetsEncrypt related, I believe my name even appears in the
changelog...

Cheers, Bernard Spil.