One place for hosting & domains

      Certificate

      Apache Configuration Error AH02572: Failed to configure at least one certificate and key



      Part of the Series:
      Common Apache Errors

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.

      Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.

      Introduction

      Apache generates an AH02572: Failed to configure at least one certificate and key error message when it is configured to use the ssl module, but is missing a TLS/SSL public certificate and corresponding private key. The error will prevent Apache from starting up, and the error message itself will be found in Apache’s logs.

      In this tutorial you will learn how to troubleshoot an AH02572 error using the methods described in the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series. You will also learn how to set the SSLCertificateFile and SSLCertificateKeyFile directives to resolve the message.

      If you have already determined that your Apache server is affected by an AH02572 error and you would like to skip the troubleshooting steps, the Adding an SSL Certificate to Apache section at the end of this tutorial explains how to resolve the error.

      Troubleshooting Using systemctl

      When you are troubleshooting an AH02572: Failed to configure at least one certificate and key error message, Apache will not be running. Its systemctl status will show a failed message.

      To examine Apache’s status with systemctl, run the following command on Ubuntu and Debian derived Linux distributions:

      Ubuntu and Debian Systems

      • sudo systemctl status apache2.service -l --no-pager

      On CentOS and Fedora systems, use this command to examine Apache’s status:

      CentOS and Fedora Systems

      • sudo systemctl status httpd.service -l --no-pager

      The -l flag will ensure that systemctl outputs the entire contents of a line, instead of substituting in ellipses () for long lines. The --no-pager flag will output the entire log to your screen without invoking a tool like less that only shows a screen of content at a time.

      You should receive output that is similar to the following:

      Output

      ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: failed (Result: exit-code) since Fri 2020-07-31 16:02:41 UTC; 20s ago Process: 36 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE) Jul 31 16:02:41 7d6ef84b6907 systemd[1]: Starting The Apache HTTP Server... Jul 31 16:02:41 7d6ef84b6907 apachectl[36]: Action 'start' failed. Jul 31 16:02:41 7d6ef84b6907 apachectl[36]: The Apache error log may have more information. Jul 31 16:02:41 7d6ef84b6907 systemd[1]: apache2.service: Control process exited, code=exited status=1 Jul 31 16:02:41 7d6ef84b6907 systemd[1]: apache2.service: Failed with result 'exit-code'. Jul 31 16:02:41 7d6ef84b6907 systemd[1]: Failed to start The Apache HTTP Server.

      The important lines to note are the ones showing that Apache failed to start. However, there is nothing in the output that indicates an AH02572 error message. Examining the systemd logs for Apache using the journalctl command, or checking Apache’s configuration files with apachectl configtest will not help locate information that you can use to troubleshoot the error.

      To diagnose and resolve an AH02572 error, the next section explains how to examine Apache’s logs directly.

      Examining Apache’s Logs

      Apache logs diagnostic information about its internal operations to various locations, which differ depending on your Linux distribution. Typically, Apache is configured to log error messages to a separate log file from access requests in order to help with debugging, monitoring, and alerting.

      On Ubuntu and Debian-derived systems, Apache defaults to using /var/log/apache2/error.log for error messages.

      On CentOS, Fedora, and RedHat-derived systems, Apache defaults to logging errors to the /var/log/httpd/error_log file.

      To examine Apache’s logs for evidence of an AH02572 error message, use the grep utility to search for the error code in the appropriate log file for your distribution. While there are other tools like less that you could use to find evidence of an AH02572 error, grep will only display lines with the error code so you can be sure of whether you’re affected by the issue.

      Invoke grep like this on Ubuntu and Debian-derived systems:

      • sudo grep AH02572 /var/log/apache2/error.log

      On CentOS, Fedora, and RedHat-derived systems, use the following command:

      • sudo grep AH02572 /var/log/httpd/error_log

      If your Apache server is affected by an AH02572 error, you will have output like the following:

      Output

      [Mon Aug 03 13:21:47.677235 2020] [ssl:emerg] [pid 26:tid 140355819735360] AH02572: Failed to configure at least one certificate and key for 172.17.0.5:443

      If your server is affected by an AH02572 error, the next section of this tutorial explains how to resolve it, by either disabling the ssl module, or configuring Apache with a private key and public certificate file.

      Resolving an AH02572 Error

      There are three ways to resolve an AH02572 error. The first option to resolve the error is to configure Apache with a private key and public certificate that is signed by a recognized Certificate Authority (CA). Let’s Encrypt is a free CA and you can use it to issue a valid certificate. This approach will ensure that traffic to and from your server is encrypted properly, and that web browsers and other HTTP clients trust your Apache server.

      Another approach is to create a self-signed certificate for your Apache server. This approach is useful for development and testing environments, or in cases where your server is not directly connected to the Internet and you can establish trust between systems manually.

      The last approach to resolving an AH02572 error is to turn off Apache’s ssl module entirely. This option is the least preferred since traffic to and from your server will not be encrypted. However, if you are only using your Apache server for local development or in a trusted environment, this approach can be valid.

      The following sections explain how to resolve an AH02572 error using each of the three options.

      Resolving an AH02572 Error with a Let’s Encrypt TLS Certificate

      To encrypt traffic to your Apache server using a free Let’s Encrypt TLS Certificate, use one of the guides that is specific to your Linux distribution from this tutorial series: How To Secure Apache with Let’s Encrypt.

      The Let’s Encrypt process is mostly automated, and the scripts will configure Apache for you. Moreover, the issued certificate will also be renewed automatically so you do not have to worry about it expiring in the future.

      If you are using a Linux distribution that is not included in the How To Secure Apache with Let’s Encrypt series, the Let’s Encrypt documentation includes links to interactive Certbot instructions that can help you configure your Apache server with a valid TLS certificate.

      Resolving an AH02572 Error with a Self-Signed Certificate

      To encrypt traffic to your Apache server using a self-signed certificate, use one of the tutorials from this series that explains how to create Self-signed SSL Certificates with Apache.

      These tutorials demonstrate how to generate a private key and public certificate for your Apache server. They also demonstrate how to use the SSLCertificateFile and SSLCertificateKeyFile Apache directives to configure your server with the certificate that you generate.

      If you are not using a distribution that is listed in the Self-signed SSL Certificates with Apache set of tutorials, this OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs guide can help you create a private key and self-signed public certificate that you can use with Apache.

      Note: Where possible, it is best to use a free Let’s Encrypt certificate, or other commercially issued TLS certificate. Self-signed TLS certificates are not trusted by default by browsers and other HTTP clients. As a result, your users will see a security error when visiting your site. However, if you are doing local development, or your use case does not require a valid TLS certificate you can opt for the self-signed approach.

      Disabling the ssl Module

      The last approach to resolving an AH02572 error is to turn off Apache’s TLS/SSL support by disabling the ssl module. This approach is less desirable than encrypting traffic to your server with a TLS certificate, so be certain that you do not need TLS support before disabling the module.

      To disable Apache’s ssl module on Ubuntu and Debian-derived systems, run the following command:

      On CentOS, Fedora, and RedHat-derived systems, disable the module with the following command:

      • sudo rm /etc/httpd/conf.modules.d/00-ssl.conf

      Once you have disabled the ssl module, run apachectl to test that the configuration is valid.

      • sudo apachectl configtest

      A successful apachectl configtest invocation should result in output like this:

      Output

      Syntax OK

      You can now restart Apache using the appropriate systemctl restart command for your Linux distribution.

      On Ubuntu and Debian-derived systems, run the following:

      • sudo systemctl restart apache2.service

      On CentOS, Fedora, and RedHat-derived systems use this command to restart Apache:

      • sudo systemctl restart httpd.service

      If there are no errors from the systemctl command then you have disabled the ssl module successfully.

      Conclusion

      AH02572: Failed to configure at least one certificate and key errors are challenging to detect and troubleshoot. They cannot be diagnosed with the usual systemctl, journalctl, and apachectl commands. In this tutorial you learned how to use the grep utility to examine Apache’s logs directly for evidence of an AH02572 error.

      Next you learned how to use Let’s Encrypt to configure Apache with a TLS certificate to secure your traffic and resolve the AH02572 error. You also learned about using self-signed TLS certificates for development and isolated environments. Finally you learned how to turn off the ssl module for those situations where it is not needed.



      Source link

      How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 20.04


      Introduction

      TLS, or “transport layer security” — and its predecessor SSL — are protocols used to wrap normal traffic in a protected, encrypted wrapper. Using this technology, servers can safely send information to their clients without their messages being intercepted or read by an outside party.

      In this guide, we will show you how to create and use a self-signed SSL certificate with the Apache web server on Ubuntu 20.04.

      Note: A self-signed certificate will encrypt communication between your server and any clients. However, because it is not signed by any of the trusted certificate authorities included with web browsers and operating systems, users cannot use the certificate to validate the identity of your server automatically. As a result, your users will see a security error when visiting your site.

      Because of this limitation, self-signed certificates are not appropriate for a production environment serving the public. They are typically used for testing, or for securing non-critical services used by a single user or a small group of users that can establish trust in the certificate’s validity through alternate communication channels.

      For a more production-ready certificate solution, check out Let’s Encrypt, a free certificate authority. You can learn how to download and configure a Let’s Encrypt certificate in our How To Secure Apache with Let’s Encrypt on Ubuntu 20.04 tutorial.

      Prerequisites

      Before starting this tutorial, you’ll need the following:

      • Access to a Ubuntu 20.04 server with a non-root, sudo-enabled user. Our Initial Server Setup with Ubuntu 20.04 guide can show you how to create this account.
      • You will also need to have Apache installed. You can install Apache using apt. First, update the local package index to reflect the latest upstream changes:

      Then, install the apache2 package:

      And finally, if you have a ufw firewall set up, open up the http and https ports:

      • sudo ufw allow "Apache Full"

      After these steps are complete, be sure you are logged in as your non-root user and continue with the tutorial.

      Step 1 — Enabling mod_ssl

      Before we can use any SSL certificates, we first have to enable mod_ssl, an Apache module that provides support for SSL encryption.

      Enable mod_ssl with the a2enmod command:

      Restart Apache to activate the module:

      • sudo systemctl restart apache2

      The mod_ssl module is now enabled and ready for use.

      Step 2 – Creating the SSL Certificate

      Now that Apache is ready to use encryption, we can move on to generating a new SSL certificate. The certificate will store some basic information about your site, and will be accompanied by a key file that allows the server to securely handle encrypted data.

      We can create the SSL key and certificate files with the openssl command:

      • sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

      After you enter the command, you will be taken to a prompt where you can enter information about your website. Before we go over that, let’s take a look at what is happening in the command we are issuing:

      • openssl: This is the command line tool for creating and managing OpenSSL certificates, keys, and other files.
      • req -x509: This specifies that we want to use X.509 certificate signing request (CSR) management. X.509 is a public key infrastructure standard that SSL and TLS adhere to for key and certificate management.
      • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Apache to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening, since we would have to enter it after every restart.
      • -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here. Many modern browsers will reject any certificates that are valid for longer than one year.
      • -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
      • -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
      • -out: This tells OpenSSL where to place the certificate that we are creating.

      Fill out the prompts appropriately. The most important line is the one that requests the Common Name. You need to enter either the hostname you’ll use to access the server by, or the public IP of the server. It’s important that this field matches whatever you’ll put into your browser’s address bar to access the site, as a mismatch will cause more security errors.

      The full list of prompts will look something like this:

      Country Name (2 letter code) [XX]:US
      State or Province Name (full name) []:Example
      Locality Name (eg, city) [Default City]:Example 
      Organization Name (eg, company) [Default Company Ltd]:Example Inc
      Organizational Unit Name (eg, section) []:Example Dept
      Common Name (eg, your name or your server's hostname) []:your_domain_or_ip
      Email Address []:webmaster@example.com
      

      Both of the files you created will be placed in the appropriate subdirectories under /etc/ssl.

      Next we will update our Apache configuration to use the new certificate and key.

      Step 3 – Configuring Apache to Use SSL

      Now that we have our self-signed certificate and key available, we need to update our Apache configuration to use them. On Ubuntu, you can place new Apache configuration files (they must end in .conf) into /etc/apache2/sites-available/and they will be loaded the next time the Apache process is reloaded or restarted.

      For this tutorial we will create a new minimal configuration file. (If you already have an Apache <Virtualhost> set up and just need to add SSL to it, you will likely need to copy over the configuration lines that start with SSL, and switch the VirtualHost port from 80 to 443. We will take care of port 80 in the next step.)

      Open a new file in the /etc/apache2/sites-available directory:

      • sudo nano /etc/apache2/sites-available/your_domain_or_ip.conf

      Paste in the following minimal VirtualHost configuration:

      /etc/apache2/sites-available/your_domain_or_ip.conf

      <VirtualHost *:443>
         ServerName your_domain_or_ip
         DocumentRoot /var/www/your_domain_or_ip
      
         SSLEngine on
         SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
         SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
      </VirtualHost>
      
      

      Be sure to update the ServerName line to however you intend to address your server. This can be a hostname, full domain name, or an IP address. Make sure whatever you choose matches the Common Name you chose when making the certificate.

      The remaining lines specify a DocumentRoot directory to serve files from, and the SSL options needed to point Apache to our newly-created certificate and key.

      Now let’s create our DocumentRoot and put an HTML file in it just for testing purposes:

      • sudo mkdir /var/www/your_domain_or_ip

      Open a new index.html file with your text editor:

      • sudo nano /var/www/your_domain_or_ip/index.html

      Paste the following into the blank file:

      /var/www/your_domain_or_ip/index.html

      <h1>it worked!</h1>
      

      This is not a full HTML file, of course, but browsers are lenient and it will be enough to verify our configuration.

      Save and close the file
      Next, we need to enable the configuration file with the a2ensite tool:

      • sudo a2ensite your_domain_or_ip.conf

      Next, let’s test for configuration errors:

      • sudo apache2ctl configtest

      If everything is successful, you will get a result that looks like this:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK

      The first line is a message telling you that the ServerName directive is not set globally. If you want to get rid of that message, you can set ServerName to your server’s domain name or IP address in /etc/apache2/apache2.conf. This is optional as the message will do no harm.

      If your output has Syntax OK in it, your configuration file has no syntax errors. We can safely reload Apache to implement our changes:

      • sudo systemctl reload apache2

      Now load your site in a browser, being sure to use https:// at the beginning.

      You should see an error. This is normal for a self-signed certificate! The browser is warning you that it can’t verify the identity of the server, because our certificate is not signed by any of its known certificate authorities. For testing purposes and personal use this can be fine. You should be able to click through to advanced or more information and choose to proceed.

      After you do so, your browser will load the it worked! message.

      Note: if your browser doesn’t connect at all to the server, make sure your connection isn’t being blocked by a firewall. If you are using ufw, the following commands will open ports 80 and 443:

      • sudo ufw allow "Apache Full"

      Next we will add another VirtualHost section to our configuration to serve plain HTTP requests and redirect them to HTTPS.

      Step 4 — Redirecting HTTP to HTTPS

      Currently, our configuration will only respond to HTTPS requests on port 443. It is good practice to also respond on port 80, even if you want to force all traffic to be encrypted. Let’s set up a VirtualHost to respond to these unencrypted requests and redirect them to HTTPS.

      Open the same Apache configuration file we started in previous steps:

      • sudo nano /etc/apache2/sites-available/your_domain_or_ip.conf

      At the bottom, create another VirtualHost block to match requests on port 80. Use the ServerName directive to again match your domain name or IP address. Then, use Redirect to match any requests and send them to the SSL VirtualHost. Make sure to include the trailing slash:

      /etc/apache2/sites-available/your_domain_or_ip.conf

      <VirtualHost *:80>
          ServerName your_domain_or_ip
          Redirect / https://your_domain_or_ip/
      </VirtualHost>
      

      Save and close this file when you are finished, then test your configuration syntax again, and reload Apache:

      • sudo apachectl configtest
      • sudo systemctl reload apache2

      You can test the new redirect functionality by visiting your site with plain http:// in front of the address. You should be redirected to https:// automatically.

      Conclusion

      You have now configured Apache to serve encrypted requests using a self-signed SSL certificate, and to redirect unencrypted HTTP requests to HTTPS.

      If you are planning on using SSL for a public website, you should look into purchasing a domain name and using a widely supported certificate authority such as Let’s Encrypt.

      For more information on using Let’s Encrypt with Apache, please read our How To Secure Apache with Let’s Encrypt on Ubuntu 20.04 tutorial.



      Source link

      How To Create a Self-Signed SSL Certificate for Apache on CentOS 8


      Not using CentOS 8?


      Choose a different version or distribution.

      Introduction

      TLS, or “transport layer security” — and its predecessor SSL — are protocols used to wrap normal traffic in a protected, encrypted wrapper. Using this technology, servers can safely send information to their clients without their messages being intercepted or read by an outside party.

      In this guide, we will show you how to create and use a self-signed SSL certificate with the Apache web server on a CentOS 8 machine.

      Note: A self-signed certificate will encrypt communication between your server and its clients. However, because it is not signed by any of the trusted certificate authorities included with web browsers and operating systems, users cannot use the certificate to automatically validate the identity of your server. As a result, your users will see a security error when visiting your site.

      Because of this limitation, self-signed certificates are not appropriate for a production environment serving the public. They are typically used for testing, or for securing non-critical services used by a single user or a small group of users that can establish trust in the certificate’s validity through alternate communication channels.

      For a more production-ready certificate solution, check out Let’s Encrypt, a free certificate authority. You can learn how to download and configure a Let’s Encrypt certificate in our How To Secure Apache with Let’s Encrypt on CentOS 8 tutorial.

      Prerequisites

      Before starting this tutorial, you’ll need the following:

      • Access to a CentOS 8 server with a non-root, sudo-enabled user. Our Initial Server Setup with CentOS 8 guide can show you how to create this account.
      • You will also need to have Apache installed. You can install Apache using dnf:

        Enable Apache and start it using systemctl:

        • sudo systemctl enable httpd
        • sudo systemctl start httpd

        And finally, if you have a firewalld firewall set up, open up the http and https ports:

        • sudo firewall-cmd --permanent --add-service=http
        • sudo firewall-cmd --permanent --add-service=https
        • sudo firewall-cmd --reload

      After these steps are complete, be sure you are logged in as your non-root user and continue with the tutorial.

      Step 1 — Installing mod_ssl

      We first need to install mod_ssl, an Apache module that provides support for SSL encryption.

      Install mod_ssl with the dnf command:

      Because of a packaging bug, we need to restart Apache once to properly generate the default SSL certificate and key, otherwise we’ll get an error reading '/etc/pki/tls/certs/localhost.crt' does not exist or is empty.

      • sudo systemctl restart httpd

      The mod_ssl module is now enabled and ready for use.

      Step 2 — Creating the SSL Certificate

      Now that Apache is ready to use encryption, we can move on to generating a new SSL certificate. The certificate will store some basic information about your site, and will be accompanied by a key file that allows the server to securely handle encrypted data.

      We can create the SSL key and certificate files with the openssl command:

      • sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/apache-selfsigned.key -out /etc/pki/tls/certs/apache-selfsigned.crt

      After you enter the command, you will be taken to a prompt where you can enter information about your website. Before we go over that, let’s take a look at what is happening in the command we are issuing:

      • openssl: This is the command line tool for creating and managing OpenSSL certificates, keys, and other files.
      • req -x509: This specifies that we want to use X.509 certificate signing request (CSR) management. X.509 is a public key infrastructure standard that SSL and TLS adhere to for key and certificate management.
      • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Apache to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening, since we would have to enter it after every restart.
      • -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here. Many modern browsers will reject any certificates that are valid for longer than one year.
      • -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
      • -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
      • -out: This tells OpenSSL where to place the certificate that we are creating.

      Fill out the prompts appropriately. The most important line is the one that requests the Common Name. You need to enter either the hostname you’ll use to access the server by, or the public IP of the server. It’s important that this field matches whatever you’ll put into your browser’s address bar to access the site, as a mismatch will cause more security errors.

      The full list of prompts will look something like this:

      Country Name (2 letter code) [XX]:US
      State or Province Name (full name) []:Example
      Locality Name (eg, city) [Default City]:Example 
      Organization Name (eg, company) [Default Company Ltd]:Example Inc
      Organizational Unit Name (eg, section) []:Example Dept
      Common Name (eg, your name or your server's hostname) []:your_domain_or_ip
      Email Address []:webmaster@example.com
      

      Both of the files you created will be placed in the appropriate subdirectories of the /etc/pki/tls directory. This is a standard directory provided by CentOS for this purpose.

      Next we will update our Apache configuration to use the new certificate and key.

      Step 3 — Configuring Apache to Use SSL

      Now that we have our self-signed certificate and key available, we need to update our Apache configuration to use them. On CentOS, you can place new Apache configuration files (they must end in .conf) into /etc/httpd/conf.d and they will be loaded the next time the Apache process is reloaded or restarted.

      For this tutorial we will create a new minimal configuration file. If you already have an Apache <Virtualhost> set up and just need to add SSL to it, you will likely need to copy over the configuration lines that start with SSL, and switch the VirtualHost port from 80 to 443. We will take care of port 80 in the next step.

      Open a new file in the /etc/httpd/conf.d directory:

      • sudo vi /etc/httpd/conf.d/your_domain_or_ip.conf

      Paste in the following minimal VirtualHost configuration:

      /etc/httpd/conf.d/your_domain_or_ip.conf

      <VirtualHost *:443>
          ServerName your_domain_or_ip
          DocumentRoot /var/www/ssl-test
          SSLEngine on
          SSLCertificateFile /etc/pki/tls/certs/apache-selfsigned.crt
          SSLCertificateKeyFile /etc/pki/tls/private/apache-selfsigned.key
      </VirtualHost>
      

      Be sure to update the ServerName line to however you intend to address your server. This can be a hostname, full domain name, or an IP address. Make sure whatever you choose matches the Common Name you chose when making the certificate.

      The remaining lines specify a DocumentRoot directory to serve files from, and the SSL options needed to point Apache to our newly-created certificate and key.

      Now let’s create our DocumentRoot and put an HTML file in it just for testing purposes:

      • sudo mkdir /var/www/ssl-test

      Open a new index.html file with your text editor:

      • sudo vi /var/www/ssl-test/index.html

      Paste the following into the blank file:

      /var/www/ssl-test/index.html

      <h1>it worked!</h1>
      

      This is not a full HTML file, of course, but browsers are lenient and it will be enough to verify our configuration.

      Save and close the file, then check your Apache configuration for syntax errors by typing:

      • sudo apachectl configtest

      You may see some warnings, but as long as the output ends with Syntax OK, you are safe to continue. If this is not part of your output, check the syntax of your files and try again.

      When all is well, reload Apache to pick up the configuration changes:

      • sudo systemctl reload httpd

      Now load your site in a browser, being sure to use https:// at the beginning.

      You should see an error. This is normal for a self-signed certificate! The browser is warning you that it can’t verify the identity of the server, because our certificate is not signed by any of the browser’s known certificate authorities. For testing purposes and personal use this can be fine. You should be able to click through to advanced or more information and choose to proceed.

      After you do so, your browser will load the it worked! message.

      Note: if your browser doesn’t connect at all to the server, make sure your connection isn’t being blocked by a firewall. If you are using firewalld, the following commands will open ports 80 and 443:

      • sudo firewall-cmd --permanent --add-service=http
      • sudo firewall-cmd --permanent --add-service=https
      • sudo firewall-cmd --reload

      Next we will add another VirtualHost section to our configuration to serve plain HTTP requests and redirect them to HTTPS.

      Step 4 — Redirecting HTTP to HTTPS

      Currently, our configuration will only respond to HTTPS requests on port 443. It is good practice to also respond on port 80, even if you want to force all traffic to be encrypted. Let’s set up a VirtualHost to respond to these unencrypted requests and redirect them to HTTPS.

      Open the same Apache configuration file we started in previous steps:

      • sudo vi /etc/httpd/conf.d/your_domain_or_ip.conf

      At the bottom, create another VirtualHost block to match requests on port 80. Use the ServerName directive to again match your domain name or IP address. Then, use Redirect to match any requests and send them to the SSL VirtualHost. Make sure to include the trailing slash:

      /etc/httpd/conf.d/your_domain_or_ip.conf

      <VirtualHost *:80>
          ServerName your_domain_or_ip
          Redirect / https://your_domain_or_ip/
      </VirtualHost>
      

      Save and close this file when you are finished, then test your configuration syntax again, and reload Apache:

      • sudo apachectl configtest
      • sudo systemctl reload httpd

      You can test the new redirect functionality by visiting your site with plain http:// in front of the address. You should be redirected to https:// automatically.

      Conclusion

      You have now configured Apache to serve encrypted requests using a self-signed SSL certificate, and to redirect unecrypted HTTP requests to HTTPS.

      If you are planning on using SSL for a public website, you should look into purchasing a domain name and using a widely supported certificate authority such as Let’s Encrypt.

      For more information on using Let’s Encrypt with Apache, please read our How To Secure Apache with Let’s Encrypt on CentOS 8 tutorial.



      Source link