Chapter 12. Web Servers

A web server is a network service that serves content to a client over the web. This typically means web pages, but any other documents can be served as well. Web servers are also known as HTTP servers, as they use the hypertext transport protocol (HTTP).

12.1. The Apache HTTP Server

The web server available in Red Hat Enterprise Linux 7 is version 2.4 of the Apache HTTP Server, httpd, an open source web server developed by the Apache Software Foundation.
If you are upgrading from a previous release of Red Hat Enterprise Linux, you will need to update the httpd service configuration accordingly. This section reviews some of the newly added features, outlines important changes between Apache HTTP Server 2.4 and version 2.2, and guides you through the update of older configuration files.

12.1.1. Notable Changes

The Apache HTTP Server in Red Hat Enterprise Linux 7 has the following changes compared to Red Hat Enterprise Linux 6:
httpd Service Control
With the migration away from SysV init scripts, server administrators should switch to using the apachectl and systemctl commands to control the service, in place of the service command. The following examples are specific to the httpd service.
The command:
service httpd graceful
is replaced by
apachectl graceful
The systemd unit file for httpd has different behavior from the init script as follows:
  • A graceful restart is used by default when the service is reloaded.
  • A graceful stop is used by default when the service is stopped.
The command:
service httpd configtest
is replaced by
apachectl configtest
Private /tmp
To enhance system security, the systemd unit file runs the httpd daemon using a private /tmp directory, separate to the system /tmp directory.
Configuration Layout
Configuration files which load modules are now placed in the /etc/httpd/conf.modules.d/ directory. Packages that provide additional loadable modules for httpd, such as php, will place a file in this directory. An Include directive before the main section of the /etc/httpd/conf/httpd.conf file is used to include files within the /etc/httpd/conf.modules.d/ directory. This means any configuration files within conf.modules.d/ are processed before the main body of httpd.conf. An IncludeOptional directive for files within the /etc/httpd/conf.d/ directory is placed at the end of the httpd.conf file. This means the files within /etc/httpd/conf.d/ are now processed after the main body of httpd.conf.
Some additional configuration files are provided by the httpd package itself:
  • /etc/httpd/conf.d/autoindex.conf — This configures mod_autoindex directory indexing.
  • /etc/httpd/conf.d/userdir.conf — This configures access to user directories, for example, http://example.com/~username/; such access is disabled by default for security reasons.
  • /etc/httpd/conf.d/welcome.conf — As in previous releases, this configures the welcome page displayed for http://localhost/ when no content is present.
Default Configuration
A minimal httpd.conf file is now provided by default. Many common configuration settings, such as Timeout or KeepAlive are no longer explicitly configured in the default configuration; hard-coded settings will be used instead, by default. The hard-coded default settings for all configuration directives are specified in the manual. See Section 12.1.13, “Installable Documentation” for more information.
Incompatible Syntax Changes
If migrating an existing configuration from httpd 2.2 to httpd 2.4, a number of backwards-incompatible changes to the httpd configuration syntax were made which will require changes. See the following Apache document for more information on upgrading http://httpd.apache.org/docs/2.4/upgrading.html
Processing Model
In previous releases of Red Hat Enterprise Linux, different multi-processing models (MPM) were made available as different httpd binaries: the forked model, prefork, as /usr/sbin/httpd, and the thread-based model worker as /usr/sbin/httpd.worker.
In Red Hat Enterprise Linux 7, only a single httpd binary is used, and three MPMs are available as loadable modules: worker, prefork (default), and event. Edit the configuration file /etc/httpd/conf.modules.d/00-mpm.conf as required, by adding and removing the comment character # so that only one of the three MPM modules is loaded.
Packaging Changes
The LDAP authentication and authorization modules are now provided in a separate sub-package, mod_ldap. The new module mod_session and associated helper modules are provided in a new sub-package, mod_session. The new modules mod_proxy_html and mod_xml2enc are provided in a new sub-package, mod_proxy_html. These packages are all in the Optional channel.

Note

