Chapter 14. 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).
The web servers available in Red Hat Enterprise Linux 7 are:
- Apache HTTP Server
- nginx
Note that the nginx web server is available only as a Software Collection for Red Hat Enterprise Linux 7. See the Red Hat Software Collections Release Notes for information regarding getting access to nginx, usage of Software Collections, and other.
14.1. The Apache HTTP Server
This section focuses on the Apache HTTP Server 2.4, 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.
14.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
andsystemctl
commands to control the service, in place of theservice
command. The following examples are specific to thehttpd
service.The command:
service httpd graceful
is replaced by
apachectl graceful
The
systemd
unit file forhttpd
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 thehttpd
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 forhttpd
, such as php, will place a file in this directory. AnInclude
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 withinconf.modules.d/
are processed before the main body ofhttpd.conf
. AnIncludeOptional
directive for files within the/etc/httpd/conf.d/
directory is placed at the end of thehttpd.conf
file. This means the files within/etc/httpd/conf.d/
are now processed after the main body ofhttpd.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 asTimeout
orKeepAlive
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 the section called “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.
NoteBefore 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 aproxy
andssl
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 forhttpd
. 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
andAllow
directives should be adapted to use the newRequire
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 version2.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.
14.1.2. Updating the Configuration
To update the configuration files from the Apache HTTP Server version 2.2, take the following steps:
-
Make sure all module names are correct, since they may have changed. Adjust the
LoadModule
directive for each module that has been renamed. - Recompile all third party modules before attempting to load them. This typically means authentication and authorization modules.
-
If you use the
mod_userdir
module, make sure theUserDir
directive indicating a directory name (typicallypublic_html
) is provided. - If you use the Apache HTTP Secure Server, see Section 14.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.
14.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 10, Managing Services with systemd.
14.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.
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.
14.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.
14.1.3.3. Restarting the Service
There are three different ways to restart a running httpd
service:
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.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.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 10, Managing Services with systemd.
14.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
14.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 14.1, “The httpd service configuration files”.
Path | Description |
---|---|
| The main configuration file. |
| 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 14.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.
14.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/
.
14.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 14.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 14.1.3.3, “Restarting the Service” for more information on how to restart the httpd
service.
14.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.
14.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 14.2, “Example virtual host configuration”.
Example 14.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
.
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 14.1.3.3, “Restarting the Service” for more information on how to restart the httpd
service.
14.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.
14.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 14.2, “Information about CA lists used by common web browsers”.
Web Browser | Link |
---|---|
Mozilla Firefox | |
Opera | |
Internet Explorer | |
Chromium | Information on root certificates used by the Chromium project. |
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.
14.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 14.1.3.3, “Restarting the Service”.
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.
14.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.
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:
As
root
, open the/etc/httpd/conf.d/ssl.conf
file and search for all instances of theSSLProtocol
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.
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.
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.
Restart the Apache daemon as follows:
~]# systemctl restart httpd
Note that any sessions will be interrupted.
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:
As
root
, open the/etc/httpd/conf.d/ssl.conf
file and search for all instances ofSSLProtocol
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
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.
Verify the change as follows:
~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
Restart the Apache daemon as follows:
~]# systemctl restart httpd
Note that any sessions will be interrupted.
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:
~]# 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.
~]$ 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).
14.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
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.
Configuring mod_nss
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 thehttpd
service as described in Section 14.1.3.3, “Restarting the Service”.As
root
, open the/etc/httpd/conf.d/nss.conf
file and search for all instances of theListen
directive.Edit the
Listen 8443
line as follows:Listen 443
Port
443
is the default port forHTTPS
.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.
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 defaultNSSNickname
. 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 thecertutil(1)
man page for more command line options.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/
.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.
Before deploying the HTTPS server, create a new certificate database using a certificate signed by a certificate authority (CA).
Example 14.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" -tCT,,
-a -icertificate.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 thecertificate.pem
input file to the command.See the
certutil(1)
man page for more command line options.The NSS database should be password protected to safeguard the private key.
Example 14.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.
Configure
mod_nss
to use the NSS internal software token by changing the line with theNSSPassPhraseDialog
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.
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.Create the
/etc/httpd/password.conf
file asroot
:~]# 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.
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
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
- Restart the Apache server for the changes to take effect as described in Section 14.1.3.3, “Restarting the Service”
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.
14.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.
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:
As
root
, open the/etc/httpd/conf.d/nss.conf
file and search for all instances of theNSSProtocol
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.
Edit the
NSSProtocol
line as follows:# SSL Protocol: NSSProtocol TLSv1.0,TLSv1.1
Repeat this action for all VirtualHost sections.
Edit the
Listen 8443
line as follows:Listen 443
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.
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.
Restart the Apache daemon as follows:
~]# service httpd restart
Note that any sessions will be interrupted.
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:
~]# 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.
~]$ 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).
14.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:
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.
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 14.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
:
~]# mvkey_file.key
/etc/pki/tls/private/hostname.key
~]# mvcertificate.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 14.1.3.3, “Restarting the Service”.
Example 14.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
14.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.
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
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:
Review the target locations in which the key and certificate will be stored.
Figure 14.1. Running the genkey utility
Use the Tab key to select the
button, and press Enter to proceed to the next screen.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.Figure 14.2. Selecting the key size
Once finished, use the Tab key to select the
button, and press Enter to initiate the random bits generation process. Depending on the selected key size, this may take some time.Decide whether you want to send a certificate request to a certificate authority.
Figure 14.3. Generating a certificate request
Use the Tab key to select
to compose a certificate request, or to generate a self-signed certificate. Then press Enter to confirm your choice.Using the Spacebar key, enable (
[*]
) or disable ([ ]
) the encryption of the private key.Figure 14.4. Encrypting the private key
Use the Tab key to select the
button, and press Enter to proceed to the next screen.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.
Figure 14.5. Entering a passphrase
Use the Tab key to select the
button, and press Enter to proceed to the next screen.ImportantEntering 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.
Customize the certificate details.
Figure 14.6. Specifying certificate information
Use the Tab key to select the
button, and press Enter to finish the key generation.If you have previously enabled the certificate request generation, you will be prompted to send it to a certificate authority.
Figure 14.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 14.1.3.3, “Restarting the Service”, so that the updated configuration is loaded.
14.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.
14.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.
14.1.13. Additional Resources
To learn more about the Apache HTTP Server, see the following resources.
Installed Documentation
-
httpd(8)
— The manual page for thehttpd
service containing the complete list of its command-line options. -
genkey(1)
— The manual page forgenkey
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.