Wilbur, yes, structure is the same.
But config files can be incompatible. For example, I noticed that comments are no more allowed in allow/deny clauses on the same line.

Also you will need to enable h2/h2c protocols in mod_ssl conf (we enabled h2 in default configuration file).
I would suggest you to install our build to a virtual machine and use your current production config files to see it will work. And only then enable additional modules and http/2.

That would be as problematic as removing it and a fresh yum install — so I did — and it brought your codeit httpd-tools and httpd-filesystem-2.4.25-1.el7.codeit.noarch as dependencies — so now a yum update will keep up with new builds codeit makes for the server and those files

Turns out I did not have mod_fcgid (base repo) or mod_ssl (your codeit repo) — though no dependency revealed that — so I got that far and I assume when you say mod_ssl conf — you mean the ssl.conf in /etc/httpd/conf.d/ssl.conf where I see «Protocols h2 http/1.1» at line 7

And so now I have minor httpd.conf and php issues as Virtualmin reports the Suexec command on my system is «configured to only run scripts under /var/www, but the Virtualmin virtual server home directory is /home. — so — CGI and PHP scripts run as domain owners will not be executed» — but the server comes up and displays the default page https and ssllabs — if I had a real certificate installed gives the ssl on the Apache server a STRAIGHT «A» rating — so I am happy — the rest is minor config stuff. The other version I removed got a «C-» so I am heading in the right direction. Next up multiple php

Looks like v. 2.4.6 was protected by your «virtualmin» repo.
Check files in /etc/yum.repos.d, search for «httpd» there and remove protection.
Please also note that probably they have a good reason to protect their build (and you have virtualmin build, not CentOS one)!

The Suexec command on your system is configured to only run scripts under /var/www, but the Virtualmin virtual server home directory is /home. CGI and PHP scripts run as domain owners will not be executed

or whatever the latest one is in the repo — then remove the Webmins 2.4.6 server as shown above by Thomas Serge

Or use rpm and find it to remove it. For instance, if you want to remove the package called «httpd.x86_64», you could do the following.

# rpm -qa | grep «httpd»
httpd.x86_64
# rpm -e —nodeps «httpd.86_64»

The first «rpm -qa» lists all RPM packages and the grep finds the package(s) you want to remove. Then you copy the entire name and run the «rpm -e —nodeps» command on that package. It will, without prompting for confirmation, remove that package but none of its dependencies.

If you do not do —nodeps — it will actually unistall Webmin / Virtualmin and PHP

This also works as the command => yum list installed | grep httpd

Do the httpd-tools FIRST — then immediately the codeit filesystem first then tools

You can point yum to the codeit repo (assuming you configured for the repo first) by using the full name of the codeit file OR FIRST

It will save the SSL.CONF file as a rpmnew and install a new one properly set up

Edit the NEW SSL.CONF and put in your servername, doc root and the certificate paths by cut and paste — if you are not using something like WinSCP and EditPadLite which work together to access your VPS and let you edit fast — then get them on your machine FIRST

THIS IS IMPORTANT as if you do not install the codeit mod_ssl the OLD cipher suites will STILL leave you with a «C» rating

A check at SSLLABS now should yield an A rating — if you have a valid SSL certificate

Then in Webmin / Virtualmin under Virtualmin=> System Settings => Virtualmin Configuration => under => Defaults for new domains => check => Home directory base and be sure it is set to /var/www or change the doc root to /home in the server and to /home there

OTHERWISE . . . . the CodeIT setup is the same as the Webmin server as to file structure and if you follow this you should not loose anything and PHP will still be on the system available to work in the webserver even with the swap

For best performance you should use php-fpm and sockets in a pool setup

Please provide output of «rpm -qa | grep apr». I think you can have libs from Virtualmin repo, as Wilbur Union correctly pointed out. Please be sure to follow all the steps he described, looks like a impressive comprehensive guide for Virtualmin.