Before subscribing to the Optional and Supplementary channels see the Scope of Coverage Details. If you decide to install packages from these channels, follow the steps documented in the article called How to access Optional and Supplementary channels, and -devel packages using Red Hat Subscription Manager (RHSM)? on the Red Hat Customer Portal.
Packaging Filesystem Layout
The /var/cache/mod_proxy/ directory is no longer provided; instead, the /var/cache/httpd/ directory is packaged with a proxy and ssl subdirectory.
Packaged content provided with httpd has been moved from /var/www/ to /usr/share/httpd/:
  • /usr/share/httpd/icons/ — The directory containing a set of icons used with directory indices, previously contained in /var/www/icons/, has moved to /usr/share/httpd/icons/. Available at http://localhost/icons/ in the default configuration; the location and the availability of the icons is configurable in the /etc/httpd/conf.d/autoindex.conf file.
  • /usr/share/httpd/manual/ — The /var/www/manual/ has moved to /usr/share/httpd/manual/. This directory, contained in the httpd-manual package, contains the HTML version of the manual for httpd. Available at http://localhost/manual/ if the package is installed, the location and the availability of the manual is configurable in the /etc/httpd/conf.d/manual.conf file.
  • /usr/share/httpd/error/ — The /var/www/error/ has moved to /usr/share/httpd/error/. Custom multi-language HTTP error pages. Not configured by default, the example configuration file is provided at /usr/share/doc/httpd-VERSION/httpd-multilang-errordoc.conf.
Authentication, Authorization and Access Control
The configuration directives used to control authentication, authorization and access control have changed significantly. Existing configuration files using the Order, Deny and Allow directives should be adapted to use the new Require syntax. See the following Apache document for more information http://httpd.apache.org/docs/2.4/howto/auth.html
suexec
To improve system security, the suexec binary is no longer installed as if by the root user; instead, it has file system capability bits set which allow a more restrictive set of permissions. In conjunction with this change, the suexec binary no longer uses the /var/log/httpd/suexec.log logfile. Instead, log messages are sent to syslog; by default these will appear in the /var/log/secure log file.
Module Interface
Third-party binary modules built against httpd 2.2 are not compatible with httpd 2.4 due to changes to the httpd module interface. Such modules will need to be adjusted as necessary for the httpd 2.4 module interface, and then rebuilt. A detailed list of the API changes in version 2.4 is available here: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html.
The apxs binary used to build modules from source has moved from /usr/sbin/apxs to /usr/bin/apxs.
Removed modules
List of httpd modules removed in Red Hat Enterprise Linux 7:
mod_auth_mysql, mod_auth_pgsql
httpd 2.4 provides SQL database authentication support internally in the mod_authn_dbd module.
mod_perl
mod_perl is not officially supported with httpd 2.4 by upstream.
mod_authz_ldap
httpd 2.4 provides LDAP support in sub-package mod_ldap using mod_authnz_ldap.

12.1.2. Updating the Configuration

To update the configuration files from the Apache HTTP Server version 2.2, take the following steps:
  1. Make sure all module names are correct, since they may have changed. Adjust the LoadModule directive for each module that has been renamed.
  2. Recompile all third party modules before attempting to load them. This typically means authentication and authorization modules.
  3. If you use the mod_userdir module, make sure the UserDir directive indicating a directory name (typically public_html) is provided.
  4. If you use the Apache HTTP Secure Server, see Section 12.1.8, “Enabling the mod_ssl Module” for important information on enabling the Secure Sockets Layer (SSL) protocol.
Note that you can check the configuration for possible errors by using the following command:
~]# apachectl configtest
Syntax OK
For more information on upgrading the Apache HTTP Server configuration from version 2.2 to 2.4, see http://httpd.apache.org/docs/2.4/upgrading.html.

12.1.3. Running the httpd Service

This section describes how to start, stop, restart, and check the current status of the Apache HTTP Server. To be able to use the httpd service, make sure you have the httpd installed. You can do so by using the following command:
~]# yum install httpd
For more information on the concept of targets and how to manage system services in Red Hat Enterprise Linux in general, see Chapter 9, Managing Services with systemd.

12.1.3.1. Starting the Service

To run the httpd service, type the following at a shell prompt as root:
~]# systemctl start httpd.service
If you want the service to start automatically at boot time, use the following command:
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

Note

If running the Apache HTTP Server as a secure server, a password may be required after the machine boots if using an encrypted private SSL key.

12.1.3.2. Stopping the Service

To stop the running httpd service, type the following at a shell prompt as root:
~]# systemctl stop httpd.service
To prevent the service from starting automatically at boot time, type:
~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

12.1.3.3. Restarting the Service

