Apache httpd 2.4.43-4 with brotli support, TLS 1.3 final (RFC 8446) built against OpenSSL 1.1.1f with http2 and ALPN for Red Hat Enterprise Linux 7 and CentOS 7

Apache httpd 2.4.43-4 with brotli compression library from Google, TLS 1.3 Final (RFC 8446), http2 (HTTP/2) support for Red Hat Enterprise Linux and CentOS added to repository. Mod_ssl is built dynamically against OpenSSL 1.1.1g.

Links:

Since 2.4.33 we added brotli compression library. Since 2.4.35 release we start building Apache httpd against OpenSSL 1.1.1*. Since 2.4.37 release TLS 1.3 final version (not to be confused with any draft versions) is supported and enabled by default. Since 2.4.43-4 release we built OpenSSL as a separate package that installs to the separate directory (/opt/codeit/openssl111) and does not affects system libraries.

Please note that TLS 1.3 final version is supported in Chrome 70+ and Mozilla Firefox 63+.

brotli support is already included in base RPM file. All you need is to add filters like

AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript

Http2 Apache httpd module no longer supports prefork mpm from version 2.4.27. If you need http2 module, please disable prefork mpm and enable evemt mpm in /etc/httpd/conf.modules.d/00-mpm.conf. We already made this in 00-mpm.conf in our packages. If you are updating other vendor installation, please update this file.

We already included a minimum required SELinux policy into the package.

Feel free to use our CentOS/RHEL repository. Please also note that this package depends on apr-util 1.5.0+ and libnghttp, which you can found in EPEL repository. So, the easiest way to use our builds of Apache HTTPd is to add EPEL repository, if you still do not have it: yum install -y epel-release