[ssl:warn] [pid 2688] AH01882: Init: this version of mod_ssl was compiled against a newer library (OpenSSL 1.0.2j 26 Sep 2016, version currently loaded is OpenSSL 1.0.2h 3 May 2016) — may result in undefined or erroneous behavior

I am not a CodeIT representative; and I could be wrong; however, I can tell you that the CodeIT mod_ssl package installs a properly configured ssl.conf file to Apache you need to edit to put your server info BACK into from the ssl.conf.rpmsave file

Do not just rename your old file back to ssl.conf

IF you have your ssl info in the httpd.conf file and/or as virtual hosts mixed in there you have a lot of analyzing to do — or cutting assunder ssl stuff.

I recommend putting it in a ssl.conf file as the CodeIT apache server is setup under the conf.d directory

ALSO if you have a SSL certificate that is https security enabled and you do not have it properly configured this may — in fact WILL — cause that error also.

For instance I got a 403 forbidden — when cPanel — «automagically» installed its own ssl certs on all my sudomains where a true commercial «wildcard SSL» cert was handling that under domain access via Drupal. That was a no-brainer when I saw what cPanel had «automagically» done — BUT — only a reinstall of the entire user account would fix it. That was the big beginning of the end of my relationship with cPanel. And their support is horrible. since cpanel hacks up a Linux sever to their file structure — they do not know how a true CentOS system is really set up nor what is wrong when something they do does not work under Drupal (7 or 8) the cpanel «apache2» and «easy apache» setup has incompatible files to this CodeIT server because of the 1.02j static compile which is what gives the «A» rating at SSLLABS

A cPanel 2.4.25 apache2 server still at this writing gives an «A-» rating at SSLLABS

Needless to say — since I am talking about webmin now — I DUMPED cPanel and all its «automagically» created crap — and I am here to ALSO tell you if you are trying to use cPanel with this CodeIT setup -that TOO will not work. cPanel changes so many files in CentOS that it is really its own distribution and not WORTH the monthly license fee because they screw up a good CentOS system, and even if you have a CentOS 7 system that once had cPanel — you will have problems — even though the CodeIT 2.4.25 httpd server will install. Go to the CentOS.org forums and they will tell you right away — they will not even try to support a cPanel beast.

Needless to say this CodeIT 2.4.25 webserver also does not work on CentOS 6 — or likely nor on a hybrid upgraded one which may have mix-matched files — that technically might work with hacked upgaded GLIBC files.

If you visit your website and then right click and inspect the page and get to the «security» section — it should STILL give you info on your certificate

Also check the logs at /var/log/httpd for errors and access and ssl closely

Just to make sure — do a «yum remove mod_security» to be sure it is not causing a problem — you can always install it again later

It does seem to matter if you just erased with «nodeps» or uninstalled — that is used «yum remove» to get rid of previous files — especially mod_ssl. If you just «erase» and leave old dependencies — the latest version «may not» be updated when you install the new program — that is old files may be left behind.

You should try a «yum update» and then LOOK at where the files are coming from — that is what repo — BEFORE you accept «y».

That does not mean an old dependency which needs to be updated is not actually satisfying a newly installed program file like the sslwarn error shows «might» be the case. This has LONG been a Red Hat dependency problem — old enough to cause a problem but new enough to satisfy another new program install dependency in an appearance-check only.

If there is no conflict between a repo — and it is only updating an existing file the newer version dependency needed file will be ignored and NOT installed, updated or replaced. Yum also will not even check for a newer file from another repo — it will take the one compatible to the OLD existing file.

A «yum update» — is NOT a «yum replace» (replacepkg) check for a dependency — and nor does it update or replace dependency files that satisfy another newer program in a range of greater than or equal to version — but NOT in its conflict.

For instance this CodeIT server requires >- apr-util 1.5.0 and if you have 1.50 installed that will meet the dependency check — when it is better to have the current version at this writing which is 1.5.2. If you have 1.50 from another repo — it will NOT tell about version 1.52

Also make sure your firewall or iptables are open to both port 80 and 443

AND your user and group are properly set in the httpd.conf and ssl.conf — this WILL happen in php-fpm set ups where the pool file user does not match or in an httpd.conf where SuexecUserGroup is used