There are three different ways to restart a running httpd service:
  1. To restart the service completely, enter the following command as root:
    ~]# systemctl restart httpd.service
    This stops the running httpd service and immediately starts it again. Use this command after installing or removing a dynamically loaded module such as PHP.
  2. To only reload the configuration, as root, type:
    ~]# systemctl reload httpd.service
    This causes the running httpd service to reload its configuration file. Any requests currently being processed will be interrupted, which may cause a client browser to display an error message or render a partial page.
  3. To reload the configuration without affecting active requests, enter the following command as root:
    ~]# apachectl graceful
    This causes the running httpd service to reload its configuration file. Any requests currently being processed will continue to use the old configuration.
For more information on how to manage system services in Red Hat Enterprise Linux 7, see Chapter 9, Managing Services with systemd.

12.1.3.4. Verifying the Service Status

To verify that the httpd service is running, type the following at a shell prompt:
~]# systemctl is-active httpd.service
active

12.1.4. Editing the Configuration Files

When the httpd service is started, by default, it reads the configuration from locations that are listed in Table 12.1, “The httpd service configuration files”.

Table 12.1. The httpd service configuration files

Path Description
/etc/httpd/conf/httpd.conf The main configuration file.
/etc/httpd/conf.d/ An auxiliary directory for configuration files that are included in the main configuration file.
Although the default configuration should be suitable for most situations, it is a good idea to become at least familiar with some of the more important configuration options. Note that for any changes to take effect, the web server has to be restarted first. See Section 12.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.
To check the configuration for possible errors, type the following at a shell prompt:
~]# apachectl configtest
Syntax OK
To make the recovery from mistakes easier, it is recommended that you make a copy of the original file before editing it.

12.1.5. Working with Modules

Being a modular application, the httpd service is distributed along with a number of Dynamic Shared Objects (DSOs), which can be dynamically loaded or unloaded at runtime as necessary. On Red Hat Enterprise Linux 7, these modules are located in /usr/lib64/httpd/modules/.

12.1.5.1. Loading a Module

To load a particular DSO module, use the LoadModule directive. Note that modules provided by a separate package often have their own configuration file in the /etc/httpd/conf.d/ directory.

Example 12.1. Loading the mod_ssl DSO

LoadModule ssl_module modules/mod_ssl.so
Once you are finished, restart the web server to reload the configuration. See Section 12.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.

12.1.5.2. Writing a Module

If you intend to create a new DSO module, make sure you have the httpd-devel package installed. To do so, enter the following command as root:
~]# yum install httpd-devel
This package contains the include files, the header files, and the APache eXtenSion (apxs) utility required to compile a module.
Once written, you can build the module with the following command:
~]# apxs -i -a -c module_name.c
If the build was successful, you should be able to load the module the same way as any other module that is distributed with the Apache HTTP Server.

12.1.6. Setting Up Virtual Hosts

The Apache HTTP Server's built in virtual hosting allows the server to provide different information based on which IP address, host name, or port is being requested.
To create a name-based virtual host, copy the example configuration file /usr/share/doc/httpd-VERSION/httpd-vhosts.conf into the /etc/httpd/conf.d/ directory, and replace the @@Port@@ and @@ServerRoot@@ placeholder values. Customize the options according to your requirements as shown in Example 12.2, “Example virtual host configuration”.

Example 12.2. Example virtual host configuration

<VirtualHost *:80>
    ServerAdmin webmaster@penguin.example.com
    DocumentRoot "/www/docs/penguin.example.com"
    ServerName penguin.example.com
    ServerAlias www.penguin.example.com
    ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
    CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>
Note that ServerName must be a valid DNS name assigned to the machine. The <VirtualHost> container is highly customizable, and accepts most of the directives available within the main server configuration. Directives that are not supported within this container include User and Group, which were replaced by SuexecUserGroup.

Note

If you configure a virtual host to listen on a non-default port, make sure you update the Listen directive in the global settings section of the /etc/httpd/conf/httpd.conf file accordingly.
To activate a newly created virtual host, the web server has to be restarted first. See Section 12.1.3.3, “Restarting the Service” for more information on how to restart the httpd service.

12.1.7. Setting Up an SSL Server

Secure Sockets Layer (SSL) is a cryptographic protocol that allows a server and a client to communicate securely. Along with its extended and improved version called Transport Layer Security (TLS), it ensures both privacy and data integrity. The Apache HTTP Server in combination with mod_ssl, a module that uses the OpenSSL toolkit to provide the SSL/TLS support, is commonly referred to as the SSL server. Red Hat Enterprise Linux also supports the use of Mozilla NSS as the TLS implementation. Support for Mozilla NSS is provided by the mod_nss module.
Unlike an HTTP connection that can be read and possibly modified by anybody who is able to intercept it, the use of SSL/TLS over HTTP, referred to as HTTPS, prevents any inspection or modification of the transmitted content. This section provides basic information on how to enable this module in the Apache HTTP Server configuration, and guides you through the process of generating private keys and self-signed certificates.

