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

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

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/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 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.

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.

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:

14.1.3.3. Restarting the 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.

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.

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”.

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.

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”.

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”.

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.

Procedure 14.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:

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.

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:

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:

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

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 14.4. 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 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:

Listen 443

Port 443 is the default port for HTTPS.

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.

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:

~]# 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:

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, -tCT,, 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:

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 the NSSPassPhraseDialog directive as follows:

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.

Procedure 14.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:

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.

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.

Procedure 14.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:

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:

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.

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:

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):

~]# genkeyhostname

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 Next 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 Next 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 Next 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 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.

Customize the certificate details.

Figure 14.6. Specifying certificate information

Use the Tab key to select the Next 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:

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:

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:

~]# 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.

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.