Also try changing the statement — which is the default ssl.conf file setup to

#

That is comment out the original and copy a new one like above which is a wildcard ssl call to port 443

If your ssl configuration is in the http.conf file that is a problem too

All of those can cause 403 forbidden errors also

The more manual editing you try to do the more likely you will create more problems

IF you go to ssllabs.com and if runs and you do not get a «A» rating — you are using a mixed ssl configuration or wrong ssl.conf file

Even if you are using a purchased ssl certificate — install the apache certbot and get a letsencrypt cert installed — because the certbot —apache will install the certs correctly to ssl.conf FOR YOU

Then you can look at the ssl.conf and see what might be wrong — however the issue is very likely between your httpd.conf and ssl.conf files as to the 403 forbidden issue — OR php-fpm if you are running that.

You can always EDIT the then working ssl.conf file back to your certificates ONLY and the rest will then work

BUT as to the

«» [ssl:warn] [pid 2688] AH01882: Init: this version of mod_ssl was compiled against a newer library (OpenSSL 1.0.2j 26 Sep 2016, version currently loaded is OpenSSL 1.0.2h 3 May 2016) – may result in undefined or erroneous behavior «»

I have that also ON A FRESH install where the webmin httpd server nor any other mod_ssl was ever allowed to be installed

That is I manually installed a new and virgin «sane» Centos 7 OS «image» — then did a yum update to 7.3.11 then added my previously configured repo files BACK to the new OS install — including the CodeIT repo and other repos and keys and did a new epel release install etc . . . and those repo files had excluded all the Virtualmin files I listed above and the SECOND command I ran after «yum update» was «yum install httpd-filesystem» which found the CodeIT file, and then «yum install httpd-tools» which found the CodeIT tools file and brought as a dependency httpd itself from codeIT — as httpd-2.4.25-1.el7.codeit.x86_64.

THEN I did a «yum install perl» THEN I ran Virtualmin’s dependency files from the install.sh — but not the install.sh itself

long but complete to be ready to install Wemin and virtualmin MANUALLY

Which must be noted completed the LAMP stack with a remi php56 install and installed MariaDB in the latest version (my repo files and key was already in the files I copied back up to the server for MariDB) — and at that point the webserver was working with PHP.

Then I did a «yum install virtualmin» which brought as a dependency => webmin

The «mod_ssl» install from the virtualmin dependency group above manually installed brought the CodeIT mod_ssl — as it was excluded in the Virtualmin repo files

Then I got a new SSL cert from letsencrypt which installed it automatically to the ssl.conf file

Then a check at SSLLABS brought an «A» rating and I installed the new letencrypt cert to Virtualmain /Webmin

So I do not at this moment know where the ssl warn error comes from unless it is from perl-Crypt-SSLeay.x86_64 — but right now does not prevent access to the server

Hi, Wilbur!
Only after I add «Protocols h2 h2c http/1.1» in ssl.conf the pages returns error 403, without it it works fine (can’t enable HTTP/2 by some reason). Can it be SELinux related issue?
Also only after «setsebool -P httpd_execmem on» I succeeded to make Apache run.

Thanks, Alexander! It fixed the SSL warning «… this version of mod_ssl was compiled against a newer library …».
Still when used «Protocols h2 h2c http/1.1» it returns error 403. Any idea why?
Also error_log still has ModSecurity warning «Loaded APR do not match with compiled!». Any way to fix it?

HERE IT IS PASTED AGAIN BELOW (with some added edits) — ignore it if you already read it above

Hi Binyadmin and Alexander

Reading the phpinfo I could see that mod_ssl was not loading what the server was compiled with

That is WHY above I said it was critically important to install the CodeIT mod_ssl file — becasue it gets an «A» rating meaning it is negotiating yhe proper cipher suites — whereas the virtualmin mod_ssl can only must a «C» rating at SSLLABS — but then i could see the mixmatch in the error logs and i knew it had to be between the server compile and mod_ssl package