12.1.7.1. An Overview of Certificates and Security

Secure communication is based on the use of keys. In conventional or symmetric cryptography, both ends of the transaction have the same key they can use to decode each other's transmissions. On the other hand, in public or asymmetric cryptography, two keys co-exist: a private key that is kept a secret, and a public key that is usually shared with the public. While the data encoded with the public key can only be decoded with the private key, data encoded with the private key can in turn only be decoded with the public key.
To provide secure communications using SSL, an SSL server must use a digital certificate signed by a Certificate Authority (CA). The certificate lists various attributes of the server (that is, the server host name, the name of the company, its location, etc.), and the signature produced using the CA's private key. This signature ensures that a particular certificate authority has signed the certificate, and that the certificate has not been modified in any way.
When a web browser establishes a new SSL connection, it checks the certificate provided by the web server. If the certificate does not have a signature from a trusted CA, or if the host name listed in the certificate does not match the host name used to establish the connection, it refuses to communicate with the server and usually presents a user with an appropriate error message.
By default, most web browsers are configured to trust a set of widely used certificate authorities. Because of this, an appropriate CA should be chosen when setting up a secure server, so that target users can trust the connection, otherwise they will be presented with an error message, and will have to accept the certificate manually. Since encouraging users to override certificate errors can allow an attacker to intercept the connection, you should use a trusted CA whenever possible. For more information on this, see Table 12.2, “Information about CA lists used by common web browsers”.

Table 12.2. Information about CA lists used by common web browsers

When setting up an SSL server, you need to generate a certificate request and a private key, and then send the certificate request, proof of the company's identity, and payment to a certificate authority. Once the CA verifies the certificate request and your identity, it will send you a signed certificate you can use with your server. Alternatively, you can create a self-signed certificate that does not contain a CA signature, and thus should be used for testing purposes only.

12.1.8. Enabling the mod_ssl Module

If you intend to set up an SSL or HTTPS server using mod_ssl, you cannot have the another application or module, such as mod_nss configured to use the same port. Port 443 is the default port for HTTPS.
To set up an SSL server using the mod_ssl module and the OpenSSL toolkit, install the mod_ssl and openssl packages. Enter the following command as root:
~]# yum install mod_ssl openssl
This will create the mod_ssl configuration file at /etc/httpd/conf.d/ssl.conf, which is included in the main Apache HTTP Server configuration file by default. For the module to be loaded, restart the httpd service as described in Section 12.1.3.3, “Restarting the Service”.

Important

Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products Red Hat supports have the ability to use SSLv2 or SSLv3 protocols, or enable them by default. However, the use of SSLv2 or SSLv3 is now strongly recommended against.

12.1.8.1. Enabling and Disabling SSL and TLS in mod_ssl

To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the SSLProtocol directive in the ## SSL Global Context section of the configuration file and removing it everywhere else, or edit the default entry under # SSL Protocol support in all VirtualHost sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either only specify SSLProtocol in the SSL Global Context section, or specify it in all per-domain VirtualHost sections.

Procedure 12.1. Disable SSLv2 and SSLv3

To disable SSL version 2 and SSL version 3, which implies enabling everything except SSL version 2 and SSL version 3, in all VirtualHost sections, proceed as follows:
  1. As root, open the /etc/httpd/conf.d/ssl.conf file and search for all instances of the SSLProtocol directive. By default, the configuration file contains one section that looks as follows:
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
    This section is within the VirtualHost section.
  2. Edit the SSLProtocol line as follows:
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2 -SSLv3
    Repeat this action for all VirtualHost sections. Save and close the file.
  3. Verify that all occurrences of the SSLProtocol directive have been changed as follows:
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
    SSLProtocol all -SSLv2 -SSLv3
    This step is particularly important if you have more than the one default VirtualHost section.
  4. Restart the Apache daemon as follows:
    ~]# systemctl restart httpd
    Note that any sessions will be interrupted.

Procedure 12.2. Disable All SSL and TLS Protocols Except TLS 1 and Up

To disable all SSL and TLS protocol versions except TLS version 1 and higher, proceed as follows:
  1. As root, open the /etc/httpd/conf.d/ssl.conf file and search for all instances of SSLProtocol directive. By default the file contains one section that looks as follows:
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
  2. Edit the SSLProtocol line as follows:
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
    Save and close the file.
  3. Verify the change as follows:
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf 
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
  4. Restart the Apache daemon as follows:
    ~]# systemctl restart httpd
    Note that any sessions will be interrupted.

