Chapter 18. Web Servers
Chapter 18. Web Servers HTTP (Hypertext Transfer Protocol) server, or 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. The web servers available in Red Hat Enterprise Linux 6 are: Apache HTTP Server nginx Important Note that the nginx web server is available only as a Software Collection for Red Hat Enterprise Linux 6. See the Red Hat Software Collections Release Notes for information regarding getting access to nginx, usage of Software Collections, and other. 18.1. The Apache HTTP Server This section focuses on the Apache HTTP Server 2.2 , a robust, full-featured open source web server developed by the Apache Software Foundation , that is included in Red Hat Enterprise Linux 6. It describes the basic configuration of the httpd service, and covers advanced topics such as adding server modules, setting up virtual hosts, or configuring the secure HTTP server. There are important differences between the Apache HTTP Server 2.2 and version 2.0, and 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, and guides you through the update of older configuration files. 18.1.1. New Features The Apache HTTP Server version 2.2 introduces the following enhancements: Improved caching modules, that is, mod_cache and mod_disk_cache . Support for proxy load balancing, that is, the mod_proxy_balancer module. Support for large files on 32-bit architectures, allowing the web server to handle files greater than 2GB. A new structure for authentication and authorization support, replacing the authentication modules provided in versions. 18.1.2. Notable Changes Since version 2.0, few changes have been made to the default httpd service configuration: The following modules are no longer loaded by default: mod_cern_meta and mod_asis . The following module is newly loaded by default: mod_ext_filter . 18.1.3. Updating the Configuration To update the configuration files from the Apache HTTP Server version 2.0, 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 18.1.9, "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.0 to 2.2, see http://httpd.apache.org/docs/2.2/upgrading.html . 18.1.4. 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 runlevels and how to manage system services in Red Hat Enterprise Linux in general, see Chapter 12, Services and Daemons . 18.1.4.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 the boot time, use the following command: This will enable the service for runlevel 2, 3, 4, and 5. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, "Enabling and Disabling a Service" . Note If running the Apache HTTP Server as a secure server, a password may be required after the machine boots if using an encrypted private SSL key. 18.1.4.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 the boot time, type: This will disable the service for all runlevels. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, "Enabling and Disabling a Service" . 18.1.4.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 being currently 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 being currently processed will use the old configuration. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.2, "Starting, Restarting, and Stopping a Service" . 18.1.4.4. Verifying the Service Status To verify that the httpd service is running, type the following at a shell prompt: Alternatively, you can use the Service Configuration utility as described in Section 12.2.1, "Using the Service Configuration Utility" . 18.1.5. Editing the Configuration Files When the httpd service is started, by default, it reads the configuration from locations that are listed in Table 18.1, "The httpd service configuration files" . Table 18.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 18.1.4.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. 18.1.5.1. Common httpd.conf Directives The following directives are commonly used in the /etc/httpd/conf/httpd.conf configuration file: <Directory> The <Directory> directive allows you to apply certain directives to a particular directory only. It takes the following form: The directory can be either a full path to an existing directory in the local file system, or a wildcard expression. This directive can be used to configure additional cgi-bin directories for server-side scripts located outside the directory that is specified by ScriptAlias . In this case, the ExecCGI and AddHandler directives must be supplied, and the permissions on the target directory must be set correctly (that is, 0755 ). Example 18.1. Using the <Directory> directive <IfDefine> The IfDefine directive allows you to use certain directives only when a particular parameter is supplied on the command line. It takes the following form: The parameter can be supplied at a shell prompt using the -D parameter command-line option (for example, httpd -DEnableHome ). If the optional exclamation mark (that is, ! ) is present, the enclosed directives are used only when the parameter is not specified. Example 18.2. Using the <IfDefine> directive <IfModule> The <IfModule> directive allows you to use certain directive only when a particular module is loaded. It takes the following form: The module can be identified either by its name, or by the file name. If the optional exclamation mark (that is, ! ) is present, the enclosed directives are used only when the module is not loaded. Example 18.3. Using the <IfModule> directive <Location> The <Location> directive allows you to apply certain directives to a particular URL only. It takes the following form: The url can be either a path relative to the directory specified by the DocumentRoot directive (for example, /server-info ), or an external URL such as http://example.com/server-info . Example 18.4. Using the <Location> directive <Proxy> The <Proxy> directive allows you to apply certain directives to the proxy server only. It takes the following form: The pattern can be an external URL, or a wildcard expression (for example, http://example.com/* ). Example 18.5. Using the <Proxy> directive <VirtualHost> The <VirtualHost> directive allows you apply certain directives to particular virtual hosts only. It takes the following form: The address can be an IP address, a fully qualified domain name, or a special form as described in Table 18.2, "Available <VirtualHost> options" . Table 18.2. Available <VirtualHost> options Option Description * Represents all IP addresses. _default_ Represents unmatched IP addresses. Example 18.6. Using the <VirtualHost> directive AccessFileName The AccessFileName directive allows you to specify the file to be used to customize access control information for each directory. It takes the following form: The filename is a name of the file to look for in the requested directory. By default, the server looks for .htaccess . For security reasons, the directive is typically followed by the Files tag to prevent the files beginning with .ht from being accessed by web clients. This includes the .htaccess and .htpasswd files. Example 18.7. Using the AccessFileName directive Action The Action directive allows you to specify a CGI script to be executed when a certain media type is requested. It takes the following form: The content-type has to be a valid MIME type such as text/html , image/png , or application/pdf . The path refers to an existing CGI script, and must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/process-image.cgi ). Example 18.8. Using the Action directive AddDescription The AddDescription directive allows you to specify a short description to be displayed in server-generated directory listings for a given file. It takes the following form: The description should be a short text enclosed in double quotes (that is, " ). The filename can be a full file name, a file extension, or a wildcard expression. Example 18.9. Using the AddDescription directive AddEncoding The AddEncoding directive allows you to specify an encoding type for a particular file extension. It takes the following form: The encoding has to be a valid MIME encoding such as x-compress , x-gzip , etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .gz ). This directive is typically used to instruct web browsers to decompress certain file types as they are downloaded. Example 18.10. Using the AddEncoding directive AddHandler The AddHandler directive allows you to map certain file extensions to a selected handler. It takes the following form: The handler has to be a name of a previously defined handler. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cgi ). This directive is typically used to treat files with the .cgi extension as CGI scripts regardless of the directory they are in. Additionally, it is also commonly used to process server-parsed HTML and image-map files. Example 18.11. Using the AddHandler option AddIcon The AddIcon directive allows you to specify an icon to be displayed for a particular file in server-generated directory listings. It takes the following form: The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/folder.png ). The pattern can be a file name, a file extension, a wildcard expression, or a special form as described in the following table: Table 18.3. Available AddIcon options Option Description ^^DIRECTORY^^ Represents a directory. ^^BLANKICON^^ Represents a blank line. Example 18.12. Using the AddIcon directive AddIconByEncoding The AddIconByEncoding directive allows you to specify an icon to be displayed for a particular encoding type in server-generated directory listings. It takes the following form: The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/compressed.png ). The encoding has to be a valid MIME encoding such as x-compress , x-gzip , etc. Example 18.13. Using the AddIconByEncoding directive AddIconByType The AddIconByType directive allows you to specify an icon to be displayed for a particular media type in server-generated directory listings. It takes the following form: The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/text.png ). The content-type has to be either a valid MIME type (for example, text/html or image/png ), or a wildcard expression such as text/* , image/* , etc. Example 18.14. Using the AddIconByType directive AddLanguage The AddLanguage directive allows you to associate a file extension with a specific language. It takes the following form: The language has to be a valid MIME language such as cs , en , or fr . The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs ). This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings. Example 18.15. Using the AddLanguage directive AddType The AddType directive allows you to define or override the media type for a particular file extension. It takes the following form: The content-type has to be a valid MIME type such as text/html , image/png , etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs ). Example 18.16. Using the AddType directive Alias The Alias directive allows you to refer to files and directories outside the default directory specified by the DocumentRoot directive. It takes the following form: The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /images/ ). The real-path is a full path to a file or directory in the local file system. This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /icons/ alias is created so that the icons from /var/www/icons/ are displayed in server-generated directory listings. Example 18.17. Using the Alias directive Allow The Allow directive allows you to specify which clients have permission to access a given directory. It takes the following form: The client can be a domain name, an IP address (both full and partial), a network / netmask pair, or all for all clients. Example 18.18. Using the Allow directive AllowOverride The AllowOverride directive allows you to specify which directives in a .htaccess file can override the default configuration. It takes the following form: The type has to be one of the available grouping options as described in Table 18.4, "Available AllowOverride options" . Table 18.4. Available AllowOverride options Option Description All All directives in .htaccess are allowed to override earlier configuration settings. None No directive in .htaccess is allowed to override earlier configuration settings. AuthConfig Allows the use of authorization directives such as AuthName , AuthType , or Require . FileInfo Allows the use of file type, metadata, and mod_rewrite directives such as DefaultType , RequestHeader , or RewriteEngine , as well as the Action directive. Indexes Allows the use of directory indexing directives such as AddDescription , AddIcon , or FancyIndexing . Limit Allows the use of host access directives, that is, Allow , Deny , and Order . Options [ = option ,... ] Allows the use of the Options directive. Additionally, you can provide a comma-separated list of options to customize which options can be set using this directive. Example 18.19. Using the AllowOverride directive BrowserMatch The BrowserMatch directive allows you to modify the server behavior based on the client's web browser type. It takes the following form: The pattern is a regular expression to match the User-Agent HTTP header field. The variable is an environment variable that is set when the header field matches the pattern. By default, this directive is used to deny connections to specific browsers with known issues, and to disable keepalives and HTTP header flushes for browsers that are known to have problems with these actions. Example 18.20. Using the BrowserMatch directive CacheDefaultExpire The CacheDefaultExpire option allows you to set how long to cache a document that does not have any expiration date or the date of its last modification specified. It takes the following form: The time is specified in seconds. The default option is 3600 (that is, one hour). Example 18.21. Using the CacheDefaultExpire directive CacheDisable The CacheDisable directive allows you to disable caching of certain URLs. It takes the following form: The path must be relative to the directory specified by the DocumentRoot directive (for example, /files/ ). Example 18.22. Using the CacheDisable directive CacheEnable The CacheEnable directive allows you to specify a cache type to be used for certain URLs. It takes the following form: The type has to be a valid cache type as described in Table 18.5, "Available cache types" . The url can be a path relative to the directory specified by the DocumentRoot directive (for example, /images/ ), a protocol (for example, ftp:// ), or an external URL such as http://example.com/ . Table 18.5. Available cache types Type Description mem The memory-based storage manager. disk The disk-based storage manager. fd The file descriptor cache. Example 18.23. Using the CacheEnable directive CacheLastModifiedFactor The CacheLastModifiedFactor directive allows you to customize how long to cache a document that does not have any expiration date specified, but that provides information about the date of its last modification. It takes the following form: The number is a coefficient to be used to multiply the time that passed since the last modification of the document. The default option is 0.1 (that is, one tenth). Example 18.24. Using the CacheLastModifiedFactor directive CacheMaxExpire The CacheMaxExpire directive allows you to specify the maximum amount of time to cache a document. It takes the following form: The time is specified in seconds. The default option is 86400 (that is, one day). Example 18.25. Using the CacheMaxExpire directive CacheNegotiatedDocs The CacheNegotiatedDocs directive allows you to enable caching of the documents that were negotiated on the basis of content. It takes the following form: The option has to be a valid keyword as described in Table 18.6, "Available CacheNegotiatedDocs options" . Since the content-negotiated documents may change over time or because of the input from the requester, the default option is Off . Table 18.6. Available CacheNegotiatedDocs options Option Description On Enables caching the content-negotiated documents. Off Disables caching the content-negotiated documents. Example 18.26. Using the CacheNegotiatedDocs directive CacheRoot The CacheRoot directive allows you to specify the directory to store cache files in. It takes the following form: The directory must be a full path to an existing directory in the local file system. The default option is /var/cache/mod_proxy/ . Example 18.27. Using the CacheRoot directive CustomLog The CustomLog directive allows you to specify the log file name and the log file format. It takes the following form: The path refers to a log file, and must be relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The format has to be either an explicit format string, or a format name that was previously defined using the LogFormat directive. Example 18.28. Using the CustomLog directive DefaultIcon The DefaultIcon directive allows you to specify an icon to be displayed for a file in server-generated directory listings when no other icon is associated with it. It takes the following form: The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/unknown.png ). Example 18.29. Using the DefaultIcon directive DefaultType The DefaultType directive allows you to specify a media type to be used in case the proper MIME type cannot be determined by the server. It takes the following form: The content-type has to be a valid MIME type such as text/html , image/png , application/pdf , etc. Example 18.30. Using the DefaultType directive Deny The Deny directive allows you to specify which clients are denied access to a given directory. It takes the following form: The client can be a domain name, an IP address (both full and partial), a network / netmask pair, or all for all clients. Example 18.31. Using the Deny directive DirectoryIndex The DirectoryIndex directive allows you to specify a document to be served to a client when a directory is requested (that is, when the URL ends with the / character). It takes the following form: The filename is a name of the file to look for in the requested directory. By default, the server looks for index.html , and index.html.var . Example 18.32. Using the DirectoryIndex directive DocumentRoot The DocumentRoot directive allows you to specify the main directory from which the content is served. It takes the following form: The directory must be a full path to an existing directory in the local file system. The default option is /var/www/html/ . Example 18.33. Using the DocumentRoot directive ErrorDocument The ErrorDocument directive allows you to specify a document or a message to be displayed as a response to a particular error. It takes the following form: The error-code has to be a valid code such as 403 (Forbidden), 404 (Not Found), or 500 (Internal Server Error). The action can be either a URL (both local and external), or a message string enclosed in double quotes (that is, " ). Example 18.34. Using the ErrorDocument directive ErrorLog The ErrorLog directive allows you to specify a file to which the server errors are logged. It takes the following form: The path refers to a log file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is logs/error_log Example 18.35. Using the ErrorLog directive ExtendedStatus The ExtendedStatus directive allows you to enable detailed server status information. It takes the following form: The option has to be a valid keyword as described in Table 18.7, "Available ExtendedStatus options" . The default option is Off . Table 18.7. Available ExtendedStatus options Option Description On Enables generating the detailed server status. Off Disables generating the detailed server status. Example 18.36. Using the ExtendedStatus directive Group The Group directive allows you to specify the group under which the httpd service will run. It takes the following form: The group has to be an existing UNIX group. The default option is apache . Note that Group is no longer supported inside <VirtualHost> , and has been replaced by the SuexecUserGroup directive. Example 18.37. Using the Group directive HeaderName The HeaderName directive allows you to specify a file to be prepended to the beginning of the server-generated directory listing. It takes the following form: The filename is a name of the file to look for in the requested directory. By default, the server looks for HEADER.html . Example 18.38. Using the HeaderName directive HostnameLookups The HostnameLookups directive allows you to enable automatic resolving of IP addresses. It takes the following form: The option has to be a valid keyword as described in Table 18.8, "Available HostnameLookups options" . To conserve resources on the server, the default option is Off . Table 18.8. Available HostnameLookups options Option Description On Enables resolving the IP address for each connection so that the host name can be logged. However, this also adds a significant processing overhead. Double Enables performing the double-reverse DNS lookup. In comparison to the above option, this adds even more processing overhead. Off Disables resolving the IP address for each connection. Note that when the presence of host names is required in server log files, it is often possible to use one of the many log analyzer tools that perform the DNS lookups more efficiently. Example 18.39. Using the HostnameLookups directive Include The Include directive allows you to include other configuration files. It takes the following form: The filename can be an absolute path, a path relative to the directory specified by the ServerRoot directive, or a wildcard expression. All configuration files from the /etc/httpd/conf.d/ directory are loaded by default. Example 18.40. Using the Include directive IndexIgnore The IndexIgnore directive allows you to specify a list of file names to be omitted from the server-generated directory listings. It takes the following form: The filename option can be either a full file name, or a wildcard expression. Example 18.41. Using the IndexIgnore directive IndexOptions The IndexOptions directive allows you to customize the behavior of server-generated directory listings. It takes the following form: The option has to be a valid keyword as described in Table 18.9, "Available directory listing options" . The default options are Charset=UTF-8 , FancyIndexing , HTMLTable , NameWidth=* , and VersionSort . Table 18.9. Available directory listing options Option Description Charset = encoding Specifies the character set of a generated web page. The encoding has to be a valid character set such as UTF-8 or ISO-8859-2 . Type = content-type Specifies the media type of a generated web page. The content-type has to be a valid MIME type such as text/html or text/plain . DescriptionWidth = value Specifies the width of the description column. The value can be either a number of characters, or an asterisk (that is, * ) to adjust the width automatically. FancyIndexing Enables advanced features such as different icons for certain files or possibility to re-sort a directory listing by clicking on a column header. FolderFirst Enables listing directories first, always placing them above files. HTMLTable Enables the use of HTML tables for directory listings. IconsAreLinks Enables using the icons as links. IconHeight = value Specifies an icon height. The value is a number of pixels. IconWidth = value Specifies an icon width. The value is a number of pixels. IgnoreCase Enables sorting files and directories in a case-sensitive manner. IgnoreClient Disables accepting query variables from a client. NameWidth = value Specifies the width of the file name column. The value can be either a number of characters, or an asterisk (that is, * ) to adjust the width automatically. ScanHTMLTitles Enables parsing the file for a description (that is, the title element) in case it is not provided by the AddDescription directive. ShowForbidden Enables listing the files with otherwise restricted access. SuppressColumnSorting Disables re-sorting a directory listing by clicking on a column header. SuppressDescription Disables reserving a space for file descriptions. SuppressHTMLPreamble Disables the use of standard HTML preamble when a file specified by the HeaderName directive is present. SuppressIcon Disables the use of icons in directory listings. SuppressLastModified Disables displaying the date of the last modification field in directory listings. SuppressRules Disables the use of horizontal lines in directory listings. SuppressSize Disables displaying the file size field in directory listings. TrackModified Enables returning the Last-Modified and ETag values in the HTTP header. VersionSort Enables sorting files that contain a version number in the expected manner. XHTML Enables the use of XHTML 1.0 instead of the default HTML 3.2. Example 18.42. Using the IndexOptions directive KeepAlive The KeepAlive directive allows you to enable persistent connections. It takes the following form: The option has to be a valid keyword as described in Table 18.10, "Available KeepAlive options" . The default option is Off . Table 18.10. Available KeepAlive options Option Description On Enables the persistent connections. In this case, the server will accept more than one request per connection. Off Disables the keep-alive connections. Note that when the persistent connections are enabled, on a busy server, the number of child processes can increase rapidly and eventually reach the maximum limit, slowing down the server significantly. To reduce the risk, it is recommended that you set KeepAliveTimeout to a low number, and monitor the /var/log/httpd/logs/error_log log file carefully. Example 18.43. Using the KeepAlive directive KeepAliveTimeout The KeepAliveTimeout directive allows you to specify the amount of time to wait for another request before closing the connection. It takes the following form: The time is specified in seconds. The default option is 15 . Example 18.44. Using the KeepAliveTimeout directive LanguagePriority The LanguagePriority directive allows you to customize the precedence of languages. It takes the following form: The language has to be a valid MIME language such as cs , en , or fr . This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings. Example 18.45. Using the LanguagePriority directive Listen The Listen directive allows you to specify IP addresses or ports to listen to. It takes the following form: The ip-address is optional and unless supplied, the server will accept incoming requests on a given port from all IP addresses. Since the protocol is determined automatically from the port number, it can be usually omitted. The default option is to listen to port 80 . Note that if the server is configured to listen to a port under 1024, only superuser will be able to start the httpd service. Example 18.46. Using the Listen directive LoadModule The LoadModule directive allows you to load a Dynamic Shared Object ( DSO ) module. It takes the following form: The name has to be a valid identifier of the required module. The path refers to an existing module file, and must be relative to the directory in which the libraries are placed (that is, /usr/lib/httpd/ on 32-bit and /usr/lib64/httpd/ on 64-bit systems by default). See Section 18.1.6, "Working with Modules" for more information on the Apache HTTP Server's DSO support. Example 18.47. Using the LoadModule directive LogFormat The LogFormat directive allows you to specify a log file format. It takes the following form: The format is a string consisting of options as described in Table 18.11, "Common LogFormat options" . The name can be used instead of the format string in the CustomLog directive. Table 18.11. Common LogFormat options Option Description %b Represents the size of the response in bytes. %h Represents the IP address or host name of a remote client. %l Represents the remote log name if supplied. If not, a hyphen (that is, - ) is used instead. %r Represents the first line of the request string as it came from the browser or client. %s Represents the status code. %t Represents the date and time of the request. %u If the authentication is required, it represents the remote user. If not, a hyphen (that is, - ) is used instead. %{ field } Represents the content of the HTTP header field . The common options include %{Referer} (the URL of the web page that referred the client to the server) and %{User-Agent} (the type of the web browser making the request). Example 18.48. Using the LogFormat directive LogLevel The LogLevel directive allows you to customize the verbosity level of the error log. It takes the following form: The option has to be a valid keyword as described in Table 18.12, "Available LogLevel options" . The default option is warn . Table 18.12. Available LogLevel options Option Description emerg Only the emergency situations when the server cannot perform its work are logged. alert All situations when an immediate action is required are logged. crit All critical conditions are logged. error All error messages are logged. warn All warning messages are logged. notice Even normal, but still significant situations are logged. info Various informational messages are logged. debug Various debugging messages are logged. Example 18.49. Using the LogLevel directive MaxKeepAliveRequests The MaxKeepAliveRequests directive allows you to specify the maximum number of requests for a persistent connection. It takes the following form: A high number can improve the performance of the server. Note that using 0 allows unlimited number of requests. The default option is 100 . Example 18.50. Using the MaxKeepAliveRequests option NameVirtualHost The NameVirtualHost directive allows you to specify the IP address and port number for a name-based virtual host. It takes the following form: The ip-address can be either a full IP address, or an asterisk (that is, * ) representing all interfaces. Note that IPv6 addresses have to be enclosed in square brackets (that is, [ and ] ). The port is optional. Name-based virtual hosting allows one Apache HTTP Server to serve different domains without using multiple IP addresses. Important Name-based virtual hosts only work with non-secure HTTP connections. If using virtual hosts with a secure server, use IP address-based virtual hosts instead. Example 18.51. Using the NameVirtualHost directive Options The Options directive allows you to specify which server features are available in a particular directory. It takes the following form: The option has to be a valid keyword as described in Table 18.13, "Available server features" . Table 18.13. Available server features Option Description ExecCGI Enables the execution of CGI scripts. FollowSymLinks Enables following symbolic links in the directory. Includes Enables server-side includes. IncludesNOEXEC Enables server-side includes, but does not allow the execution of commands. Indexes Enables server-generated directory listings. MultiViews Enables content-negotiated " MultiViews " . SymLinksIfOwnerMatch Enables following symbolic links in the directory when both the link and the target file have the same owner. All Enables all of the features above with the exception of MultiViews . None Disables all of the features above. Important The SymLinksIfOwnerMatch option is not a security feature as it can be bypassed by an attacker. Example 18.52. Using the Options directive Order The Order directive allows you to specify the order in which the Allow and Deny directives are evaluated. It takes the following form: The option has to be a valid keyword as described in Table 18.14, "Available Order options" . The default option is allow,deny . Table 18.14. Available Order options Option Description allow,deny Allow directives are evaluated first. deny,allow Deny directives are evaluated first. Example 18.53. Using the Order directive PidFile The PidFile directive allows you to specify a file to which the process ID ( PID ) of the server is stored. It takes the following form: The path refers to a pid file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is run/httpd.pid . Example 18.54. Using the PidFile directive ProxyRequests The ProxyRequests directive allows you to enable forward proxy requests. It takes the following form: The option has to be a valid keyword as described in Table 18.15, "Available ProxyRequests options" . The default option is Off . Table 18.15. Available ProxyRequests options Option Description On Enables forward proxy requests. Off Disables forward proxy requests. Example 18.55. Using the ProxyRequests directive ReadmeName The ReadmeName directive allows you to specify a file to be appended to the end of the server-generated directory listing. It takes the following form: The filename is a name of the file to look for in the requested directory. By default, the server looks for README.html . Example 18.56. Using the ReadmeName directive Redirect The Redirect directive allows you to redirect a client to another URL. It takes the following form: The status is optional, and if provided, it has to be a valid keyword as described in Table 18.16, "Available status options" . The path refers to the old location, and must be relative to the directory specified by the DocumentRoot directive (for example, /docs ). The url refers to the current location of the content (for example, http://docs.example.com ). Table 18.16. Available status options Status Description permanent Indicates that the requested resource has been moved permanently. The 301 (Moved Permanently) status code is returned to a client. temp Indicates that the requested resource has been moved only temporarily. The 302 (Found) status code is returned to a client. seeother Indicates that the requested resource has been replaced. The 303 (See Other) status code is returned to a client. gone Indicates that the requested resource has been removed permanently. The 410 (Gone) status is returned to a client. Note that for more advanced redirection techniques, you can use the mod_rewrite module that is part of the Apache HTTP Server installation. Example 18.57. Using the Redirect directive ScriptAlias The ScriptAlias directive allows you to specify the location of CGI scripts. It takes the following form: The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/ ). The real-path is a full path to a file or directory in the local file system. This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /cgi-bin/ alias is created so that the scripts located in the /var/www/cgi-bin/ are accessible. The ScriptAlias directive is used for security reasons to prevent CGI scripts from being viewed as ordinary text documents. Example 18.58. Using the ScriptAlias directive ServerAdmin The ServerAdmin directive allows you to specify the email address of the server administrator to be displayed in server-generated web pages. It takes the following form: The default option is root@localhost . This directive is commonly set to webmaster@ hostname , where hostname is the address of the server. Once set, alias webmaster to the person responsible for the web server in /etc/aliases , and as superuser, run the newaliases command. Example 18.59. Using the ServerAdmin directive ServerName The ServerName directive allows you to specify the host name and the port number of a web server. It takes the following form: The hostname has to be a fully qualified domain name ( FQDN ) of the server. The port is optional, but when supplied, it has to match the number specified by the Listen directive. When using this directive, make sure that the IP address and server name pair are included in the /etc/hosts file. Example 18.60. Using the ServerName directive ServerRoot The ServerRoot directive allows you to specify the directory in which the server operates. It takes the following form: The directory must be a full path to an existing directory in the local file system. The default option is /etc/httpd/ . Example 18.61. Using the ServerRoot directive ServerSignature The ServerSignature directive allows you to enable displaying information about the server on server-generated documents. It takes the following form: The option has to be a valid keyword as described in Table 18.17, "Available ServerSignature options" . The default option is On . Table 18.17. Available ServerSignature options Option Description On Enables appending the server name and version to server-generated pages. Off Disables appending the server name and version to server-generated pages. EMail Enables appending the server name, version, and the email address of the system administrator as specified by the ServerAdmin directive to server-generated pages. Example 18.62. Using the ServerSignature directive ServerTokens The ServerTokens directive allows you to customize what information is included in the Server response header. It takes the following form: The option has to be a valid keyword as described in Table 18.18, "Available ServerTokens options" . The default option is OS . Table 18.18. Available ServerTokens options Option Description Prod Includes the product name only (that is, Apache ). Major Includes the product name and the major version of the server (for example, 2 ). Minor Includes the product name and the minor version of the server (for example, 2.2 ). Min Includes the product name and the minimal version of the server (for example, 2.2.15 ). OS Includes the product name, the minimal version of the server, and the type of the operating system it is running on (for example, Red Hat ). Full Includes all the information above along with the list of loaded modules. Note that for security reasons, it is recommended to reveal as little information about the server as possible. Example 18.63. Using the ServerTokens directive SuexecUserGroup The SuexecUserGroup directive allows you to specify the user and group under which the CGI scripts will be run. It takes the following form: The user has to be an existing user, and the group must be a valid UNIX group. For security reasons, the CGI scripts should not be run with root privileges. Note that in <VirtualHost> , SuexecUserGroup replaces the User and Group directives. Example 18.64. Using the SuexecUserGroup directive Timeout The Timeout directive allows you to specify the amount of time to wait for an event before closing a connection. It takes the following form: The time is specified in seconds. The default option is 60 . Example 18.65. Using the Timeout directive TypesConfig The TypesConfig allows you to specify the location of the MIME types configuration file. It takes the following form: The path refers to an existing MIME types configuration file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is /etc/mime.types . Note that instead of editing /etc/mime.types , the recommended way to add MIME type mapping to the Apache HTTP Server is to use the AddType directive. Example 18.66. Using the TypesConfig directive UseCanonicalName The UseCanonicalName allows you to specify the way the server refers to itself. It takes the following form: The option has to be a valid keyword as described in Table 18.19, "Available UseCanonicalName options" . The default option is Off . Table 18.19. Available UseCanonicalName options Option Description On Enables the use of the name that is specified by the ServerName directive. Off Disables the use of the name that is specified by the ServerName directive. The host name and port number provided by the requesting client are used instead. DNS Disables the use of the name that is specified by the ServerName directive. The host name determined by a reverse DNS lookup is used instead. Example 18.67. Using the UseCanonicalName directive User The User directive allows you to specify the user under which the httpd service will run. It takes the following form: The user has to be an existing UNIX user. The default option is apache . For security reasons, the httpd service should not be run with root privileges. Note that User is no longer supported inside <VirtualHost> , and has been replaced by the SuexecUserGroup directive. Example 18.68. Using the User directive UserDir The UserDir directive allows you to enable serving content from users' home directories. It takes the following form: The option can be either a name of the directory to look for in user's home directory (typically public_html ), or a valid keyword as described in Table 18.20, "Available UserDir options" . The default option is disabled . Table 18.20. Available UserDir options Option Description enabled user ... Enables serving content from home directories of given user s. disabled [ user ... ] Disables serving content from home directories, either for all users, or, if a space separated list of user s is supplied, for given users only. Note In order for the web server to access the content, the permissions on relevant directories and files must be set correctly. Make sure that all users are able to access the home directories, and that they can access and read the content of the directory specified by the UserDir directive. For example: All files in this directory must be set accordingly. Example 18.69. Using the UserDir directive 18.1.5.2. Common ssl.conf Directives The Secure Sockets Layer ( SSL ) directives allow you to customize the behavior of the Apache HTTP Secure Server, and in most cases, they are configured appropriately during the installation. Be careful when changing these settings, as incorrect configuration can lead to security vulnerabilities. The following directive is commonly used in /etc/httpd/conf.d/ssl.conf : SetEnvIf The SetEnvIf directive allows you to set environment variables based on the headers of incoming connections. It takes the following form: The option can be either a HTTP header field, a previously defined environment variable name, or a valid keyword as described in Table 18.21, "Available SetEnvIf options" . The pattern is a regular expression. The variable is an environment variable that is set when the option matches the pattern. If the optional exclamation mark (that is, ! ) is present, the variable is removed instead of being set. Table 18.21. Available SetEnvIf options Option Description Remote_Host Refers to the client's host name. Remote_Addr Refers to the client's IP address. Server_Addr Refers to the server's IP address. Request_Method Refers to the request method (for example, GET ). Request_Protocol Refers to the protocol name and version (for example, HTTP/1.1 ). Request_URI Refers to the requested resource. The SetEnvIf directive is used to disable HTTP keepalives, and to allow SSL to close the connection without a closing notification from the client browser. This is necessary for certain web browsers that do not reliably shut down the SSL connection. Example 18.70. Using the SetEnvIf directive Note that for the /etc/httpd/conf.d/ssl.conf file to be present, the mod_ssl needs to be installed. See Section 18.1.8, "Setting Up an SSL Server" for more information on how to install and configure an SSL server. 18.1.5.3. Common Multi-Processing Module Directives The Multi-Processing Module ( MPM ) directives allow you to customize the behavior of a particular MPM specific server-pool. Since its characteristics differ depending on which MPM is used, the directives are embedded in IfModule . By default, the server-pool is defined for both the prefork and worker MPMs. The following MPM directives are commonly used in /etc/httpd/conf/httpd.conf : MaxClients The MaxClients directive allows you to specify the maximum number of simultaneously connected clients to process at one time. It takes the following form: A high number can improve the performance of the server, although it is not recommended to exceed 256 when using the prefork MPM. Example 18.71. Using the MaxClients directive MaxRequestsPerChild The MaxRequestsPerChild directive allows you to specify the maximum number of request a child process can serve before it dies. It takes the following form: Setting the number to 0 allows unlimited number of requests. The MaxRequestsPerChild directive is used to prevent long-lived processes from causing memory leaks. Example 18.72. Using the MaxRequestsPerChild directive MaxSpareServers The MaxSpareServers directive allows you to specify the maximum number of spare child processes. It takes the following form: This directive is used by the prefork MPM only. Example 18.73. Using the MaxSpareServers directive MaxSpareThreads The MaxSpareThreads directive allows you to specify the maximum number of spare server threads. It takes the following form: The number must be greater than or equal to the sum of MinSpareThreads and ThreadsPerChild . This directive is used by the worker MPM only. Example 18.74. Using the MaxSpareThreads directive MinSpareServers The MinSpareServers directive allows you to specify the minimum number of spare child processes. It takes the following form: Note that a high number can create a heavy processing load on the server. This directive is used by the prefork MPM only. Example 18.75. Using the MinSpareServers directive MinSpareThreads The MinSpareThreads directive allows you to specify the minimum number of spare server threads. It takes the following form: This directive is used by the worker MPM only. Example 18.76. Using the MinSpareThreads directive StartServers The StartServers directive allows you to specify the number of child processes to create when the service is started. It takes the following form: Since the child processes are dynamically created and terminated according to the current traffic load, it is usually not necessary to change this value. Example 18.77. Using the StartServers directive ThreadsPerChild The ThreadsPerChild directive allows you to specify the number of threads a child process can create. It takes the following form: This directive is used by the worker MPM only. Example 18.78. Using the ThreadsPerChild directive 18.1.6. 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. By default, these modules are located in /usr/lib/httpd/modules/ on 32-bit and in /usr/lib64/httpd/modules/ on 64-bit systems. 18.1.6.1. Loading a Module To load a particular DSO module, use the LoadModule directive as described in Section 18.1.5.1, "Common httpd.conf Directives" . Note that modules provided by a separate package often have their own configuration file in the /etc/httpd/conf.d/ directory. Example 18.79. Loading the mod_ssl DSO Once you are finished, restart the web server to reload the configuration. See Section 18.1.4.3, "Restarting the Service" for more information on how to restart the httpd service. 18.1.6.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. 18.1.7. 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, find the virtual host container provided in /etc/httpd/conf/httpd.conf as an example, remove the hash sign (that is, # ) from the beginning of each line, and customize the options according to your requirements as shown in Example 18.80, "Example virtual host configuration" . Example 18.80. 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 18.1.4.3, "Restarting the Service" for more information on how to restart the httpd service. 18.1.8. 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. 18.1.8.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 18.22, "Information about CA lists used by common web browsers" . Table 18.22. 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. 18.1.9. Enabling the mod_ssl Module If you intend to set up an SSL or HTTPS server using mod_ssl , you cannot have 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 18.1.4.3, "Restarting the Service" . Important Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566) , Red Hat recommends disabling SSL , if it is enabled, 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. However, the use of SSLv2 or SSLv3 is now strongly recommended against. 18.1.9.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. Note that in Red Hat Enterprise Linux 6.8 SSLv2 is disabled by default. Procedure 18.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: 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. Procedure 18.2. Disable All SSL and TLS Protocols Except TLS 1 and Up To disable all SSL and TLS protocol versions except TLS version 1 and higher, proceed as follows: 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. Procedure 18.3. Testing the Status of SSL and TLS Protocols To check which versions of SSL and TLS are enabled or disabled, make use of the openssl s_client -connect command. The command has the following form: openssl s_client -connect hostname : port - protocol Where port is the port to test and protocol is the protocol version to test for. To test the SSL server running locally, use localhost as the host name. For example, to test the default port for secure HTTPS connections, port 443 to see if SSLv3 is enabled, issue a command as follows: 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) . 18.1.10. Enabling the mod_nss Module If you intend to set up an HTTPS server using mod_nss , the HTTPS server cannot simultaneously use mod_ssl with its default settings as mod_ssl will use port 443 by default, however this is the default HTTPS port. If is recommend to remove the package if it is not required. 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 . For a specific VirtualHost where HTTPS is required, 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 18.4. 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 18.1.4.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 18.81. Adding a Certificate to the Mozilla NSS database The certutil command is used to add a CA certificate to the NSS database files: certutil -d /etc/httpd/ nss-db-directory / -A -n " CA_certificate " -t CT,, -a -i certificate.pem The above command adds a CA certificate stored in a PEM-formatted file named certificate.pem . The -d option specifies the NSS database directory containing the certificate and key database files, the -n option sets a name for the certificate, -t CT,, means that the certificate is trusted to be used in TLS clients and servers. The -A option adds an existing certificate to a certificate database. If the database does not exist it will be created. The -a option allows the use of ASCII format for input or output, and the -i option passes the certificate.pem input file to the command. See the certutil(1) man page for more command line options. The NSS database should be password protected to safeguard the private key. Example 18.82. Setting_a_Password_for_a_Mozilla_NSS_database The certutil tool can be used to 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: 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: 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: 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 18.1.4.3, "Restarting the Service" Important Due to the vulnerability described in POODLE: SSLv3 vulnerability (CVE-2014-3566) , Red Hat recommends disabling SSL , if it is enabled, 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. However, the use of SSLv2 or SSLv3 is now strongly recommended against. 18.1.10.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. Note that in Red Hat Enterprise Linux 6.8 SSLv2 is disabled by default. Procedure 18.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: 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. Procedure 18.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 : 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: 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) . 18.1.11. 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 18.1.12, "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 18.1.4.3, "Restarting the Service" . Example 18.83. Using a key and certificate from the Red Hat Secure Web Server 18.1.12. 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. In Red Hat Enterprise Linux 6, the mod_ssl package is required by the genkey utility. To install these, 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, 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 18.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 18.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 18.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 18.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 18.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 18.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 18.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 18.1.4.3, "Restarting the Service" , so that the updated configuration is loaded. 18.1.13. 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, enable ports and protocols as required. The default port for HTTP is 80 and the default port for HTTPS is 443 . In both cases the TCP should be allowed to pass through the firewall. To enable port 80 for HTTP using the command line, issue the following command as root : Note that this will restart the firewall as long as it has not been disabled with the --disabled option. Active connections will be terminated and time out on the initiating machine. Use the lokkit --help command to view the built in help. To enable port 443 for HTTPS using the command line, issue the following command as root : Note that this will restart the firewall as long as it has not been disabled with the --disabled option. Active connections will be terminated and time out on the initiating machine. See the /etc/services file for list of services and their associated ports. When preparing a configuration file for multiple installations using administration tools, it is useful to edit the firewall configuration file directly. Note that any mistakes in the configuration file could have unexpected consequences, cause an error, and prevent the firewall settings from being applied. Therefore, check the /etc/sysconfig/system-config-firewall file thoroughly after editing. To apply the settings in /etc/sysconfig/system-config-firewall , issue the following command as root : For example, to enable HTTPS to pass through the firewall, by editing the configuration file, become the root user and add the following line to /etc/sysconfig/system-config-firewall : Note that these changes will not take effect even if the firewall is reloaded or the system rebooted. To apply the changes in /etc/sysconfig/system-config-firewall , issue the following command as root : 18.1.13.1. Checking Network Access for Incoming HTTPS and HTTPS Using the Command Line To check what 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 default port for HTTP is enabled, the following line appears as output in addition to the lines shown above: To check if the firewall is currently allowing incoming HTTP traffic for clients, issue the following command as root : Once the default port for HTTPS is enabled, the following line appears as output in addition to the lines shown above: To check if the firewall is currently allowing incoming HTTPS traffic for clients, issue the following command as root : 18.1.14. 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. 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.
~]# service httpd configtest Syntax OK ~]# yum install httpd ~]# service httpd start Starting httpd: [ OK ] ~]# chkconfig httpd on ~]# service httpd stop Stopping httpd: [ OK ] ~]# chkconfig httpd off ~]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] ~]# service httpd reload ~]# service httpd graceful ~]# service httpd status httpd (pid 19014) is running ~]# service httpd configtest Syntax OK <Directory directory > directive ... </Directory> <Directory /var/www/html> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> <IfDefine [ ! ] parameter > directive ... </IfDefine> <IfDefine EnableHome> UserDir public_html </IfDefine> <IfModule [ ! ] module > directive ... </IfModule> <IfModule mod_disk_cache.c> CacheEnable disk / CacheRoot /var/cache/mod_proxy </IfModule> <Location url > directive ... </Location> <Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from .example.com </Location> <Proxy pattern > directive ... </Proxy> <Proxy *> Order deny,allow Deny from all Allow from .example.com </Proxy> <VirtualHost address [ : port ]...> directive ... </VirtualHost> <VirtualHost *:80> ServerAdmin webmaster@penguin.example.com DocumentRoot /www/docs/penguin.example.com ServerName penguin.example.com ErrorLog logs/penguin.example.com-error_log CustomLog logs/penguin.example.com-access_log common </VirtualHost> AccessFileName filename ... AccessFileName .htaccess <Files ~ "^\.ht"> Order allow,deny Deny from all Satisfy All </Files> Action content-type path Action image/png /cgi-bin/process-image.cgi AddDescription " description " filename ... AddDescription "GZIP compressed tar archive" .tgz AddEncoding encoding extension ... AddEncoding x-gzip .gz .tgz AddHandler handler extension ... AddHandler cgi-script .cgi AddIcon path pattern ... AddIcon /icons/text.png .txt README AddIconByEncoding path encoding ... AddIconByEncoding /icons/compressed.png x-compress x-gzip AddIconByType path content-type ... AddIconByType /icons/video.png video/* AddLanguage language extension ... AddLanguage cs .cs .cz AddType content-type extension ... AddType application/x-gzip .gz .tgz Alias url-path real-path Alias /icons/ /var/www/icons/ <Directory "/var/www/icons"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all <Directory> Allow from client ... Allow from 192.168.1.0/255.255.255.0 AllowOverride type ... AllowOverride FileInfo AuthConfig Limit BrowserMatch pattern variable ... BrowserMatch "Mozilla/2" nokeepalive CacheDefaultExpire time CacheDefaultExpire 3600 CacheDisable path CacheDisable /temporary CacheEnable type url CacheEnable disk / CacheLastModifiedFactor number CacheLastModifiedFactor 0.1 CacheMaxExpire time CacheMaxExpire 86400 CacheNegotiatedDocs option CacheNegotiatedDocs On CacheRoot directory CacheRoot /var/cache/mod_proxy CustomLog path format CustomLog logs/access_log combined DefaultIcon path DefaultIcon /icons/unknown.png DefaultType content-type DefaultType text/plain Deny from client ... Deny from 192.168.1.1 DirectoryIndex filename ... DirectoryIndex index.html index.html.var DocumentRoot directory DocumentRoot /var/www/html ErrorDocument error-code action ErrorDocument 403 "Access Denied" ErrorDocument 404 /404-not_found.html ErrorLog path ErrorLog logs/error_log ExtendedStatus option ExtendedStatus On Group group Group apache HeaderName filename HeaderName HEADER.html HostnameLookups option HostnameLookups Off Include filename Include conf.d/*.conf IndexIgnore filename ... IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t IndexOptions option ... IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8 KeepAlive option KeepAlive Off KeepAliveTimeout time KeepAliveTimeout 15 LanguagePriority language ... LanguagePriority sk cs en Listen [ ip-address : ] port [ protocol ] Listen 80 LoadModule name path LoadModule php5_module modules/libphp5.so LogFormat format name LogFormat "%h %l %u %t \"%r\" %>s %b" common LogLevel option LogLevel warn MaxKeepAliveRequests number MaxKeepAliveRequests 100 NameVirtualHost ip-address [ : port ] NameVirtualHost *:80 Options option ... Options Indexes FollowSymLinks Order option Order allow,deny PidFile path PidFile run/httpd.pid ProxyRequests option ProxyRequests On ReadmeName filename ReadmeName README.html Redirect [ status ] path url Redirect permanent /docs http://docs.example.com ScriptAlias url-path real-path ScriptAlias /cgi-bin/ /var/www/cgi-bin/ <Directory "/var/www/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory> ServerAdmin email ServerAdmin webmaster@penguin.example.com ServerName hostname [ : port ] ServerName penguin.example.com:80 ServerRoot directory ServerRoot /etc/httpd ServerSignature option ServerSignature On ServerTokens option ServerTokens Prod SuexecUserGroup user group SuexecUserGroup apache apache Timeout time Timeout 60 TypesConfig path TypesConfig /etc/mime.types UseCanonicalName option UseCanonicalName Off User user User apache UserDir option ~]# chmod a+x /home/ username / ~]# chmod a+rx /home/ username /public_html/ UserDir public_html SetEnvIf option pattern [ ! ] variable [ = value ]... SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 MaxClients number MaxClients 256 MaxRequestsPerChild number MaxRequestsPerChild 4000 MaxSpareServers number MaxSpareServers 20 MaxSpareThreads number MaxSpareThreads 75 MinSpareServers number MinSpareServers 5 MinSpareThreads number MinSpareThreads 75 StartServers number StartServers 8 ThreadsPerChild number ThreadsPerChild 25 LoadModule ssl_module modules/mod_ssl.so ~]# yum install httpd-devel ~]# apxs -i -a -c module_name .c NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin webmaster@penguin.example.com DocumentRoot /www/docs/penguin.example.com ServerName penguin.example.com ServerAlias www.penguin.example.com ErrorLog logs/penguin.example.com-error_log CustomLog logs/penguin.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 ~]# service httpd restart ~]# 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 ~]# service httpd restart ~]# 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 -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 ~]# 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 TLSv1.0,TLSv1.1,TLSv1.2 SSL Protocol: NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2 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,TLSv1.2 ~]# service httpd restart ~]# yum install openssl ~]# 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_2 CONNECTED(00000003) depth=1 C = US, O = example.com, CN = Certificate Shack output omitted New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES256-SHA 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 mod_ssl ~]# 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 ~]# lokkit --port=80:tcp --update ~]# lokkit --port=443:tcp --update ~]# lokkit --update --port=443:tcp ~]# lokkit --update ~]# less /etc/sysconfig/system-config-firewall Configuration file for system-config-firewall --enabled --service=ssh --port=80:tcp ~]# iptables -L -n | grep 'tcp.*80' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 --port=443:tcp ~]# iptables -L -n | grep 'tcp.*443' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 ~]# yum install httpd-manual ~]# service httpd graceful