Chapter 1. Setting up the Apache HTTP web server
Chapter 1. Setting up the Apache HTTP web server 1.1. Introduction to the Apache HTTP web server 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 Apache HTTP Server , httpd , is an open source web server developed by the Apache Software Foundation . If you are upgrading from a release of Red Hat Enterprise Linux, you have to update the httpd service configuration accordingly. This section reviews some of the newly added features, and guides you through the update of prior configuration files. 1.2. Notable changes in the Apache HTTP Server The Apache HTTP Server has been updated from version 2.4.6 in RHEL 7 to version 2.4.37 in RHEL 8. This updated version includes several new features, but maintains backwards compatibility with the RHEL 7 version at the level of configuration and Application Binary Interface (ABI) of external modules. New features include: HTTP/2 support is now provided by the mod_http2 package, which is a part of the httpd module. systemd socket activation is supported. See httpd.socket(8) man page for more details. Multiple new modules have been added: mod_proxy_hcheck - a proxy health-check module mod_proxy_uwsgi - a Web Server Gateway Interface (WSGI) proxy mod_proxy_fdpass - provides support for the passing the socket of the client to another process mod_cache_socache - an HTTP cache using, for example, memcache backend mod_md - an ACME protocol SSL/TLS certificate service The following modules now load by default: mod_request mod_macro mod_watchdog A new subpackage, httpd-filesystem , has been added, which contains the basic directory layout for the Apache HTTP Server including the correct permissions for the directories. Instantiated service support, httpd@.service has been introduced. See the httpd.service man page for more information. A new httpd-init.service replaces the %post script to create a self-signed mod_ssl key pair. Automated TLS certificate provisioning and renewal using the Automatic Certificate Management Environment (ACME) protocol is now supported with the mod_md package (for use with certificate providers such as Let's Encrypt ). The Apache HTTP Server now supports loading TLS certificates and private keys from hardware security tokens directly from PKCS#11 modules. As a result, a mod_ssl configuration can now use PKCS#11 URLs to identify the TLS private key, and, optionally, the TLS certificate in the SSLCertificateKeyFile and SSLCertificateFile directives. A new ListenFree directive in the /etc/httpd/conf/httpd.conf file is now supported. Similarly to the Listen directive, ListenFree provides information about IP addresses, ports, or IP address-and-port combinations that the server listens to. However, with ListenFree , the IP_FREEBIND socket option is enabled by default. Hence, httpd is allowed to bind to a nonlocal IP address or to an IP address that does not exist yet. This allows httpd to listen on a socket without requiring the underlying network interface or the specified dynamic IP address to be up at the time when httpd is trying to bind to it. Note that the ListenFree directive is currently available only in RHEL 8. For more details on ListenFree , see the following table: Table 1.1. ListenFree directive's syntax, status, and modules Syntax Status Modules ListenFree [IP-address:]portnumber [protocol] MPM event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2 Other notable changes include: The following modules have been removed: mod_file_cache mod_nss Use mod_ssl as a replacement. For details about migrating from mod_nss , see Section 1.14, "Exporting a private key and certificates from an NSS database to use them in an Apache web server configuration" . mod_perl The default type of the DBM authentication database used by the Apache HTTP Server in RHEL 8 has been changed from SDBM to db5 . The mod_wsgi module for the Apache HTTP Server has been updated to Python 3. WSGI applications are now supported only with Python 3, and must be migrated from Python 2. The multi-processing module (MPM) configured by default with the Apache HTTP Server has changed from a multi-process, forked model (known as prefork ) to a high-performance multi-threaded model, event . Any third-party modules that are not thread-safe need to be replaced or removed. To change the configured MPM, edit the /etc/httpd/conf.modules.d/00-mpm.conf file. See the httpd.service(8) man page for more information. The minimum UID and GID allowed for users by suEXEC are now 1000 and 500, respectively (previously 100 and 100). The /etc/sysconfig/httpd file is no longer a supported interface for setting environment variables for the httpd service. The httpd.service(8) man page has been added for the systemd service. Stopping the httpd service now uses a "graceful stop" by default. The mod_auth_kerb module has been replaced by the mod_auth_gssapi module. 1.3. Updating the configuration To update the configuration files from the Apache HTTP Server version used in Red Hat Enterprise Linux 7, choose one of the following options: If /etc/sysconfig/httpd is used to set environment variables, create a systemd drop-in file instead. If any third-party modules are used, ensure they are compatible with a threaded MPM. If suexec is used, ensure user and group IDs meet the new minimums. You can check the configuration for possible errors by using the following command: 1.4. The Apache configuration files The httpd , by default, reads the configuration files after start. You can see the list of the locations of configuration files in the table below. Table 1.2. 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. /etc/httpd/conf.modules.d/ An auxiliary directory for configuration files which load installed dynamic modules packaged in Red Hat Enterprise Linux. In the default configuration, these configuration files are processed first. Although the default configuration is suitable for most situations, you can use also other configuration options. For any changes to take effect, restart the web server first. To check the configuration for possible errors, type the following at a shell prompt: To make the recovery from mistakes easier, make a copy of the original file before editing it. 1.5. Managing the httpd service This section describes how to start, stop, and restart the httpd service. Prerequisites The Apache HTTP Server is installed. Procedure To start the httpd service, enter: To stop the httpd service, enter: To restart the httpd service, enter: 1.6. Setting up a single-instance Apache HTTP Server You can set up a single-instance Apache HTTP Server to serve static HTML content. Follow the procedure if the web server should provide the same content for all domains associated with the server. If you want to provide different content for different domains, set up name-based virtual hosts. For details, see Configuring Apache name-based virtual hosts . Procedure Install the httpd package: If you use firewalld , open the TCP port 80 in the local firewall: Enable and start the httpd service: Optional: Add HTML files to the /var/www/html/ directory. Note When adding content to /var/www/html/ , files and directories must be readable by the user under which httpd runs by default. The content owner can be the either the root user and root user group, or another user or group of the administrator's choice. If the content owner is the root user and root user group, the files must be readable by other users. The SELinux context for all the files and directories must be httpd_sys_content_t , which is applied by default to all content within the /var/www directory. Verification Connect with a web browser to http:// server_IP_or_host_name / . If the /var/www/html/ directory is empty or does not contain an index.html or index.htm file, Apache displays the Red Hat Enterprise Linux Test Page . If /var/www/html/ contains HTML files with a different name, you can load them by entering the URL to that file, such as http:// server_IP_or_host_name / example.html . Additional resources Apache manual: Installing the Apache HTTP server manual . See the httpd.service(8) man page on your system. 1.7. Configuring Apache name-based virtual hosts Name-based virtual hosts enable Apache to serve different content for different domains that resolve to the IP address of the server. You can set up a virtual host for both the example.com and example.net domain with separate document root directories. Both virtual hosts serve static HTML content. Prerequisites Clients and the web server resolve the example.com and example.net domain to the IP address of the web server. Note that you must manually add these entries to your DNS server. Procedure Install the httpd package: Edit the /etc/httpd/conf/httpd.conf file: Append the following virtual host configuration for the example.com domain: These settings configure the following: All settings in the <VirtualHost *:80> directive are specific for this virtual host. DocumentRoot sets the path to the web content of the virtual host. ServerName sets the domains for which this virtual host serves content. To set multiple domains, add the ServerAlias parameter to the configuration and specify the additional domains separated with a space in this parameter. CustomLog sets the path to the access log of the virtual host. ErrorLog sets the path to the error log of the virtual host. Note Apache uses the first virtual host found in the configuration also for requests that do not match any domain set in the ServerName and ServerAlias parameters. This also includes requests sent to the IP address of the server. Append a similar virtual host configuration for the example.net domain: Create the document roots for both virtual hosts: If you set paths in the DocumentRoot parameters that are not within /var/www/ , set the httpd_sys_content_t context on both document roots: These commands set the httpd_sys_content_t context on the /srv/example.com/ and /srv/example.net/ directory. Note that you must install the policycoreutils-python-utils package to run the restorecon command. If you use firewalld , open port 80 in the local firewall: Enable and start the httpd service: Verification Create a different example file in each virtual host's document root: Use a browser and connect to http://example.com . The web server shows the example file from the example.com virtual host. Use a browser and connect to http://example.net . The web server shows the example file from the example.net virtual host. Additional resources Installing the Apache HTTP Server manual - Virtual Hosts 1.8. Configuring Kerberos authentication for the Apache HTTP web server To perform Kerberos authentication in the Apache HTTP web server, RHEL 8 uses the mod_auth_gssapi Apache module. The Generic Security Services API ( GSSAPI ) is an interface for applications that make requests to use security libraries, such as Kerberos. The gssproxy service allows to implement privilege separation for the httpd server, which optimizes this process from the security point of view. Note The mod_auth_gssapi module replaces the removed mod_auth_kerb module. Prerequisites The httpd and gssproxy packages are installed. The Apache web server is set up and the httpd service is running. 1.8.1. Setting up GSS-Proxy in an IdM environment This procedure describes how to set up GSS-Proxy to perform Kerberos authentication in the Apache HTTP web server. Procedure Enable access to the keytab file of HTTP/<SERVER_NAME>@realm principal by creating the service principal: Retrieve the keytab for the principal stored in the /etc/gssproxy/http.keytab file: This step sets permissions to 400, thus only the root user has access to the keytab file. The apache user does not. Create the /etc/gssproxy/80-httpd.conf file with the following content: Restart and enable the gssproxy service: Additional resources gssproxy(8) man pages on your system gssproxy-mech(8) man pages on your system gssproxy.conf(5) man pages on your system 1.8.2. Configuring Kerberos authentication for a directory shared by the Apache HTTP web server This procedure describes how to configure Kerberos authentication for the /var/www/html/private/ directory. Prerequisites The gssproxy service is configured and running. Procedure Configure the mod_auth_gssapi module to protect the /var/www/html/private/ directory: Create system unit configuration drop-in file: Add the following parameter to the system drop-in file: Reload the systemd configuration: Restart the httpd service: Verification Obtain a Kerberos ticket: Open the URL to the protected directory in a browser. 1.9. Configuring TLS encryption on an Apache HTTP Server By default, Apache provides content to clients using an unencrypted HTTP connection. This section describes how to enable TLS encryption and configure frequently used encryption-related settings on an Apache HTTP Server. Prerequisites The Apache HTTP Server is installed and running. 1.9.1. Adding TLS encryption to an Apache HTTP Server You can enable TLS encryption on an Apache HTTP Server for the example.com domain. Prerequisites The Apache HTTP Server is installed and running. The private key is stored in the /etc/pki/tls/private/example.com.key file. For details about creating a private key and certificate signing request (CSR), as well as how to request a certificate from a certificate authority (CA), see your CA's documentation. Alternatively, if your CA supports the ACME protocol, you can use the mod_md module to automate retrieving and provisioning TLS certificates. The TLS certificate is stored in the /etc/pki/tls/certs/example.com.crt file. If you use a different path, adapt the corresponding steps of the procedure. The CA certificate is stored in the /etc/pki/tls/certs/ca.crt file. If you use a different path, adapt the corresponding steps of the procedure. Clients and the web server resolve the host name of the server to the IP address of the web server. Procedure Install the mod_ssl package: Edit the /etc/httpd/conf.d/ssl.conf file and add the following settings to the <VirtualHost _default_:443> directive: Set the server name: Important The server name must match the entry set in the Common Name field of the certificate. Optional: If the certificate contains additional host names in the Subject Alt Names (SAN) field, you can configure mod_ssl to provide TLS encryption also for these host names. To configure this, add the ServerAliases parameter with corresponding names: Set the paths to the private key, the server certificate, and the CA certificate: For security reasons, configure that only the root user can access the private key file: Warning If the private key was accessed by unauthorized users, revoke the certificate, create a new private key, and request a new certificate. Otherwise, the TLS connection is no longer secure. If you use firewalld , open port 443 in the local firewall: Restart the httpd service: Note If you protected the private key file with a password, you must enter this password each time when the httpd service starts. Verification Use a browser and connect to https:// example.com . Additional resources SSL/TLS Encryption Security considerations for TLS in RHEL 8 1.9.2. Setting the supported TLS protocol versions on an Apache HTTP Server By default, the Apache HTTP Server on RHEL uses the system-wide crypto policy that defines safe default values, which are also compatible with recent browsers. For example, the DEFAULT policy defines that only the TLSv1.2 and TLSv1.3 protocol versions are enabled in apache. You can manually configure which TLS protocol versions your Apache HTTP Server supports. Follow the procedure if your environment requires to enable only specific TLS protocol versions, for example: If your environment requires that clients can also use the weak TLS1 (TLSv1.0) or TLS1.1 protocol. If you want to configure that Apache only supports the TLSv1.2 or TLSv1.3 protocol. Prerequisites TLS encryption is enabled on the server as described in Adding TLS encryption to an Apache HTTP server . Procedure Edit the /etc/httpd/conf/httpd.conf file, and add the following setting to the <VirtualHost> directive for which you want to set the TLS protocol version. For example, to enable only the TLSv1.3 protocol: Restart the httpd service: Verification Use the following command to verify that the server supports TLSv1.3 : Use the following command to verify that the server does not support TLSv1.2 : If the server does not support the protocol, the command returns an error: Optional: Repeat the command for other TLS protocol versions. Additional resources update-crypto-policies(8) man page on your system Using system-wide cryptographic policies . For further details about the SSLProtocol parameter, refer to the mod_ssl documentation in the Apache manual: Installing the Apache HTTP server manual . 1.9.3. Setting the supported ciphers on an Apache HTTP Server By default, the Apache HTTP Server uses the system-wide crypto policy that defines safe default values, which are also compatible with recent browsers. For the list of ciphers the system-wide crypto allows, see the /etc/crypto-policies/back-ends/openssl.config file. You can manually configure which ciphers your Apache HTTP Server supports. Follow the procedure if your environment requires specific ciphers. Prerequisites TLS encryption is enabled on the server as described in Adding TLS encryption to an Apache HTTP server . Procedure Edit the /etc/httpd/conf/httpd.conf file, and add the SSLCipherSuite parameter to the <VirtualHost> directive for which you want to set the TLS ciphers: This example enables only the EECDH+AESGCM , EDH+AESGCM , AES256+EECDH , and AES256+EDH ciphers and disables all ciphers which use the SHA1 and SHA256 message authentication code (MAC). Restart the httpd service: Verification To display the list of ciphers the Apache HTTP Server supports: Install the nmap package: Use the nmap utility to display the supported ciphers: Additional resources update-crypto-policies(8) man page on your system Using system-wide cryptographic policies . SSLCipherSuite 1.10. Configuring TLS client certificate authentication Client certificate authentication enables administrators to allow only users who authenticate using a certificate to access resources on the web server. You can configure client certificate authentication for the /var/www/html/Example/ directory. If the Apache HTTP Server uses the TLS 1.3 protocol, certain clients require additional configuration. For example, in Firefox, set the security.tls.enable_post_handshake_auth parameter in the about:config menu to true . For further details, see Transport Layer Security version 1.3 in Red Hat Enterprise Linux 8 . Prerequisites TLS encryption is enabled on the server as described in Adding TLS encryption to an Apache HTTP server . Procedure Edit the /etc/httpd/conf/httpd.conf file and add the following settings to the <VirtualHost> directive for which you want to configure client authentication: The SSLVerifyClient require setting defines that the server must successfully validate the client certificate before the client can access the content in the /var/www/html/Example/ directory. Restart the httpd service: Verification Use the curl utility to access the https://example.com/Example/ URL without client authentication: The error indicates that the web server requires a client certificate authentication. Pass the client private key and certificate, as well as the CA certificate to curl to access the same URL with client authentication: If the request succeeds, curl displays the index.html file stored in the /var/www/html/Example/ directory. Additional resources mod_ssl configuration 1.11. Securing web applications on a web server using ModSecurity ModSecurity is an open source web application firewall (WAF) supported by various web servers such as Apache, Nginx, and IIS, which reduces security risks in web applications. ModSecurity provides customizable rule sets for configuring your server. The mod_security-crs package contains the core rule set (CRS) with rules against cross-website scripting, bad user agents, SQL injection, Trojans, session hijacking, and other exploits. 1.11.1. Deploying the ModSecurity web-based application firewall for Apache To reduce risks related to running web-based applications on your web server by deploying ModSecurity, install the mod_security and mod_security_crs packages for the Apache HTTP server. The mod_security_crs package provides the core rule set (CRS) for the ModSecurity web-based application firewall (WAF) module. Procedure Install the mod_security , mod_security_crs , and httpd packages: Start the httpd server: Verification Verify that the ModSecurity web-based application firewall is enabled on your Apache HTTP server: Check that the /etc/httpd/modsecurity.d/activated_rules/ directory contains rules provided by mod_security_crs : Additional resources Red Hat JBoss Core Services ModSecurity Guide An introduction to web application firewalls for Linux sysadmins 1.11.2. Adding a custom rule to ModSecurity If the rules contained in the ModSecurity core rule set (CRS) do not fit your scenario and if you want to prevent additional possible attacks, you can add your custom rules to the rule set used by the ModSecurity web-based application firewall. The following example demonstrates the addition of a simple rule. For creating more complex rules, see the reference manual on the ModSecurity Wiki website. Prerequisites ModSecurity for Apache is installed and enabled. Procedure Open the /etc/httpd/conf.d/mod_security.conf file in a text editor of your choice, for example: Add the following example rule after the line starting with SecRuleEngine On : The rule forbids the use of resources to the user if the data parameter contains the evil string. Save the changes, and quit the editor. Restart the httpd server: Verification Create a test .html page: Restart the httpd server: Request test.html without malicious data in the GET variable of the HTTP request: Request test.html with malicious data in the GET variable of the HTTP request: Check the /var/log/httpd/error_log file, and locate the log entry about denying access with the param data containing an evil data message: Additional resources ModSecurity Wiki 1.12. Installing the Apache HTTP Server manual You can install the Apache HTTP Server manual. This manual provides a detailed documentation of, for example: Configuration parameters and directives Performance tuning Authentication settings Modules Content caching Security tips Configuring TLS encryption After installing the manual, you can display it using a web browser. Prerequisites The Apache HTTP Server is installed and running. Procedure Install the httpd-manual package: Optional: By default, all clients connecting to the Apache HTTP Server can display the manual. To restrict access to a specific IP range, such as the 192.0.2.0/24 subnet, edit the /etc/httpd/conf.d/manual.conf file and add the Require ip 192.0.2.0/24 setting to the <Directory "/usr/share/httpd/manual"> directive: Restart the httpd service: Verification To display the Apache HTTP Server manual, connect with a web browser to http:// host_name_or_IP_address /manual/ 1.13. Working with Apache modules The httpd service is a modular application, and you can extend it with a number of Dynamic Shared Objects ( DSO s). Dynamic Shared Objects are modules that you can dynamically load or unload at runtime as necessary. You can find these modules in the /usr/lib64/httpd/modules/ directory. 1.13.1. Loading a DSO module As an administrator, you can choose the functionality to include in the server by configuring which modules the server should load. 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.modules.d/ directory. Prerequisites You have installed the httpd package. Procedure Search for the module name in the configuration files in the /etc/httpd/conf.modules.d/ directory: Edit the configuration file in which the module name was found, and uncomment the LoadModule directive of the module: If the module was not found, for example, because a RHEL package does not provide the module, create a configuration file, such as /etc/httpd/conf.modules.d/30-example.conf with the following directive: Restart the httpd service: 1.13.2. Compiling a custom Apache module You can create your own module and build it with the help of the httpd-devel package, which contains the include files, the header files, and the APache eXtenSion ( apxs ) utility required to compile a module. Prerequisites You have the httpd-devel package installed. Procedure Build a custom module with the following command: Verification Load the module the same way as described in Loading a DSO module . 1.14. Exporting a private key and certificates from an NSS database to use them in an Apache web server configuration RHEL 8 no longer provides the mod_nss module for the Apache web server, and Red Hat recommends using the mod_ssl module. If you store your private key and certificates in a Network Security Services (NSS) database, for example, because you migrated the web server from RHEL 7 to RHEL 8, follow this procedure to extract the key and certificates in Privacy Enhanced Mail (PEM) format. You can then use the files in the mod_ssl configuration as described in Configuring TLS encryption on an Apache HTTP server . This procedure assumes that the NSS database is stored in /etc/httpd/alias/ and that you store the exported private key and certificates in the /etc/pki/tls/ directory. Prerequisites The private key, the certificate, and the certificate authority (CA) certificate are stored in an NSS database. Procedure List the certificates in the NSS database: You need the nicknames of the certificates in the steps. To extract the private key, you must temporarily export the key to a PKCS #12 file: Use the nickname of the certificate associated with the private key, to export the key to a PKCS #12 file: Note that you must set a password on the PKCS #12 file. You need this password in the step. Export the private key from the PKCS #12 file: Delete the temporary PKCS #12 file: Set the permissions on /etc/pki/tls/private/server.key to ensure that only the root user can access this file: Use the nickname of the server certificate in the NSS database to export the CA certificate: Set the permissions on /etc/pki/tls/certs/server.crt to ensure that only the root user can access this file: Use the nickname of the CA certificate in the NSS database to export the CA certificate: Follow Configuring TLS encryption on an Apache HTTP server to configure the Apache web server, and: Set the SSLCertificateKeyFile parameter to /etc/pki/tls/private/server.key . Set the SSLCertificateFile parameter to /etc/pki/tls/certs/server.crt . Set the SSLCACertificateFile parameter to /etc/pki/tls/certs/ca.crt . Additional resources certutil(1) , pk12util(1) , and pkcs12(1ssl) man pages on your system 1.15. Additional resources httpd(8) httpd.service(8) httpd.conf(5) apachectl(8) Using GSS-Proxy for Apache httpd operation . Configuring applications to use cryptographic hardware through PKCS #11 .
apachectl configtest Syntax OK apachectl configtest Syntax OK systemctl start httpd systemctl stop httpd systemctl restart httpd yum install httpd firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload systemctl enable --now httpd yum install httpd <VirtualHost *:80> DocumentRoot "/var/www/example.com/" ServerName example.com CustomLog /var/log/httpd/example.com_access.log combined ErrorLog /var/log/httpd/example.com_error.log </VirtualHost> <VirtualHost *:80> DocumentRoot "/var/www/example.net/" ServerName example.net CustomLog /var/log/httpd/example.net_access.log combined ErrorLog /var/log/httpd/example.net_error.log </VirtualHost> mkdir /var/www/example.com/ mkdir /var/www/example.net/ semanage fcontext -a -t httpd_sys_content_t "/srv/example.com(/.*)?" restorecon -Rv /srv/example.com/ semanage fcontext -a -t httpd_sys_content_t "/srv/example.net(/.\*)?" restorecon -Rv /srv/example.net/ firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload systemctl enable --now httpd echo "vHost example.com" > /var/www/example.com/index.html echo "vHost example.net" > /var/www/example.net/index.html ipa service-add HTTP/<SERVER_NAME> ipa-getkeytab -s USD(awk '/^server =/ {print USD3}' /etc/ipa/default.conf) -k /etc/gssproxy/http.keytab -p HTTP/USD(hostname -f) [service/HTTP] mechs = krb5 cred_store = keytab:/etc/gssproxy/http.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U euid = apache systemctl restart gssproxy.service systemctl enable gssproxy.service <Location /var/www/html/private> AuthType GSSAPI AuthName "GSSAPI Login" Require valid-user </Location> systemctl edit httpd.service [Service] Environment=GSS_USE_PROXY=1 systemctl daemon-reload systemctl restart httpd.service kinit yum install mod_ssl ServerName example.com ServerAlias www.example.com server.example.com SSLCertificateKeyFile "/etc/pki/tls/private/example.com.key" SSLCertificateFile "/etc/pki/tls/certs/example.com.crt" SSLCACertificateFile "/etc/pki/tls/certs/ca.crt" chown root:root /etc/pki/tls/private/example.com.key chmod 600 /etc/pki/tls/private/example.com.key firewall-cmd --permanent --add-port=443/tcp firewall-cmd --reload systemctl restart httpd SSLProtocol -All TLSv1.3 systemctl restart httpd openssl s_client -connect example.com :443 -tls1_3 openssl s_client -connect example.com :443 -tls1_2 140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70 SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256" systemctl restart httpd yum install nmap nmap --script ssl-enum-ciphers -p 443 example.com PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A <Directory "/var/www/html/Example/"> SSLVerifyClient require </Directory> systemctl restart httpd curl https://example.com/Example/ curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0 curl --cacert ca.crt --key client.key --cert client.crt https://example.com/Example/ yum install -y mod_security mod_security_crs httpd systemctl restart httpd httpd -M | grep security security2_module (shared) ls /etc/httpd/modsecurity.d/activated_rules/ REQUEST-921-PROTOCOL-ATTACK.conf REQUEST-930-APPLICATION-ATTACK-LFI.conf vi /etc/httpd/conf.d/mod_security.conf SecRule ARGS:data "@contains evil" "deny,status:403,msg:'param data contains evil data',id:1" systemctl restart httpd echo "mod_security test" > /var/www/html/ test .html systemctl restart httpd curl http://localhost/test.html?data=good mod_security test curl localhost/test.html?data=xxxevilxxx <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You do not have permission to access this resource.</p> </body></html> [Wed May 25 08:01:31.036297 2022] [:error] [pid 5839:tid 139874434791168] [client ::1:45658] [client ::1] ModSecurity: Access denied with code 403 (phase 2). String match "evil" at ARGS:data. [file "/etc/httpd/conf.d/mod_security.conf"] [line "4"] [id "1"] [msg "param data contains evil data"] [hostname "localhost"] [uri "/test.html"] [unique_id "Yo4amwIdsBG3yZqSzh2GuwAAAIY"] yum install httpd-manual <Directory "/usr/share/httpd/manual"> Require ip 192.0.2.0/24 </Directory> systemctl restart httpd grep mod_ssl.so /etc/httpd/conf.modules.d/ * LoadModule ssl_module modules/mod_ssl.so LoadModule ssl_module modules/<custom_module>.so systemctl restart httpd apxs -i -a -c module_name.c certutil -d /etc/httpd/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA C,, Example Server Certificate u,u,u pk12util -o /etc/pki/tls/private/export.p12 -d /etc/httpd/alias/ -n "Example Server Certificate" Enter password for PKCS12 file: password Re-enter password: password pk12util: PKCS12 EXPORT SUCCESSFUL openssl pkcs12 -in /etc/pki/tls/private/export.p12 -out /etc/pki/tls/private/server.key -nocerts -nodes Enter Import Password: password MAC verified OK rm /etc/pki/tls/private/export.p12 chown root:root /etc/pki/tls/private/server.key chmod 0600 /etc/pki/tls/private/server.key certutil -d /etc/httpd/alias/ -L -n "Example Server Certificate" -a -o /etc/pki/tls/certs/server.crt chown root:root /etc/pki/tls/certs/server.crt chmod 0600 /etc/pki/tls/certs/server.crt certutil -d /etc/httpd/alias/ -L -n " Example CA " -a -o /etc/pki/tls/certs/ca.crt