Procedure 12.3. Testing the Status of SSL and TLS Protocols

To check which versions of SSL and TLS are enabled or disabled, make use of the openssl s_client -connect command. The command has the following form:
openssl s_client -connect hostname:port -protocol
Where port is the port to test and protocol is the protocol version to test for. To test the SSL server running locally, use localhost as the host name. For example, to test the default port for secure HTTPS connections, port 443 to see if SSLv3 is enabled, issue a command as follows:
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    139809943877536:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
    139809943877536:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
    output omitted
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3
    output truncated
    The above output indicates that the handshake failed and therefore no cipher was negotiated.
  2. ~]$ openssl s_client -connect localhost:443 -tls1_2
    CONNECTED(00000003)
    depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = localhost.localdomain, emailAddress = root@localhost.localdomain
    output omitted
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1.2
    output truncated
    The above output indicates that no failure of the handshake occurred and a set of ciphers was negotiated.
The openssl s_client command options are documented in the s_client(1) manual page.
For more information on the SSLv3 vulnerability and how to test for it, see the Red Hat Knowledgebase article POODLE: SSLv3 vulnerability (CVE-2014-3566).

12.1.9. Enabling the mod_nss Module

If you intend to set up an HTTPS server using mod_nss, you cannot have the mod_ssl package installed with its default settings as mod_ssl will use port 443 by default, however this is the default HTTPS port. If at all possible, remove the package.
To remove mod_ssl, enter the following command as root:
~]# yum remove mod_ssl

Note

If mod_ssl is required for other purposes, modify the /etc/httpd/conf.d/ssl.conf file to use a port other than 443 to prevent mod_ssl conflicting with mod_nss when its port to listen on is changed to 443.
Only one module can own a port, therefore mod_nss and mod_ssl can only co-exist at the same time if they use unique ports. For this reason mod_nss by default uses 8443, but the default port for HTTPS is port 443. The port is specified by the Listen directive as well as in the VirtualHost name or address.
Everything in NSS is associated with a token. The software token exists in the NSS database but you can also have a physical token containing certificates. With OpenSSL, discrete certificates and private keys are held in PEM files. With NSS, these are stored in a database. Each certificate and key is associated with a token and each token can have a password protecting it. This password is optional, but if a password is used then the Apache HTTP server needs a copy of it in order to open the database without user intervention at system start.

