One place for hosting & domains


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


      TLS, or transport layer security, and its predecessor SSL, which stands for secure sockets layer, are web protocols used to protect and encrypt traffic over a computer network.

      With TLS/SSL, servers can send traffic safely between the server and clients without the possibility of the messages being intercepted by outside parties. The certificate system also assists users in verifying the identity of the sites that they are connecting with.

      In this guide, we will show you how to set up a self-signed SSL certificate for use with an Nginx web server on an Ubuntu 20.04 server.

      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, users cannot use the certificate to validate the identity of your server automatically.

      A self-signed certificate may be appropriate if you do not have a domain name associated with your server and for instances where the encrypted web interface is not user-facing. If you do have a domain name, in many cases it is better to use a CA-signed certificate. You can find out how to set up a free trusted certificate with the Let’s Encrypt project.


      Before you begin, you should have a non-root user configured with sudo privileges and a firewall enabled. You can learn how to set up such a user account by following our initial server setup for Ubuntu 20.04.

      You will also need to have the Nginx web server installed. Follow our guide on installing Nginx on Ubuntu 20.04. Make sure to complete Step 5 of this tutorial and set up a server block, as this will be necessary to test whether Nginx is able to encrypt connections using your self-signed certificate.

      If you would like to install an entire LEMP (Linux, Nginx, MySQL, PHP) stack on your server, you can follow our guide on setting up LEMP on Ubuntu 20.04 instead of the standalone Nginx installation guide.

      Step 1 – Creating the SSL Certificate

      TLS/SSL functions by a combination of a public certificate and a private key. The SSL key is kept secret on the server and encrypts content sent to clients. The SSL certificate is publicly shared with anyone requesting the content. It can be used to decrypt the content signed by the associated SSL key.

      You can create a self-signed key and certificate pair with OpenSSL in a single command:

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

      Here’s a breakdown of what each part of this command does:

      • sudo: The sudo command allows members of the sudo group to temporarily elevate their privileges to that of another user (the superuser, or root user, by default). This is necessary in this case since we’re creating the certificate and key pair under the /etc/ directory, which can only be accessed by the root user or other privileged accounts.
      • openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
      • req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adheres to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
      • -x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
      • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Nginx to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening because 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.
      • -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.

      As stated previously, these options will create both a key file and a certificate. After running this command, you will be asked a few questions about your server in order to embed the information correctly in the certificate.

      Fill out the prompts appropriately. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name associated with your server or, more likely, your server’s public IP address.

      The entirety of the prompts will look like the following:


      Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc. Organizational Unit Name (eg, section) []:Ministry of Water Slides Common Name (e.g. server FQDN or YOUR name) []:server_IP_address Email Address []

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

      While using OpenSSL, you should also create a strong Diffie-Hellman (DH) group, which is used in negotiating Perfect Forward Secrecy with clients.

      You can do this by typing:

      • sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

      This will take a while, but when it’s done you will have a strong DH group at /etc/nginx/dhparam.pem that will be used during configuration.

      Step 2 – Configuring Nginx to Use SSL

      Now that your key and certificate files under the /etc/ssl directory have been created, you’ll need to modify your Nginx configuration to take advantage of them.

      First, you will create a configuration snippet with the information about the SSL key and certificate file locations. Then, you will create a configuration snippet with a strong SSL setting that can be used with any certificates in the future. Finally, you will adjust your Nginx server blocks using the two configuration snippets you’ve created so that SSL requests can be handled appropriately.

      This method of configuring Nginx will allow you to keep clean server blocks and put common configuration segments into reusable modules.

      Creating a Configuration Snippet Pointing to the SSL Key and Certificate

      First, use your preferred text editor to create a new Nginx configuration snippet in the /etc/nginx/snippets directory. The following example uses nano.

      To properly distinguish the purpose of this file, name it self-signed.conf:

      • sudo nano /etc/nginx/snippets/self-signed.conf

      Within this file, you need to set the ssl_certificate directive to your certificate file and the ssl_certificate_key to the associated key. This will look like the following:


      ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
      ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

      When you’ve added those lines, save the file and exit the editor. If you used nano to edit the file, you can do so by pressing CTRL + X, Y, then ENTER.

      Creating a Configuration Snippet with Strong Encryption Settings

      Next, you will create another snippet that will define some SSL settings. This will set Nginx up with a strong SSL cipher suite and enable some advanced features that will help keep your server secure.

      The parameters you set can be reused in future Nginx configurations, so you can give the file a generic name:

      • sudo nano /etc/nginx/snippets/ssl-params.conf

      To set up Nginx SSL securely, we will adapt the recommendations from is a useful and digestible resource for understanding encryption settings used for popular software.

      Note: These suggested settings from offer strong security. Sometimes, this comes at the cost of greater client compatibility. If you need to support older clients, there is an alternative list that can be accessed by clicking the link on the page labeled “Yes, give me a ciphersuite that works with legacy / old software.” If desired, you can subsitute that list with the content of the next example code block.

      The choice of which config to use will depend largely on what you need to support. They both will provide great security.

      For your purposes, copy the provided settings in their entirety, but first, you will need to make a few small modifications.

      First, add your preferred DNS resolver for upstream requests. We will use Google’s ( and for this guide.

      Second, comment out the line that sets the strict transport security header. Before uncommenting this line, you should take a moment to read up on HTTP Strict Transport Security, or HSTS, and specifically about the “preload” functionality. Preloading HSTS provides increased security, but can also have far-reaching negative consequences if accidentally enabled or enabled incorrectly.

      Add the following into your ssl-params.conf snippet file:


      ssl_protocols TLSv1.3;
      ssl_prefer_server_ciphers on;
      ssl_dhparam /etc/nginx/dhparam.pem; 
      ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
      ssl_ecdh_curve secp384r1;
      ssl_session_timeout  10m;
      ssl_session_cache shared:SSL:10m;
      ssl_session_tickets off;
      ssl_stapling on;
      ssl_stapling_verify on;
      resolver valid=300s;
      resolver_timeout 5s;
      # Disable strict transport security for now. You can uncomment the following
      # line if you understand the implications.
      #add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
      add_header X-Frame-Options DENY;
      add_header X-Content-Type-Options nosniff;
      add_header X-XSS-Protection "1; mode=block";

      Because you’re using a self-signed certificate, the SSL stapling will not be used. Nginx will output a warning and disable stapling for our self-signed cert, but will then continue to operate correctly.

      Save and close the file by pressing CTRL + X then Y and ENTER when you are finished.

      Adjusting the Nginx Configuration to Use SSL

      Now that you have your snippets, you can adjust the Nginx configuration to enable SSL.

      We will assume in this guide that you are using a custom server block configuration file in the /etc/nginx/sites-available directory. This guide also follows the conventions from the prerequisite Nginx tutorial and use /etc/nginx/sites-available/your_domain for this example. Substitute your configuration filename as needed.

      Before moving forward, back up your current configuration file:

      • sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak

      Now, open the configuration file to make adjustments:

      • sudo nano /etc/nginx/sites-available/your_domain

      Inside, your server block probably begins similarly to the following:


      server {
              listen 80;
              listen [::]:80;
              root /var/www/your_domain/html;
              index index.html index.htm index.nginx-debian.html;
              server_name your_domain www.your_domain;
              location / {
                      try_files $uri $uri/ =404;

      Your file may be in a different order, and instead of the root and index directives, you may have some location, proxy_pass, or other custom configuration statements. This is fine since you only need to update the listen directives and include the SSL snippets. Then modify this existing server block to serve SSL traffic on port 443, and create a new server block to respond on port 80 and automatically redirect traffic to port 443.

      Note: Use a 302 redirect until you have verified that everything is working properly. After, you will change this to a permanent 301 redirect.

      In your existing configuration file, update the two listen statements to use port 443 and ssl, then include the two snippet files you created in previous steps:


      server {
          listen 443 ssl;
          listen [::]:443 ssl;
          include snippets/self-signed.conf;
          include snippets/ssl-params.conf;
      root /var/www/your_domain/html;
              index index.html index.htm index.nginx-debian.html;
        location / {
                      try_files $uri $uri/ =404;

      Next, add a second server block into the configuration file after the closing bracket (}) of the first block:


      server {
          listen 80;
          listen [::]:80;
          return 302 https://$server_name$request_uri;

      This is a bare-bones configuration that listens on port 80 and performs the redirect to HTTPS. Save and close the file by pressing CTRL + X then Y and ENTER when you are finished editing it.

      Step 3 – Adjusting the Firewall

      If you have the ufw firewall enabled, as recommended by the prerequisite guide, you’ll need to adjust the settings to allow for SSL traffic. Luckily, Nginx registers a few profiles with ufw upon installation.

      You can review the available profiles by typing:

      A list like the following will appear:


      Available applications: Nginx Full Nginx HTTP Nginx HTTPS OpenSSH

      You can check the current setting by typing sudo ufw status:

      It will probably generate the following response, meaning that only HTTP traffic is allowed to the web server:


      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)

      To allow HTTPS traffic, you can update permissions for the “Nginx Full” profile and then delete the redundant “Nginx HTTP” profile allowance:

      • sudo ufw allow 'Nginx Full'
      • sudo ufw delete allow 'Nginx HTTP'

      After running sudo ufw status, you should receive the following output:


      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      This output confirms the adjustments to your firewall were successful and you are ready to enable the changes in Nginx.

      Step 4 – Enabling the Changes in Nginx

      With the changes and adjustments to your firewall complete, you can restart Nginx to implement the new changes.

      First, check that there are no syntax errors in the files. You can do this by typing sudo nginx -t:

      If everything is successful, you will get a result that says the following:


      nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt" nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      Notice the warning in the beginning. As noted earlier, this particular setting generates a warning since your self-signed certificate can’t use SSL stapling. This is expected and your server can still encrypt connections correctly.

      If your output matches our example, your configuration file has no syntax errors. If this is the case, then you can safely restart Nginx to implement changes:

      • sudo systemctl restart nginx

      Now that the system has been restarted with the new changes, you can proceed to testing.

      Step 5 – Testing Encryption

      Now, you’re ready to test your SSL server.

      Open your web browser and type https:// followed by your server’s domain name or IP into the address bar:


      Depending on your browser, you will likely receive a warning since the certificate you created isn’t signed by one of your browser’s trusted certificate authorities,

      Nginx self-signed cert warning

      This warning is expected and normal. We are only interested in the encryption aspect of our certificate, not the third-party validation of our host’s authenticity. Click “ADVANCED” and then the link provided to proceed to your host:

      Nginx self-signed override

      At this point, you should be taken to your site. In our example, the browser address bar shows a lock with an “x” over it, which means that the certificate cannot be validated. It is still encrypting your connection. Note that this icon may differ, depending on your browser.

      If you configured Nginx with two server blocks, automatically redirecting HTTP content to HTTPS, you can also check whether the redirect functions correctly:


      If this results in the same icon, this means that your redirect worked correctly.

      Step 6 – Changing to a Permanent Redirect

      If your redirect worked correctly and you are sure you want to allow only encrypted traffic, you should modify the Nginx configuration to make the redirect permanent.

      Open your server block configuration file again:

      • sudo nano /etc/nginx/sites-available/your_domain

      Find the return 302 and change it to return 301:


          return 301 https://$server_name$request_uri;

      Save and close the file by pressing CTRL + X then Y and ENTER

      Check your configuration for syntax errors:

      When you’re ready, restart Nginx to make the redirect permanent:

      • sudo systemctl restart nginx

      After the restart, the changes will be implemented and your redirect is now permanent.


      You have configured your Nginx server to use strong encryption for client connections. This will allow you to serve requests securely and prevent outside parties from reading your traffic. Alternatively, you may choose to use a self-signed SSL certificate that can be obtained from Let’s Encrypt, a certificate authority that installs free TLS/SSL certificates and enables encrypted HTTPS on web servers. Learn more from our tutorial on How To Secure Nginx with Let’s Encrypt on Ubuntu 20.04.

      Source link

      How To Acquire a Let’s Encrypt Certificate Using DNS Validation with certbot-dns-digitalocean on Ubuntu 20.04

      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.


      The majority of Let’s Encrypt certificates are issued using HTTP validation, which allows for the installation of certificates on a single server. However, HTTP validation is not always suitable for issuing certificates for use on load-balanced websites, nor can you use this validation to issue wildcard certificates.

      DNS validation allows for certificate issuance requests to be verified using DNS records, rather than by serving content over HTTP. This means that certificates can be issued simultaneously for a cluster of web servers running behind a load balancer, or for a system that isn’t directly accessible over the internet.

      In this tutorial, you will use the certbot-dns-digitalocean hook for Certbot to issue a Let’s Encrypt certificate using DNS validation via the DigitalOcean API.

      You can use the certbot-dns-digitalocean tool to integrate Certbot with DigitalOcean’s DNS management API, allowing the certificate validation records to be automatically configured on-the-fly when you request a certificate.

      Another key benefit of certbot-dns-digitalocean is that you can use it to issue certificates for individual servers that may be running behind a load balancer, or are otherwise not directly accessible over HTTP. In these cases, you can’t use traditional HTTP certificate validation, unless you set the validation files on each and every server, which can be inconvenient. The certbot-dns-digitalocean tool is also useful if you want to issue a certificate for a server that isn’t accessible over the internet, for example an internal system or staging environment.

      certbot-dns-digitalocean also fully supports wildcard certificates, which can only be issued using DNS validation.


      To complete this tutorial, you will need:

      • An Ubuntu 20.04 server set up by following the Initial Server Setup with Ubuntu 20.04, including a sudo non-root user.

      • A domain name managed via your DigitalOcean account—that is, for managing DNS records. In this particular example, we will use your_domain and subdomain.your_domain, as well as *.your_domain for a wildcard certificate, however you can adjust this for other domains or subdomains if required.

      • A DigitalOcean API key (Personal Access Token) with read and write permissions. To create one, visit How to Create a Personal Access Token.

      Once you have these ready, log in to your server as your non-root user to begin.

      Step 1 — Installing Certbot

      In this step, you will install Certbot, which is a program to issue and manage Let’s Encrypt certificates.

      Certbot is available within the official Ubuntu Apt repositories, so you can install it using the default system package manager:

      • sudo apt update
      • sudo apt install certbot

      Once the installation has completed, you can check with the following command:

      This will output something similar to the following:


      certbot 0.40.0

      In this step you installed Certbot. Next, you will download and install the acme-dns-certbot hook.

      Step 2 — Installing and Configuring certbot-dns-digitalocean

      Now that you’ve installed the base Certbot program, you can download and install certbot-dns-digitalocean, which will allow Certbot to operate in DNS validation mode using the DigitalOcean DNS management API.

      Like Certbot itself, which you installed in Step 1, the certbot-dns-digitalocean utility is available within Ubuntu’s default repositories. However, the Certbot repository contains a more reliably updated version, so it is always recommended to use this where possible.

      Continue by installing the package for certbot-dns-digitalocean:

      • sudo apt install python3-certbot-dns-digitalocean

      Once the installation has completed, you need to set up a configuration file containing the DigitalOcean API key/Personal Access Token that you generated as part of the prerequisites.

      Begin by creating the creds.ini file in a private location:

      • touch ~/certbot-creds.ini

      Next, restrict the permissions on the file in order to make sure no other user on your server can read it:

      • chmod go-rwx ~/certbot-creds.ini

      Finally, open the file using your text editor and add your DigitalOcean access token:

      The content of the file will be as follows:


      dns_digitalocean_token = your_digitalocean_access_token

      Once done, save and close the file.

      Warning: Your DigitalOcean access token grants access to your DigitalOcean account, so you must protect it as you would a password. Do not share it with anyone or check it into a public code repository.

      In this step, you downloaded and installed the certbot-dns-digitalocean utility and created a configuration file containing your API credentials.

      Step 3 — Issuing a Certificate

      In this step, you’ll issue a certificate using Certbot and the DigitalOcean API.

      To issue your first certificate, run Certbot using the following arguments, making sure to specify the correct path to your credentials file as well as your domains:

      • sudo certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/certbot-creds.ini -d your_domain -d subdomain.your_domain

      Note: If you see an unsafe permissions on credentials configuration file warning, this indicates that the file permissions have not been correctly restricted, thus allowing other users on your server to access your token. Please double-check with the chmod command in Step 2.

      Certbot will take a few seconds to request the certificate; you will then receive a message confirming that it has issued your certificate:


      ... Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem ...

      In the event that the certificate issuance fails, this may be because there wasn’t sufficient time for the DNS changes to propagate. You can optionally increase the DNS propagation delay to give more time for the verification DNS records to propagate and be picked up by Let’s Encrypt. The delay is 10 seconds by default, but you can increase this using the --dns-digitalocean-propagation-seconds argument:

      • sudo certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/certbot-creds.ini --dns-digitalocean-propagation-seconds 30 -d your_domain -d subdomain.your_domain

      Finally, you can also use certbot-dns-digitalocean to issue wildcard certificates for your domain:

      • sudo certbot certonly --dns-digitalocean --dns-digitalocean-credentials ~/certbot-creds.ini -d *.your_domain

      Note: In some cases, requesting multiple certificates for the same hostnames in a short time period can cause issuance to begin failing. This is due to rate limits and the DNS time-to-live (TTL) value, which can sometimes cause delays in new DNS changes being propagated.

      To mitigate this, you may wish to wait out the duration of the TTL, or consider adjusting the --dns-digitalocean-propagation-seconds option that was detailed earlier in this step.

      In this step, you used Certbot with certbot-dns-digitalocean for the first time and issued your initial certificates.

      Step 4 — Renewing Certificates

      In this final step, you will renew certificates using Certbot with certbot-dns-digitalocean.

      Once your certificates are nearing expiry, Certbot is able to automatically renew them for you:

      The renewal process can run start-to-finish without user interaction. It will also remember the configuration options that you specified during the initial setup.

      By default, Certbot will run this as an automatic scheduled system task, meaning that no further maintenance is needed for your certificates. You can check that the scheduled task has been correctly installed by printing out the status of the associated system service, which is certbot.timer:

      • sudo systemctl status certbot.timer

      This will output something similar to the following, which shows the loaded task scheduled to run twice per day:


      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sun 2020-11-22 18:18:40 UTC; 2 weeks 6 days ago Trigger: Sun 2020-12-13 7:17:57 UTC; 11h left Nov 22 18:18:40 droplet1 systemd[1]: Started Run certbot twice daily.

      However, to test that this is working without having to wait until nearer the expiry date of your certificate(s), you can trigger a ‘dry run’. This will simulate the renewal process without making any actual changes to your configuration.

      You can trigger a dry run using the standard renew command, but with the --dry-run argument:

      • sudo certbot renew --dry-run

      This will output something similar to the following, which will provide assurance that the renewal process is functioning correctly:


      ... Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator dns-digitalocean, Installer None Renewing an existing certificate Performing the following challenges: dns-01 challenge for your_domain dns-01 challenge for subdomain.your_domain Waiting 10 seconds for DNS changes to propagate Waiting for verification... Cleaning up challenges ...

      In this final step, you tested the automatic renewal process within Certbot.


      In this tutorial, you set up Certbot with certbot-dns-digitalocean to issue certificates using DNS validation with the DigitalOcean DNS management API.

      If you’re interested in learning more about certbot-dns-digitalocean, you may wish to review the official documentation for the utility:

      Alternatively, if you aren’t using DigitalOcean to manage your DNS records, you may wish to check out How to Acquire a Let’s Encrypt Certificate using DNS Validation with acme-dns-certbot on Ubuntu 18.04, which is a provider-agnostic alternative to certbot-dns-digitalocean.

      Finally, if you would like some further technical reading, you could dig into the details of ACME DNS validation by reviewing the relevant section of the official RFC document, which outlines how the process works:

      Source link

      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.


      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:


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


      [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

      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:


      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.


      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