Page still in development, bear with me...

LibreLAMP - A LAMP Stack for RHEL/CentOS 7

LibreLAMP is a collection of RPM Packages providing an alternate LAMP stack linked against LibreSSL, replacing the RHEL/CentOS 7 provided LAMP stack, which is linked against OpenSSL.

The intended audience is the security minded system administrator that understands the value of a TLS library that has a well-managed code-base with insecure protocols and ciphers removed, and without the un-necessary feature bloat that currently plagues the OpenSSL library.

LibreSSL was forked by the OpenBSD developers out of frustration over several issues with OpenSSL. LibreLAMP is the result of my frustration that it otherwise would likely take years for me to see the library make it into RHEL/CentOS, the server platform I am committed to.

Reactive security is patching exploits as they are found. Proactive security is removing potential exploitable code before the exploits are found. I prefer to be proactive, I did not want to wait for LibreSSL to come to me.

This page describes the software packages that are part of the LAMP stack itself.

For e-mail server software, see the Mail Software page.

List of Topics

LibreSSL Packaging Notes

[Puffy the LibreSSL Mascot]

No version of LibreSSL ships with RHEL/CentOS 7. The LibreSSL provided as part of LibreLAMP (Version 2.6.4) is a TLS library used as an alternative to OpenSSL.

LibreSSL is a fork of the OpenSSL project.

The purpose of a TLS library is to provide secure encrypted communication between two networked computers. Protocols and cipher suites that are weak or known to be insecure do not meet that purpose and have been removed. Features (such as heartbeat) that provide very little benefit but are potentially exploitable (such as the heartbleed vulnerability) have been removed. The remaining code has been reviewed with considerable cleanup. The result is a TLS implementation with a smaller code base that is fundamentally more secure than OpenSSL.

A goal of the LibreSSL project is produce a secure alternative to OpenSSL. I like that goal. However the purpose of LibreLAMP is not to replace OpenSSL, but rather, to provide a LAMP stack using LibreSSL installed in parallel with the distribution vendor provided OpenSSL.

I am personally very fond of RHEL/CentOS as a stable enterprise quality Linux distribution, but it will probably be years before LibreSSL becomes a part of that platform. I did not want to wait years for the security benefits that come from using LibreSSL as the TLS library for my public facing servers.

As such, my goal in packaging LibreSSL for RHEL/CentOS 7 is to package for parallel installation with the system OpenSSL rather than as a replacement for the system OpenSSL.

To achieve parallel installation, the /usr/bin/openssl binary that would normally be installed with LibreSSL has been renamed to /usr/bin/libressl.

Scripts and utilities that call /usr/bin/openssl will still be using the version provided by RHEL/CentOS 7. This is important, not every option supported by the vendor /usr/bin/openssl is supported by the LibreSSL fork (e.g. the -rand switch to genrsa). It is difficult to know what all these differences are because the RHEL/CentOS 7 provided man page for openssl(1) is extremely sparse and lacking in information about options to the command.

Configuration File Notes

I could have continued to use the RHEL/CentOS 7 provided /etc/pki/tls/openssl.cnf file as the configuration file for LibreSSL but I chose not to for several reasons:

  • Even though my goal is not to replace OpenSSL, I do not want to depend upon it either.
  • It is possible some of the configuration options are broken in LibreSSL.
  • I do not yet understand all of the implications of the configuration options in the RHEL/CentOS 7 provided configuration file. I did not want to package a binary that uses configuration options for which I am not familiar with the implications or the security of those implications.

What I did was patch LibreSSL to use /etc/pki/tls/libressl.cnf by default instead.

If you wish to change the behavior of LibreSSL, that is the file you need to customize.

Devel Package Notes

The libressl-devel package conflicts with the RHEL/CentOS 7 supplied openssl-devel package.

This is because LibreSSL is API compatible with OpenSSL 1.0.1, so many of the header files have the same file name and are installed in the same place so that software that wants to link against the library can find the header files.

There is really not a sane reason for trying to have both libressl-devel and openssl-devel installed at the same time.

LibreSSL and FIPS

LibreSSL does not support FIPS and I suspect it never will.

For all practical purposes, FIPS is worthless. Read more about LibreSSL and FIPS here: The future (or lack thereof) of LibreSSL’s FIPS Object Module.

Apache Packaging Notes

[Apache Feather Logo]
Apache Feather

RHEL/CentOS 7 ship with Apache 2.4.6. LibreLAMP ships Apache 2.4.29. Using a newer version of the Apache web server will prevent the LibreLAMP Apache packages from being replaced by an update to the Apache packaging in RHEL/CentOS 7.

Third party Apache modules built for the vendor provided Apache 2.4.6 web server should still work with LibreLAMP provided Apache 2.4.29.

The Apache build provided by LibreLAMP is based upon the RPM spec file used to build the vendor Apache 2.4.6. The layout is the same and RHEL/CentOS 7 specific patches that are not already merged into Apache 2.4.29 are applied.

Other than a few new Apache features that are available, using the Apache provided by LibreLAMP should be no different than using the Apache provided by RHEL/CentOS 7, with the noted exceptions listed in the sections below.

mod_ssl Patch

LibreLAMP has patched mod_ssl to reject the RC4 and the LOW quality ciphers. They simply should never be used in a secure connection.

When a cipher uses DH parameters and your Apache configuration does not point to custom DH parameters, 3072-bit are used by default instead of 2014-bit.


The Apache Server in LibreLAMP supports HTTP/2 ALPN out of the box. The core configuration file is located at /etc/httpd/conf.modules.d/00-http2.conf and by default contains the following:

LoadModule http2_module modules/
ProtocolsHonorOrder On
Protocols h2 http/1.1