Procedure 12.4. Configuring mod_nss

  1. Install mod_nss as root:
    ~]# yum install mod_nss
    This will create the mod_nss configuration file at /etc/httpd/conf.d/nss.conf. The /etc/httpd/conf.d/ directory is included in the main Apache HTTP Server configuration file by default. For the module to be loaded, restart the httpd service as described in Section 12.1.3.3, “Restarting the Service”.
  2. As root, open the /etc/httpd/conf.d/nss.conf file and search for all instances of the Listen directive.
    Edit the Listen 8443 line as follows:
    Listen 443
    Port 443 is the default port for HTTPS.
  3. Edit the default VirtualHost _default_:8443 line as follows:
    VirtualHost _default_:443
    Edit any other non-default virtual host sections if they exist. Save and close the file.
  4. Mozilla NSS stores certificates in a server certificate database indicated by the NSSCertificateDatabase directive in the /etc/httpd/conf.d/nss.conf file. By default the path is set to /etc/httpd/alias, the NSS database created during installation.
    To view the default NSS database, issue a command as follows:
    ~]# certutil -L -d /etc/httpd/alias
    
    Certificate Nickname                                         Trust Attributes
                                                                 SSL,S/MIME,JAR/XPI
    
    cacert                                                       CTu,Cu,Cu
    Server-Cert                                                  u,u,u
    alpha                                                        u,pu,u
    In the above command output, Server-Cert is the default NSSNickname. The -L option lists all the certificates, or displays information about a named certificate, in a certificate database. The -d option specifies the database directory containing the certificate and key database files. See the certutil(1) man page for more command line options.
  5. To configure mod_nss to use another database, edit the NSSCertificateDatabase line in the /etc/httpd/conf.d/nss.conf file. The default file has the following lines within the VirtualHost section.
    #   Server Certificate Database:
    #   The NSS security database directory that holds the certificates and
    #   keys. The database consists of 3 files: cert8.db, key3.db and secmod.db.
    #   Provide the directory that these files exist.
    NSSCertificateDatabase /etc/httpd/alias
    In the above command output, alias is the default NSS database directory, /etc/httpd/alias/.
  6. To apply a password to the default NSS certificate database, use the following command as root:
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
    Password changed successfully.
  7. Before deploying the HTTPS server, create a new certificate database using a certificate signed by a certificate authority (CA).

    Example 12.3. Adding a Certificate to the Mozilla NSS database

    The certutil command is used to add a CA certificate to the NSS database files:
    certutil -d /etc/httpd/nss-db-directory/ -A -n "CA_certificate" -t CT,, -a -i certificate.pem
    The above command adds a CA certificate stored in a PEM-formatted file named certificate.pem. The -d option specifies the NSS database directory containing the certificate and key database files, the -n option sets a name for the certificate, -t CT,, means that the certificate is trusted to be used in TLS clients and servers. The -A option adds an existing certificate to a certificate database. If the database does not exist it will be created. The -a option allows the use of ASCII format for input or output, and the -i option passes the certificate.pem input file to the command.
    See the certutil(1) man page for more command line options.
  8. The NSS database should be password protected to safeguard the private key.

    Example 12.4. Setting a Password for a Mozilla NSS database

    The certutil tool can be used set a password for an NSS database as follows:
    certutil -W -d /etc/httpd/nss-db-directory/
    For example, for the default database, issue a command as root as follows:
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password: 
    Re-enter password: 
    Password changed successfully.
  9. Configure mod_nss to use the NSS internal software token by changing the line with the NSSPassPhraseDialog directive as follows:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSPassPhraseDialog file:/etc/httpd/password.conf
    This is to avoid manual password entry on system start. The software token exists in the NSS database but you can also have a physical token containing your certificates.
  10. If the SSL Server Certificate contained in the NSS database is an RSA certificate, make certain that the NSSNickname parameter is uncommented and matches the nickname displayed in step 4 above:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSNickname Server-Cert
    If the SSL Server Certificate contained in the NSS database is an ECC certificate, make certain that the NSSECCNickname parameter is uncommented and matches the nickname displayed in step 4 above:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSECCNickname Server-Cert
    Make certain that the NSSCertificateDatabase parameter is uncommented and points to the NSS database directory displayed in step 4 or configured in step 5 above:
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSCertificateDatabase /etc/httpd/alias
    Replace /etc/httpd/alias with the path to the certificate database to be used.
  11. Create the /etc/httpd/password.conf file as root:
    ~]# vi /etc/httpd/password.conf
    Add a line with the following form:
    internal:password
    Replacing password with the password that was applied to the NSS security databases in step 6 above.
  12. Apply the appropriate ownership and permissions to the /etc/httpd/password.conf file:
    ~]# chgrp apache /etc/httpd/password.conf
    ~]# chmod 640 /etc/httpd/password.conf
    ~]# ls -l /etc/httpd/password.conf
    -rw-r-----. 1 root apache 10 Dec  4 17:13 /etc/httpd/password.conf
  13. To configure mod_nss to use the NSS the software token in /etc/httpd/password.conf, edit /etc/httpd/conf.d/nss.conf as follows:
    ~]# vi /etc/httpd/conf.d/nss.conf
  14. Restart the Apache server for the changes to take effect as described in Section 12.1.3.3, “Restarting the Service”

Important

Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommends disabling SSL and using only TLSv1.1 or TLSv1.2. Backwards compatibility can be achieved using TLSv1.0. Many products Red Hat supports have the ability to use SSLv2 or SSLv3 protocols, or enable them by default. However, the use of SSLv2 or SSLv3 is now strongly recommended against.

12.1.9.1. Enabling and Disabling SSL and TLS in mod_nss

To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the NSSProtocol directive in the ## SSL Global Context section of the configuration file and removing it everywhere else, or edit the default entry under # SSL Protocol in all VirtualHost sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either only specify NSSProtocol in the SSL Global Context section, or specify it in all per-domain VirtualHost sections.

Procedure 12.5. Disable All SSL and TLS Protocols Except TLS 1 and Up in mod_nss