I can confirm the new version — httpd-2.4.25-3.el7.codeit.x86_64.rpm — compiled against 1.02k fixed the error – I now only get

My 2 cents – I agree with Alexander – remove Mod_security = or AT LEAST begin a “yum remove mod_security” and see what dependencies it wants to take with it

THEN reinstall it — if you must — and it may work properly

Binyanin – as I said above – the ssl.conf that comes down from Codeit (in the original mod_ssl) comes with and provides the proper protocols command in the ssl.conf – it is at the top of the file — however an update likely will NOT provide it again — so if you want the ssl.conf remove it and reinstall it and it should save your ssl.conf as ssl.conf.rpmnew

The proper command should be Protocols h2 http/1.1 => not what you list – Protocols h2 h2c http/1.1

I do not think this is now SELinux related – but as Alexander said

Alexander Gerasimov said January 11, 2017 at 1:25 pm

“” You can try to disable SELinux for testing purposes: “setenforce 0”. “”

Use the command as CodeIT provided it and the server in SSL mode will work – and if you go to SSLLABS and get an “A” rating you cannot do any better – so the manual edits will not help any further — but only cause you problems as I said earlier

To any readers just coming across this page — install ONLY httpd-2.4.25-3.el7.codeit.x86_64.rpm and its support files — NOTICE version «3» of httpd-2.4.25-3 — and not the earlier versions

As to mod_security — I would suggest you consider version 2.90 or higher

It can be found as a rpm for Fedora 24 and 2.91 for Fedora 25 at this writing which will work on this CodeIT server set up

Fedora 19 or greater is => RHEL 7 which is also => CentOS 7

mod_security 2.73 (which your system showed as installed) is the latest at this writing in the epel repo so you usually will not find 2.90 in a yum search usually at this writing

mod_security 2.90 comes configured in the rpm to match this CodeIT server setup using *.conf includes and all it «technically» needs is server restart to call in a load of the modules and include confs which include rules

mod_security 2.80 and above have support for CRS 3 and 2.73 does not so that module that shows you are using does not.

You can also download the crs git page into for instance /etc/httpd/crs where it will harmlessly be available for manual mods in the future — however do not just enable the example.conf like many sites suggest as it is ALREADY enabled in the form of the rpm install — you can look at and edit the existing conf files provided by the rpm as needed with other rules etc you want

two library files are needed as a dependency to install mod_security 2.90

yum install yajl

and

the » lua53u-libs »

yum install lua53u-libs (which sometimes yum does not find in the ius repo)

and is also available as lua53u-libs-5.3.4-1.ius.centos7.x86_64.rpm in the ius repo and a «few» other places around the web

of course you also then » CAN «configure a Fedora 25 repo safely to keep it up to date; however, it is not advised — nor a » Rawhide » repo — not because the files in them are not compatible but because you risk overly «polluting» your CentOS 7 as a TRUE CentOS — OS

Then you can «get» the » git » CRS 3 files by then making sure your system is up to date and installing things you might need from git — they now call » owasp-modsecurity-crs » to differentiate it from the 2.73 version only called » mod_security_crs »

So yes » yum remove mod_security mod_security_crs » first if they not already uninstalled

httpd-devel should bring the CodeIT devel file to match this CodeIT server (unless you already have it installed) and if it does not then you do not have the CodeIT repo configured . . . so stop and do so or you risk polluting the CodeIT server

Then the entire owasp-modsecurity-crs git page ( crs 3 ) should be in the directory /etc/httpd/crs/owasp-modsecurity-crs — and is NOT installed anywhere but only now you have the latest rules of whatever version time the git repository was modified — but READ everything and compare what you want to add or do not need to add because the rpm has already installed and configured much of it integrated already

You will not get compiled version errors then from mod_security — it works fine on my systems

I disabled SELinux, removed mod_security, mod_security_crs and mod_ssl, and clean install mod_ssl (kept its original config file). But still the same 403 error when used «Protocols h2 http/1.1». Any tips on how to actually make HTTP/2 working?