That configuration will provide HTTP/2 when TLS is being used and the client supports HTTP/2. Otherwise it will use HTTP/1.1. For more options with the Apache Protocols directive, please see the Apache Protocols Directive documentation.

You may also benefit from virtual host specific tweeks to HTTP/2. Several different directives are available, as described in the Apache mod_http2 Module Documentation.

OCSP Stapling

The directives needed to add OCSP Stapling to Apache have been added to the default /etc/httpd/conf.d/ssl.conf file.

This can cause error messages in the log file if your TLS certificates do not support OCSP validation. If this causes problems, please see the Apache documentation at for solutions.

To disable it completely, you can edit the /etc/httpd/conf.d/ssl.conf file and comment out the following two lines:

SSLUseStapling On
SSLStaplingCache "shmcb:/run/httpd/ssl_stapling(65536)"

MariaDB Packaging Notes

[MariaDB Seal Logo]
MariaDB Seal

RHEL/CentOS 7 ships with MariaDB 5.5.41. LibreLAMP currently provides MariaDB 10.1.31. It is my plan to update to the 10.2.x or 10.3.x branch of the MariaDB SQL database suite soon.

These versions are not ABI compatible, software linked against the vendor provided MariaDB libraries will need to be rebuilt against the newer MariaDB libraries.

In the past I tried to keep ABI compatability with the MariaDB that ships with CentOS 7 but the 5.x branch is really old now. I have been using the 10.1.x branch myself for over a year now, it really is an improvement worth having.

PHP Packaging Notes

[PHP Elephant Logo]
Logo by Camilo Sanchez
CC by 3.0

RHEL/CentOS 7 ships with PHP 5.4.16 which is really old. The 5.4 branch of PHP is end of life and no longer even receive bug fixes from the PHP developers. Many modern web applications expect a newer version of PHP.

The PHP in LibreLAMP is 7.1.14. I probably will not package PHP 7.2.x but will keep packages 7.1.x releases until the next major branch after 7.2 branch.

Some of the PHP modules have dependencies on libraries that are part of the EPEL project. Installation of those PHP modules will require that you have the EPEL package repository enabled.

Pristine Source

RHEL/CentOS and Fedora remove some of the PHP source code in their source package. LibreSSL does not. I previously thought it was due to patent issues but I have been informed it has to do with the licensing of ext/json not actually being FLOSS.

The issue appears to be a clause in the license that says ‘The Software shall be used for Good, not Evil.’

Technically speaking FLOSS does not restrict the intended use of the software. So due to that clause, many distributions modify the PHP source to remove the ext/json code. Personally I find the clause in the license humorous. Am I evil?

PECL Extensions

The version of PHP provided by LibreLAMP is not ABI compatible with the version of PHP that ships with RHEL/CentOS 7. As such, PECL modules built against the version of PHP that ships with RHEL/CentOS 7 will not work with the PHP provided by LibreLAMP.

LibreLAMP provides packages that do work for some of the PECL module available in RHEL/CentOS 7 and in EPEL.

If you need a particular PECL extension not provided by LibreLamp, feel free to contact me and I will see what I can do.

PEAR Extensions

PHP PEAR Extensions are script libraries, they are not binary. It is my suggestion to just use the /usr/bin/pear utility to install and update any PEAR extensions that you might need. LibreLAMP will not package them.

Update Policy

Security issues and serious bugs in software packages distributed as part of LibreLAMP will be updated in a timely manner.

I do prefer to wait for a patch that is endorsed by the upstream project before applying a patch unless the particular bug involves a remote exploit vulnerability.

For LibreSSL itself, I do plan to keep up with upstream versioning. However I will not always release a new version of LibreSSL immediately. When shared library versions change, I prefer to wait until the next Apache or PHP update before pushing a new version of LibreSSL.

A shared library versioning change requires rebuilding all packages that link against LibreSSL. That is very time consuming on my end and results in pushing a lot of updated packages to the update server. As PHP tends to be updated about once a month anyway and is a fairly significant update itself, I prefer to wait until the next PHP update to push the changes.

When an update to LibreSSL does not version the shared library, then it is safe to push an update without needing to rebuild all the software that uses it, as that indicates the new version is ABI compatible with the previous version.

For the Apache web server, only updates from the 2.4.x branch will be made available. That is the branch that ships in RHEL/CentOS 7 and is also the most current stable branch available upstream. When a new branch is available upstream, updating to that branch will need a very compelling reason before I choose to do it.

With PHP I tend to update every other major release. For example, I skipped the PHP 7.0.x branch but I am packaging the PHP 7.1.x branch. I will likely skip PHP 7.2.x branch but will likely package the PHP 7.3.x branch.

Future Plans

The LAMP stack is pretty much covered. However there are other public facing servers that are commonly used that would benefit from linking against LibreSSL as opposed to OpenSSL. Once I am confident the LAMP stack is in fact performing to Enterprise standards, the following are my personal highest priority:

  • NSD (Authoritative DNS Nameserver)
  • Unbound (Recursive DNS Server)
  • Nginx (Popular web server)

NSD and Unbound are done, some documentation still needs to be created for them.

There are some servers that I do not wish to rebuild against LibreSSL:

  • OpenSSH (I would actually love to rebuild against LibreSSL but if I screw it up, I can not easily connect to my servers to revert. There is a second remote way in but it is a pain the ass to use)
  • BIND (I do not think it should be used, too many security issues too often)
  • Sendmail (I do not think it should be used, too many security issues too often)


All software packages in LibreLAMP are Free Libre Open Source Software licensed under various FLOSS licenses.

The source code, including all patches, can be obtained in Source RPM packages located at