To disable all SSL and TLS protocol versions except TLS version 1 and higher, proceed as follows:
  1. As root, open the /etc/httpd/conf.d/nss.conf file and search for all instances of the NSSProtocol directive. By default, the configuration file contains one section that looks as follows:
    ~]# vi /etc/httpd/conf.d/nss.conf
    #   SSL Protocol:
    output omitted
    #   Since all protocol ranges are completely inclusive, and no protocol in the
    #   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
    #   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
    NSSProtocol SSLv3,TLSv1.0,TLSv1.1
    This section is within the VirtualHost section.
  2. Edit the NSSProtocol line as follows:
    #   SSL Protocol:
    NSSProtocol TLSv1.0,TLSv1.1
    Repeat this action for all VirtualHost sections.
  3. Edit the Listen 8443 line as follows:
    Listen 443
  4. Edit the default VirtualHost _default_:8443 line as follows:
    VirtualHost _default_:443
    Edit any other non-default virtual host sections if they exist. Save and close the file.
  5. Verify that all occurrences of the NSSProtocol directive have been changed as follows:
    ~]# grep NSSProtocol /etc/httpd/conf.d/nss.conf
    #   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
    #   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
    NSSProtocol TLSv1.0,TLSv1.1
    This step is particularly important if you have more than one VirtualHost section.
  6. Restart the Apache daemon as follows:
    ~]# service httpd restart
    Note that any sessions will be interrupted.

Procedure 12.6. Testing the Status of SSL and TLS Protocols in mod_nss

To check which versions of SSL and TLS are enabled or disabled in mod_nss, make use of the openssl s_client -connect command. Install the openssl package as root:
~]# yum install openssl
The openssl s_client -connect command has the following form:
openssl s_client -connect hostname:port -protocol
Where port is the port to test and protocol is the protocol version to test for. To test the SSL server running locally, use localhost as the host name. For example, to test the default port for secure HTTPS connections, port 443 to see if SSLv3 is enabled, issue a command as follows:
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    3077773036:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
    output omitted
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3
    output truncated
    The above output indicates that the handshake failed and therefore no cipher was negotiated.
  2. ~]$ openssl s_client -connect localhost:443 -tls1
    CONNECTED(00000003)
    depth=1 C = US, O = example.com, CN = Certificate Shack
    output omitted
    New, TLSv1/SSLv3, Cipher is AES128-SHA
    Server public key is 1024 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1
    output truncated
    The above output indicates that no failure of the handshake occurred and a set of ciphers was negotiated.
The openssl s_client command options are documented in the s_client(1) manual page.
For more information on the SSLv3 vulnerability and how to test for it, see the Red Hat Knowledgebase article POODLE: SSLv3 vulnerability (CVE-2014-3566).

12.1.10. Using an Existing Key and Certificate

If you have a previously created key and certificate, you can configure the SSL server to use these files instead of generating new ones. There are only two situations where this is not possible:
  1. You are changing the IP address or domain name.
    Certificates are issued for a particular IP address and domain name pair. If one of these values changes, the certificate becomes invalid.
  2. You have a certificate from VeriSign, and you are changing the server software.
    VeriSign, a widely used certificate authority, issues certificates for a particular software product, IP address, and domain name. Changing the software product renders the certificate invalid.
In either of the above cases, you will need to obtain a new certificate. For more information on this topic, see Section 12.1.11, “Generating a New Key and Certificate”.
If you want to use an existing key and certificate, move the relevant files to the /etc/pki/tls/private/ and /etc/pki/tls/certs/ directories respectively. You can do so by issuing the following commands as root:
~]# mv key_file.key /etc/pki/tls/private/hostname.key
~]# mv certificate.crt /etc/pki/tls/certs/hostname.crt
Then add the following lines to the /etc/httpd/conf.d/ssl.conf configuration file:
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
To load the updated configuration, restart the httpd service as described in Section 12.1.3.3, “Restarting the Service”.

Example 12.5. Using a key and certificate from the Red Hat Secure Web Server

~]# mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/penguin.example.com.key
~]# mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/penguin.example.com.crt

12.1.11. Generating a New Key and Certificate

In order to generate a new key and certificate pair, the crypto-utils package must be installed on the system. To install it, enter the following command as root:
~]# yum install crypto-utils
This package provides a set of tools to generate and manage SSL certificates and private keys, and includes genkey, the Red Hat Keypair Generation utility that will guide you through the key generation process.

Important

If the server already has a valid certificate and you are replacing it with a new one, specify a different serial number. This ensures that client browsers are notified of this change, update to this new certificate as expected, and do not fail to access the page. To create a new certificate with a custom serial number, as root, use the following command instead of genkey:
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt

Note