I installed mod_security 2.9.1 and mod_security_crs 2.2.9 (from «wget -q -O — http://www.atomicorp.com/installers/atomic | sh»), and it continues to show warning «ModSecurity: Loaded APR do not match with compiled!».

As I said I am not a CodeIT representative and it appears the CodeIT is running properly, but you are mixing now programs and as I said in an earlier post that can bring mixed library troubles. Also if you install a file via tarball and compile and install it — then do an rpm later — you will get that kind of error too.

Not to take up CodeIT’s server space but in an effort to assist and show you what you have done

Remember manually installed programs not of an rpm nature will not show

Your error log is telling you that you have mixed up files installed

So the simple tip is fix the mis-matches

You need to search for linux tools to tell you where the mis-matches are

You can try

whereis libaprutil-1.so.0

To see where it is — how many there are, if there are ones in different locations, what the dates are, and if it links to other names et cetera — and from that point you need to KNOW what you are doing as to deleting files et cetera

If you just «erased» an rpm with «nodeps» there is a chance that files were left behind

If you have done a lot of «hosed» up commands like using that atomiccorp stuff your system may not be «sane» any longer and it will take a lot of manual work to «try» to straighten it out

My previous post TOLD you to uninstall mod_security_crs and it told you that the NEW rules for mod_security version 2.80 and above is crs3 that is owasp-modsecurity-crs — NOT mod_security_crs — yet you reinstalled mod_security_crs when the post TOLD you NOT to because it was already configured with rules in the rpm

You are also installing things from non-approved sources using manual methods when the best way to keep a Linux system «sane» is to use the automatic tools that come with it — namely yum

The simple tip on fixing your system is get that unapproved crap off your system, do not use unapproved and known problem software sources, configure to the approved repos correctly and use yum FIRST — and only if a file is NOT available then use another source AFTER best efforts to verify it is a safe source

The CodeIT repo while not «officially listed» as approved — is often referred to at CentOS.org as a safe and well maintained repo — and the fact they posted a fix to the cutting edge h2 Apache 2.4.25 server build WITHIN A FEW HOURS — when the file mis-match was discovered is a testament to that. These problems you have is NOT due to their server at all as mine works fine and my error log is only four lines:

Take off mod_security_crs and see if «some» errors go away — and re-read my last post

mod_security WILL also cause 403 forbidden responses if configured improperly or you call to your server that breaks a rule- that is its function

Also remember as I said you can get version mis-matches installing old versions — and if you do not remove them and their dependencies — or you installed them without dependencies — for instance did not use yum — then those dependency files may well remain or libraries and be the potential cause of problems later

For instance the lua53u-libs-5.3.4-1.ius.centos7.x86_64.rpm WILL INSTALL against lua5.1 but it is good practice to remove lua5.1 and install lua5.3 to keep lua «sane» even though mod_security 2.90 only uses ONE file provided by lua53u-libs

These are things YOU need to know as a linux admin and while I will look at the posts I requested of you — if you post them — I am not a CodeIT representative and this is their technical blog page, and nor am I being paid for this so my assistance to you is nearing its close.

The CodeIT server is working fine it appears — and is working fine for me — excellent in fact

The error log is telling what is wrong and it is all mod_security related it appears — yet I do not have those errors and I have mod_security 2.90 installed and mod_evasive and both are working fine with the CodeIT 2.4.25 / 1.02k server

If Alexander has nothing to add, I cannot see how you can be helped further — the error log is TELLING you what is wrong, and I have told you ways you have mis-matched up your system possibly, and you need to search the problem and fix it

I’m trying to build my own RPMS for the latest apache version using exactly how the default Centos7 Apache 2.4.6 was built. This means all the stock modules, the way it uses the default SSL, file location etc..

Can you share how did you build your RPMS and how to make it compatible on all the default modules the stock Centos7 apache has?

I want to have the same behavior as if i’m doing a yum update from a CentOS official repo with release apache 2.4.latest.

Yes, your RPM is working fine and probably better, but is there a way to have it as close as CentOS official release?