34 thoughts on “Apache httpd 2.4.43-4 with brotli support, TLS 1.3 final (RFC 8446) built against OpenSSL 1.1.1f with http2 and ALPN for Red Hat Enterprise Linux 7 and CentOS 7”

  1. Dear Friends

    After installing 2.4.43-4, I have got an error with SSLCompression off after restarting httpd.service.

    I would be glad for your help.

    Thank you in advance for your help and support.

    Sincerely

      1. Dear Alexander

        …but in my last configuration I had line SSLCompression off, but when I try to restart httpd.service I have got an error:

        Setting Compression mode unsupported; not implemented by the SSL library

        In the older version of your 2.4.43 it was working fine with this line.

        Any idea how to resolve this?

        Sincerely

        1. Dear User,

          The purpose of our builds are the new standards: fast, modern and highly secure.
          We upgraded our builds to deliver OpenSSL library in a new dynamic way. Also, we disabled old and vulnerable features in it to additionally save traffic and memory.
          If you want to use these older deprecated features such as compression that leads to CRIME/BEAST vulnerabilities, please use the bundled Apache httpd server from CentOS team. Alternatively, you want to use our builds, please disable the compression:

          SSLCompression off

          As it is not supported in this build.

          1. Dear Alexander

            I think you may not understand me like I want to 🙂 I’m using your builds from day one. I just say, that I have already used: “SSLCompression off” in all my configuration files in vhosts. In this new build 2.4.43-4 this command “SSLCompression off” is no longer recognized, so to properly run my httpd.service I needed to delete this command “SSLCompression off” from my configuration files or just add hash “#” before it.

            The way you are trying to explain, to add “SSLCompression off” to my configuration files or ssl.conf is not working in this build.

            For a good understanding of each other. Your build is forced to use “SSLCompression off”, so there is no need to use this command anymore in any configuration files, because it’s always disabled = SSLCompression off? Is it correct?

            Thank you once more for your great work.

            Sincerely

          2. Dear User,

            Thanks for clarification, indeed I did not usnerstood you right.
            Yes, OpenSSL library that we ship, does not support SSL compression and if you use our library, SSL compression is always off, even you do not explicitly specify “SSLCompression off”.

  2. You should not have removed the SSLCompression option.
    It broke all our server when the update was done. And no warning. My Compression was always set to off.

    Very angry.

    But hey, I’m glad you are offering the repo free of charge.

    1. Actually we did not removed it.
      This is original Apache httpd behavior and we never had SSLCompression in sample config files and test hosts.
      Please always test your configuration after upgrade with

      httpd -t

      And restart your server only after that. Also you can have your own staging environment with similar configuration to be less angry.
      I think we will return compression support temporarily because of this regression.

      1. I use apachectl -t
        Is that why I get no return? the command is wrong?

        Since when does this config is invalid then? I had SSLCompression off since 2018

          1. Well, I tested httpd -t and it worked.
            Must be a change that happend sometime ago. Or when I switched repo for yours.

            This morning my system updated to this :
            httpd x86_64 2.4.43-4.codeit.el7 CodeIT 1.4 M
            httpd-filesystem noarch 2.4.43-4.codeit.el7 CodeIT 29 k
            httpd-tools x86_64 2.4.43-4.codeit.el7 CodeIT 94 k
            mod_ssl x86_64 1:2.4.43-4.codeit.el7 CodeIT 121 k
            Installing for dependencies:
            openssl111-libs x86_64 1.1.1g-1.codeit.el7 CodeIT 1.4 M

            Works OK right now. Won’t update manually. Thanks a lot for your help

  3. Our server is crashing almost daily after we upgraded to 2.4.43-4. A lot of mpm errors and zend memory issues. Basically overnight the ram usage goes from 20% to 100% and everything crashes. The only solution is to keep rebooting constantly. Just updated to 2.4.43-5. Do you know what was fixed in this version?

    1. Hello,

      In 2.4.43-5 we only rebuilt it with OpenSSL compression support to return SSLCompression back.

      Please check different mpms and php support for them. Usually they recommend to use php-fpm for event and preform mpms.

  4. Hi Alexander, thanks for quick reply and for suggestions which I’ve double-checked.
    However, your suggestion prompted me to look deeper and compare operational server with vanilla build. Turns out “which hostname” on a vanilla machine yields the “correct” /usr/bin/hostname.

    Traced to inconsistent PATH settings set in csh.login, in turn traced this to setup-2.8-x.rpm
    The misbehaving server would appear to have the CentOS “cr” repo enabled. This increments the base setup-2.8.71-10.el7.noarch to setup-2.8.71-11.el7.noarch.

    One change is a difference in /etc/csh.login which is defining a completely different PATH variable than system default – csh.login in later version has a setenv PATH statement which is placing /bin before /usr/bin and therefore resulting in the error reported.

    This is clearly self-inflicted on our test box, apologies for taking up your time, thanks for reviewing.

    For anyone else experiencing same issues, be very wary of the CentOS7 “cr” repo!

  5. Hi Alexander, the plot thickens…
    I’m going to backtrack on that. Seems the pathnames were a redherring. I have just built a virgin CentOS7 machine, applied the EPEL repo to it, carried out a full update then added the CodeIT CentOS7 repo.
    Here’s my results.

    It will quite happily install an earlier version of mod_ssl but not latest from CodeIT repo. To my little brain, it would appear something is actually amiss with mod_ssl package?
    Grateful for any ideas

    Cheers
    Rob

    [root@tdtst01 yum.repos.d]# echo $PATH
    /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
    [root@tdtst01 yum.repos.d]# which hostname
    /bin/hostname
    [root@tdtst01 yum.repos.d]# dnf install httpd mod_ssl
    Last metadata expiration check: 0:06:57 ago on Mon 27 Apr 2020 14:05:30 UTC.
    Dependencies resolved.

    Problem: cannot install the best candidate for the job
    – nothing provides /usr/bin/hostname needed by mod_ssl-1:2.4.43-6.codeit.el7.x86_64
    =====================================================================================================================================================
    Package Arch Version Repository Size
    =====================================================================================================================================================
    Installing:
    httpd x86_64 2.4.43-2.codeit.el7 CodeIT 1.4 M
    mod_ssl x86_64 1:2.4.43-2.codeit.el7 CodeIT 1.3 M
    Installing dependencies:
    brotli x86_64 1.0.7-5.el7 epel 318 k
    libnghttp2 x86_64 1.31.1-2.el7 epel 67 k
    sscg x86_64 2.6.1-1.el7 epel 60 k
    libtalloc x86_64 2.1.16-1.el7 cr 33 k
    libpath_utils x86_64 0.2.1-32.el7 base 28 k
    mailcap noarch 2.1.41-2.el7 base 31 k
    apr x86_64 1.7.0-2.el7 CodeIT 122 k
    apr-util x86_64 1.6.1-6.el7 CodeIT 98 k
    httpd-filesystem noarch 2.4.43-2.codeit.el7 CodeIT 27 k
    httpd-tools x86_64 2.4.43-2.codeit.el7 CodeIT 1.3 M
    mod_http2 x86_64 1.15.7-1.codeit CodeIT 208 k
    Skipping packages with broken dependencies:
    mod_ssl x86_64 1:2.4.43-6.codeit.el7 CodeIT 121 k

    Transaction Summary
    =====================================================================================================================================================
    Install 13 Packages
    Skip 1 Package

    Total download size: 5.0 M
    Installed size: 14 M
    Is this ok [y/N]:

    1. Hi Rob,

      Just try to update to the latest hostname package, as I suggested earlier.

      yum upgrade hostname

      hostname-3.13-3.el7_7.1.x86_64 from the Updates CentOS 7 repo should work fine for you.

  6. Hi Alexander,
    Once again this side bad, and for complete disclosure the issue is with YUM vs DNF.
    Turns out that on the test box yum had been swapped for dnf in the extras repo.
    Interestingly yum behaves where dnf does not. dnf DOES behave if wanting to install previous version of mod_ssl. I have never delved into rpm specifications, so cannot answer why one works and the other doesnt.

    yum install httpd mod_ssl

    –> Finished Dependency Resolution

    Dependencies Resolved

    =====================================================================================================================================================
    Package Arch Version Repository Size
    =====================================================================================================================================================
    Installing:
    httpd x86_64 2.4.43-6.codeit.el7 CodeIT 1.4 M
    mod_ssl x86_64 1:2.4.43-6.codeit.el7 CodeIT 121 k
    Installing for dependencies:
    apr x86_64 1.7.0-2.el7 CodeIT 122 k
    apr-util x86_64 1.6.1-6.el7 CodeIT 98 k
    brotli x86_64 1.0.7-5.el7 epel 318 k
    httpd-filesystem noarch 2.4.43-6.codeit.el7 CodeIT 29 k
    httpd-tools x86_64 2.4.43-6.codeit.el7 CodeIT 94 k
    libnghttp2 x86_64 1.31.1-2.el7 epel 67 k
    libpath_utils x86_64 0.2.1-32.el7 base 28 k
    libtalloc x86_64 2.1.16-1.el7 base 33 k
    mailcap noarch 2.1.41-2.el7 base 31 k
    mod_http2 x86_64 1.15.7-1.codeit CodeIT 208 k
    openssl111-libs x86_64 1.1.1g-2.codeit.el7 CodeIT 1.4 M
    sscg x86_64 2.6.1-1.el7 epel 60 k

    Transaction Summary
    =====================================================================================================================================================
    Install 2 Packages (+12 Dependent packages)

    # dnf install httpd mod_ssl
    Last metadata expiration check: 0:04:04 ago on Mon 27 Apr 2020 15:30:34 UTC.
    Dependencies resolved.

    Problem: cannot install the best candidate for the job
    – nothing provides /usr/bin/hostname needed by mod_ssl-1:2.4.43-6.codeit.el7.x86_64
    =====================================================================================================================================================
    Package Arch Version Repository Size
    =====================================================================================================================================================
    Installing:
    httpd x86_64 2.4.43-2.codeit.el7 CodeIT 1.4 M
    mod_ssl x86_64 1:2.4.43-2.codeit.el7 CodeIT 1.3 M
    Installing dependencies:
    brotli x86_64 1.0.7-5.el7 epel 318 k
    libnghttp2 x86_64 1.31.1-2.el7 epel 67 k
    sscg x86_64 2.6.1-1.el7 epel 60 k
    libpath_utils x86_64 0.2.1-32.el7 base 28 k
    libtalloc x86_64 2.1.16-1.el7 base 33 k
    mailcap noarch 2.1.41-2.el7 base 31 k
    apr x86_64 1.7.0-2.el7 CodeIT 122 k
    apr-util x86_64 1.6.1-6.el7 CodeIT 98 k
    httpd-filesystem noarch 2.4.43-2.codeit.el7 CodeIT 27 k
    httpd-tools x86_64 2.4.43-2.codeit.el7 CodeIT 1.3 M
    mod_http2 x86_64 1.15.7-1.codeit CodeIT 208 k
    Skipping packages with broken dependencies:
    mod_ssl x86_64 1:2.4.43-6.codeit.el7 CodeIT 121 k

    Transaction Summary
    =====================================================================================================================================================
    Install 13 Packages
    Skip 1 Package

    Thanks for your attention and apologies for taking your time!

      1. Hi Alexander, revisiting this
        Please review https://bugzilla.redhat.com/show_bug.cgi?id=1645638 which kind of shows the same issue – unresolved dependencies with /usr/bin/hostname. The suggestion is that the rpm package is wrong.

        A “dnf deplist ” gives the dependency and provider.
        For mod_ssl-1:2.4.43-6.codeit.el7.x86_64, this gives an unresolved dependency of /usr/bin/hostname

        By contrast dnf deplist mod_ssl-1:2.4.43-2.codeit.el7.x86_64 shows no such dependency requirement which suggests why it works.

        Apparently the correct approach is to remove the invalid dependency from the package. Either YUM or DNF will then operate correctly. It is not unreasonble to expect either system-provided package manager to work.

        Per previous – could I ask you to look again at the package?
        Thanks for your work
        Kindest regards
        Rob

        1. Hello Rob,

          Actually I think that problem is somewhere in the dnf database, as /usr/bin/hostname is registered as “provided” in the most recent “hostname” package. If I manually update it to the latest version, I do not see any problems with this dependency anymore.

          Anyway, to support dnf and avoid cases with non-updated OS we released a fix for this case, please test with testing repository and reply if it worked for you.

          https://repo.codeit.guru/packages/testing/x86_64/ – httpd-2.4.43-7

          1. Hey Alexander, thanks for looking at that
            TLDR: it worked cheers!

            The OS is up to date cannot understand your notes above.

            I looked at the link you gave, although a repodata folder’s in there I didn’t see any reference to a “testing” .repo available so I put my own, in order that either yum or, in this case, dnf could resolve all depedencies. Maybe I’m being thick and missed any published repo file.

            [CodeITtest]
            name=CodeIT test repo
            baseurl=https://repo.codeit.guru/packages/testing/x86_64/
            enabled=1

            dnf update
            =====================================================================================================================================================
            Package Arch Version Repository Size
            =====================================================================================================================================================
            Upgrading:
            httpd x86_64 2.4.43-7.codeit.el7 CodeITtest 1.4 M
            httpd-devel x86_64 2.4.43-7.codeit.el7 CodeITtest 213 k
            httpd-filesystem noarch 2.4.43-7.codeit.el7 CodeITtest 29 k
            httpd-tools x86_64 2.4.43-7.codeit.el7 CodeITtest 94 k
            mod_ssl x86_64 1:2.4.43-7.codeit.el7 CodeITtest 122 k

            Transaction Summary
            =====================================================================================================================================================
            Upgrade 5 Packages

            Total download size: 1.8 M
            Is this ok [y/N]: y

            No complaints about dependencies, clean upgrade and all sorted
            Thanks for your work!
            Kindest regards
            Rob

  7. Hi Alexander,

    I am working to fix a bug with httpd and mod_http2 (using your 2.4.43 from the centos 7 repo). I need to build an rpm with latest changes from https://github.com/icing/mod_h2 (from master) into a mod_http2.x86_64 1.15.9-x.codeit @CodeIT or similair
    would be good that I use your script for that (to speed up the build) so I can do locally. Is that something you could share? Please could you reply personally?
    This will help to fix mod_http2 – https://github.com/icing/mod_h2/issues/201

      1. hmm, you have an interesting dependancy in the mod_http2-1.15.9-1.codeit.x86_64 on the build being performed under /root/ folder, so tests fail if this process is executed from the non-root user 🙂 but so far going ok

      2. Hi, Alexander

        So there is a new 1.15.12 version of mod_http2 that fixes among other things
        header parsing which prevents 431 errors when cookies number approaches 100 on Firefox and Chrome 🙂
        looking forward to see that in your repos 🙂

  8. Hello,

    First of all, thanks for the great work.

    With your packages (Apache 2.4.43 as well as Apache 2.4.41), I have not able to override umask, which is mandaroty for my use. I tried different solution without effect.

    Is it related to a specific compiling option you are using?

    Many thanks in advance

  9. Hello, if I don’t set MaxConnectionsPerChild 0 or leave it as default httpd becomes unresponsive even if not high CPU or RAM usage, and after a while AH03490: scoreboard is full, not at MaxRequestWorkers.Increase ServerLimit. on error log. So, it could be caused by your additional modules or also modpagespeed from Google. Hard to say what, unless you let me know how to inspect what prevent httpd from correctly recycling children. Thanks

  10. Hi,
    about two weeks ago I replaced the CentOS httpd version with the 2.4.43 on one server that uses WebDAV. Replacement worked well as usual but now I have problems with the WebDAV connections.

    Reading directory contents works but if I try to create a new file/folder I get this message in error_log:
    [dav_fs:crit] [pid 8728:tid 139838229575424] (20019)DSO load failed: AH00576: The DBM driver could not be loaded

    After some seaches on different sites I really don’t understand what could be the cause for that problem. I only could see that all mentioned packages and modules come with the CodeIT version so everything should be fine.

    Just saw that there ist the new version 2.4.46, but after an update I still get this messages.
    So has anybody an idea of what the problem could be?

    Thank you very much!

Leave a Reply

Your email address will not be published. Required fields are marked *