If there already is a key file for a particular host name in your system, genkey will refuse to start. In this case, remove the existing file using the following command as root:
~]# rm /etc/pki/tls/private/hostname.key
To run the utility enter the genkey command as root, followed by the appropriate host name (for example, penguin.example.com):
~]# genkey hostname
To complete the key and certificate creation, take the following steps:
  1. Review the target locations in which the key and certificate will be stored.
    Running the genkey utility

    Figure 12.1. Running the genkey utility

    Use the Tab key to select the Next button, and press Enter to proceed to the next screen.
  2. Using the up and down arrow keys, select a suitable key size. Note that while a larger key increases the security, it also increases the response time of your server. The NIST recommends using 2048 bits. See NIST Special Publication 800-131A.
    Selecting the key size

    Figure 12.2. Selecting the key size

    Once finished, use the Tab key to select the Next button, and press Enter to initiate the random bits generation process. Depending on the selected key size, this may take some time.
  3. Decide whether you want to send a certificate request to a certificate authority.
    Generating a certificate request

    Figure 12.3. Generating a certificate request

    Use the Tab key to select Yes to compose a certificate request, or No to generate a self-signed certificate. Then press Enter to confirm your choice.
  4. Using the Spacebar key, enable ([*]) or disable ([ ]) the encryption of the private key.
    Encrypting the private key

    Figure 12.4. Encrypting the private key

    Use the Tab key to select the Next button, and press Enter to proceed to the next screen.
  5. If you have enabled the private key encryption, enter an adequate passphrase. Note that for security reasons, it is not displayed as you type, and it must be at least five characters long.
    Entering a passphrase

    Figure 12.5. Entering a passphrase

    Use the Tab key to select the Next button, and press Enter to proceed to the next screen.

    Important

    Entering the correct passphrase is required in order for the server to start. If you lose it, you will need to generate a new key and certificate.
  6. Customize the certificate details.
    Specifying certificate information

    Figure 12.6. Specifying certificate information

    Use the Tab key to select the Next button, and press Enter to finish the key generation.
  7. If you have previously enabled the certificate request generation, you will be prompted to send it to a certificate authority.
    Instructions on how to send a certificate request

    Figure 12.7. Instructions on how to send a certificate request

    Press Enter to return to a shell prompt.
Once generated, add the key and certificate locations to the /etc/httpd/conf.d/ssl.conf configuration file:
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
Finally, restart the httpd service as described in Section 12.1.3.3, “Restarting the Service”, so that the updated configuration is loaded.

12.1.12. Configure the Firewall for HTTP and HTTPS Using the Command Line

Red Hat Enterprise Linux does not allow HTTP and HTTPS traffic by default. To enable the system to act as a web server, make use of firewalld's supported services to enable HTTP and HTTPS traffic to pass through the firewall as required.
To enable HTTP using the command line, issue the following command as root:
~]# firewall-cmd --add-service http
 success
To enable HTTPS using the command line, issue the following command as root:
~]# firewall-cmd --add-service https
 success
Note that these changes will not persist after the next system start. To make permanent changes to the firewall, repeat the commands adding the --permanent option.

12.1.12.1. Checking Network Access for Incoming HTTPS and HTTPS Using the Command Line

To check what services the firewall is configured to allow, using the command line, issue the following command as root:
~]# firewall-cmd --list-all
public (default, active)
  interfaces: em1
  sources: 
  services: dhcpv6-client ssh
output truncated
In this example taken from a default installation, the firewall is enabled but HTTP and HTTPS have not been allowed to pass through.
Once the HTTP and HTTP firewall services are enabled, the services line will appear similar to the following:
services: dhcpv6-client http https ssh
For more information on enabling firewall services, or opening and closing ports with firewalld, see the Red Hat Enterprise Linux 7 Security Guide.

12.1.13. Additional Resources

To learn more about the Apache HTTP Server, see the following resources.

Installed Documentation

  • httpd(8) — The manual page for the httpd service containing the complete list of its command-line options.
  • genkey(1) — The manual page for genkey utility, provided by the crypto-utils package.
  • apachectl(8) — The manual page for the Apache HTTP Server Control Interface.

Installable Documentation

  • http://localhost/manual/ — The official documentation for the Apache HTTP Server with the full description of its directives and available modules. Note that in order to access this documentation, you must have the httpd-manual package installed, and the web server must be running.
    Before accessing the documentation, issue the following commands as root:
    ~]# yum install httpd-manual
    ~]# apachectl graceful

Online Documentation

  • http://httpd.apache.org/ — The official website for the Apache HTTP Server with documentation on all the directives and default modules.
  • http://www.openssl.org/ — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.