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 Important 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 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 and systemctl commands to control the service, in place of the service command. The following examples are specific to the httpd service. The command: is replaced by 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: is replaced by 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 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 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 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 . 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 the UserDir directive indicating a directory name (typically public_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: 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: 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 : If you want the service to start automatically at boot time, use the following command: 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. 14.1.3.2. Stopping the Service To stop the running httpd service, type the following at a shell prompt as root : To prevent the service from starting automatically at boot time, type: 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 : 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: 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 : 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: 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" . Table 14.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 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: 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 ( DSO s), 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 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 : 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: 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 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 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" . Table 14.2. Information about CA lists used by common web browsers Web Browser Link Mozilla Firefox Mozilla root CA list . Opera Information on root certificates used by Opera . Internet Explorer Information on root certificates used by Microsoft Windows . 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 : 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" . 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. 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 the SSLProtocol directive. By default, the configuration file contains one section that looks as follows: This section is within the VirtualHost section. Edit the SSLProtocol line as follows: 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: This step is particularly important if you have more than the one default VirtualHost section. Restart the Apache daemon as follows: 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 of SSLProtocol directive. By default the file contains one section that looks as follows: Edit the SSLProtocol line as follows: Save and close the file. Verify the change as follows: Restart the Apache daemon as follows: 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: 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: The above output indicates that the handshake failed and therefore no cipher was negotiated. 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 : 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. Configuring mod_nss Install mod_nss as root : 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 14.1.3.3, "Restarting the Service" . 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: Port 443 is the default port for HTTPS . Edit the default VirtualHost default :8443 line as follows: 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: 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. 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. 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 : 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: 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. 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: For example, for the default database, issue a command as root as follows: Configure mod_nss to use the NSS internal software token by changing the line with the NSSPassPhraseDialog directive as follows: 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: 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: 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: Replace /etc/httpd/alias with the path to the certificate database to be used. Create the /etc/httpd/password.conf file as root : Add a line with the following form: 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: 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: Restart the Apache server for the changes to take effect as described in Section 14.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. 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 the NSSProtocol directive. By default, the configuration file contains one section that looks as follows: This section is within the VirtualHost section. Edit the NSSProtocol line as follows: Repeat this action for all VirtualHost sections. Edit the Listen 8443 line as follows: Edit the default VirtualHost default :8443 line as follows: 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: This step is particularly important if you have more than one VirtualHost section. Restart the Apache daemon as follows: 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 : The openssl s_client -connect command has the following form: 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: The above output indicates that the handshake failed and therefore no cipher was negotiated. 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 : Then add the following lines to the /etc/httpd/conf.d/ssl.conf configuration file: 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 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 : 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 : 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 : To run the utility enter the genkey command as root , followed by the appropriate host name (for example, penguin.example.com ): 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 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 Yes to compose a certificate request, or No 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 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 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. 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: 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 : To enable HTTPS using the command line, issue the following command as root : Note that these changes will not persist after the 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 : 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: 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 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 : 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.

Commands:
service httpd graceful
apachectl graceful
service httpd configtest
apachectl configtest
~]# apachectl configtest Syntax OK
~]# yum install httpd
~]# systemctl start httpd.service
~]# systemctl enable httpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
~]# systemctl stop httpd.service
~]# systemctl disable httpd.service Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.
~]# systemctl restart httpd.service
~]# systemctl reload httpd.service
~]# apachectl graceful
~]# systemctl is-active httpd.service active
~]# apachectl configtest Syntax OK
LoadModule ssl_module modules/mod_ssl.so
~]# yum install httpd-devel
~]# apxs -i -a -c module_name.c
<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>
~]# yum install mod_ssl openssl
~]# 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
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
~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf SSLProtocol all -SSLv2 -SSLv3
~]# systemctl restart httpd
~]# 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
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
~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
~]# systemctl restart httpd
openssl s_client -connect hostname : port - protocol
~]# 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
~]USD 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
~]# yum remove mod_ssl
~]# yum install mod_nss
Listen 443
VirtualHost default :443
~]# 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
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
~]# 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.
certutil -d /etc/httpd/nss-db-directory/ -A -n " CA_certificate " -t CT,, -a -i certificate.pem
certutil -W -d /etc/httpd/ nss-db-directory /
~]# 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.
~]# vi /etc/httpd/conf.d/nss.conf NSSPassPhraseDialog file:/etc/httpd/password.conf
~]# vi /etc/httpd/conf.d/nss.conf NSSNickname Server-Cert
~]# vi /etc/httpd/conf.d/nss.conf NSSECCNickname Server-Cert
~]# vi /etc/httpd/conf.d/nss.conf NSSCertificateDatabase /etc/httpd/alias
~]# vi /etc/httpd/password.conf
internal: password
~]# 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
~]# vi /etc/httpd/conf.d/nss.conf
~]# 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
SSL Protocol: NSSProtocol TLSv1.0,TLSv1.1
Listen 443
VirtualHost default :443
~]# 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
~]# service httpd restart
~]# yum install openssl
openssl s_client -connect hostname : port - protocol
~]# 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
~]USD 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
~]# mv key_file.key /etc/pki/tls/private/hostname.key ~]# mv certificate.crt /etc/pki/tls/certs/hostname.crt
SSLCertificateFile /etc/pki/tls/certs/ hostname .crt SSLCertificateKeyFile /etc/pki/tls/private/ hostname .key
~]# 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
~]# yum install crypto-utils
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt
~]# rm /etc/pki/tls/private/hostname.key
~]# genkey hostname
SSLCertificateFile /etc/pki/tls/certs/ hostname .crt SSLCertificateKeyFile /etc/pki/tls/private/ hostname .key
~]# firewall-cmd --add-service http success
~]# firewall-cmd --add-service https success
~]# firewall-cmd --list-all public (default, active) interfaces: em1 sources: services: dhcpv6-client ssh output truncated
services: dhcpv6-client http https ssh
~] yum install httpd-manual ~] apachectl graceful