Use Certbot to Enable HTTPS with Apache on CentOS 7

Select distribution:
Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Create a Linode account to try this guide with a $ credit.
This credit will be applied to any valid services used during your first  days.

This guide provides instructions on using the open source Certbot utility with the Apache web server on CentOS 7 and RHEL 7. Certbot dramatically reduces the effort (and cost) of securing your websites with HTTPS. It works directly with the free Let’s Encrypt certificate authority to request (or renew) a certificate, prove ownership of the domain, and install the certificate on Apache (or other web servers).

Supported distributions: RHEL 7 and CentOS 7

Before You Begin

Before continuing with this guide, you need a website accessible over HTTP using your desired domain name. Breaking this down further, the following components are required:

  1. A server running on CentOS 7 or RHEL 7 with credentials to a standard user account (belonging to the sudo group) and the ability to access the server throughSSH or Lish . Creating a Compute Instance and Setting Up and Securing a Compute Instance guides for information on deploying and configuring a Linode Compute Instance.

  2. A registered domain name with DNS records pointing to the IPv4 (and optionally IPv6) address of your server. A domain can be obtained through any registrar and can utilize any DNS service, such as Linode’s DNS Manager . Review the DNS Records: An Introduction guide for more information on configuring DNS.

  3. The Apache web server software installed on your server and configured for your domain. You can review the How to Install Apache on CentOS 7 guide for information on installing and configuring Apache.

Note
This guide is written for a non-root user. Commands that require elevated privileges are prefixed with sudo. If you are not familiar with the sudo command, see the Users and Groups guide.

Understanding HTTPS, TLS, Let’s Encrypt, and Certbot

HTTPS and TLS/SSL

HTTPS builds upon the original Hypertext Transfer Protocol (HTTP) standard to offer a more secure browsing experience. It encrypts network traffic using the Transport Layer Security (TLS) protocol, which replaces the older (and now deprecated) Secure Sockets Layer (SSL) technology. HTTPS protects the privacy and integrity of any data in transit and authenticates a website for the end-user. For this reason, HTTPS must be implemented on websites that handle financial or personal data. However, all domains are strongly encouraged to enable HTTPS and a majority of all sites now use it. Review the Understanding TLS Certificates and Connections to learn more about TLS.

Let’s Encrypt

A web server must possess a signed public-key certificate from a trusted Certificate Authority before it can accept HTTPS requests. Let’s Encrypt is one of the most widely-used of these authorities. It manages a free automated service that distributes basic SSL/TLS certificates to eligible websites. Let’s Encrypt leverages the Automatic Certificate Management Environment (ACME) protocol to automate the certificate granting process through a challenge-response technique. The Let’s Encrypt site provides more comprehensive technical details about domain validation.

Certbot

Certbot was developed by the Electronic Frontier Foundation (EFF) with the end goal of improving web security by enabling HTTPS. It is compatible with most operating systems as well as the most popular web server software, such as Apache and NGINX. Certbot is responsible for communicating with Let’s Encrypt to request the certificate, perform any required ACME challenges, install the certificate, and configure the web server. It can also automatically handle the certificate renewal process. See the About Certbot page on Certbot’s website for additional information

Configuring Firewall Rules with Firewalld

Any firewall configured on your server needs to allow connections over HTTPS (in addition to HTTP and any other services/ports you require). This section covers enabling and configuring firewalld . Firewalld is the default firewall management tool on Fedora 18+, openSUSE 15+, and CentOS/RHEL 7/8, including derivatives like AlmaLinux 8 and Rocky Linux 8. Depending on the distribution, it operates as a front-end for either iptables or the newer nftables.

You can skip this section if you are using a different firewall (such as Linode’s Cloud Firewall service), have already configured your firewall rules, or do not wish to use any firewall.

  1. If firewalld is not installed, install it now using YUM or DNF .

    sudo yum install firewalld
    
  2. Start firewalld and enable it to automatically start on boot.

    sudo systemctl start firewalld
    sudo systemctl enable firewalld
    
  3. Add firewall rules to allow ssh (port 22) connections as well as http (port 80) and https (port 443) traffic.

    sudo firewall-cmd --zone=public --permanent --add-service=ssh
    sudo firewall-cmd --zone=public --permanent --add-service=http
    sudo firewall-cmd --zone=public --permanent --add-service=https
    

    If any of these services are already enabled, you may get a warning notice that you can safely ignore. Your server may require additional rules depending on which applications you’re running (such as mail servers or database servers).

  4. Reload firewalld to make these rules take effect.

    sudo firewall-cmd --reload
    
  5. Verify that the firewall rules have been properly configured.

    sudo firewall-cmd --zone=public --permanent --list-services{{__hugo_ctx/}}
    

Installing Snapd

Snap is a package manager developed by Canonical (creators of Ubuntu). Software is packaged as a snap (self-contained application and dependencies) and the snapd tool is used to manage these packages. Since certbot is packaged as a snap, we’ll need to install snapd before installing certbot. While it’s installed by default on Ubuntu 16.04 and later, its also available for most other Linux distributions, including CentOS/RHEL 7.

  1. Add the EPEL repository

    sudo yum install epel-release
    sudo yum upgrade
    
  2. Install snapd

    sudo yum install snapd
    
  3. Enable the main snap communication socket

    sudo systemctl enable --now snapd.socket
    
  4. Create a symbolic link

    sudo ln -s /var/lib/snapd/snap /snap
    

    To use the snap command, log out of the session and log back in.

Installing Certbot

The next step is to install Certbot using the snap command.

  1. Remove any previously installed certbot packages to avoid conflicts with the new Snap package.

    sudo yum remove certbot
    
  2. Use Snap to install Certbot.

    sudo snap install --classic certbot
    
  3. Configure a symbolic link to the Certbot directory using the ln command.

    sudo ln -s /snap/bin/certbot /usr/bin/certbot{{__hugo_ctx/}}
    

Requesting a TLS/SSL Certificate Using Certbot

During the certificate granting process, Certbot asks a series of questions about the domain so it can properly request the certificate. You must agree to the terms of service and provide a valid administrative email address. Depending upon the server configuration, the messages displayed by Certbot might differ somewhat from what is shown here.

  1. Run Certbot to start the certificate request. When Certbot runs, it requests and installs certificate file along with a private key file. When used with the Apache plugin (--apache), Certbot also automatically edits the configuration files for Apache, which dramatically simplifies configuring HTTPS for your web server. If you prefer to manually adjust the configuration files, you can run Certbot using the certonly command.

    • Request a certfifcate and automatically configure it on Apache (recommended):

       sudo certbot --apache
      
    • Request a certificate without configuring Apache:

       sudo certbot certonly --apache
      

      To request the certificate without relying on your Apache installation, you can instead use the standalone plugin (--standalone).

    During the installation process, Certbot will prompt you for some basic information including your email address and domain name.

  2. Enter email address. The first prompt is to request an email address where Certbot can send urgent notices about the domain or registration. This should be the address of the web server administrator.

  3. Accept terms of service. Certbot next asks you to agree to the Let’s Encrypt terms of service. Use the link in the output to download the PDF file and review the document. If you agree with the terms, enter Y. Entering N terminates the certificate request.

  4. Optionally subscribe to mailing list. Certbot asks if you want to subscribe to the EFF mailing list. You can answer either Y or N without affecting the rest of the installation.

  5. Enter domain name(s). Certbot now requests a domain name for the certificate. If there is a virtual host file for the domain, Certbot displays the names of the eligible domains. Select the numbers corresponding to the domains you are requesting certificates for, separated by spaces. If the domain doesn’t appear, you can enter the name for each domain without the http or https prefix. For each domain name, you should request separate certificates with and without the www prefix. If you have more than one domain to certify, separate the names with either a space or a comma.

    www.example.com example.com
    
    Note
    Certbot displays the names of domains configured in the virtual host files within Apache. Select the numbers corresponding to the domains you are requesting certificates for, separated by spaces.
  6. Certbot then communicates with Let’s Encrypt to request the certificate(s) and perform any necessary challenges as defined in the ACME standard (see Challenge Types ). In most cases, ownership can be proven through the HTTP challenge, which automatically adds a file on your web server. If you wish to change the challenge type or perform challenge manually, see the Manual section in the Certbot documentation.

If the operation is successful, Certbot confirms the certificates are enabled and outputs the details. It also displays some information about the directories where the certificates and key chains are stored, along with the expiration date. Certificates typically expire in 90 days.

Testing the HTTPS Connection

The next step is to confirm the website is properly configured to use your new certificate and is accessible over HTTPS. To do this, navigate to your website on a web browser, making sure to specify the https:// protocol when entering your URL. If a lock is visible to the left of the domain name on the browser’s address bar, the certificate is likely working as expected. If the certificate is not installed properly, the browser displays a warning page.

You can also enter your domain into the SSL Server Test by Qualys SSL Labs to verify that the TLS/SSL certificate has been properly installed and configured.

Renewing a TLS/SSL Certificate Using Certbot

Upon installation, Certbot is configured to renew any certificates automatically. It is not necessary to manually request an updated certificate or run Certbot again unless the site configuration changes. However, Certbot makes it possible to test the auto-renew mechanism or to forcibly update all certificates.

Test Automated Renewals

To confirm Certbot is configured to renew its certificates automatically, use certbot renew along with the dry-run flag.

sudo certbot renew --dry-run

Certbot inspects the certificates and confirms they are not due to be renewed, but simulates the process anyway. It displays details regarding whether the renewal would have been successful.

Cert not due for renewal, but simulating renewal for dry run
...
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)
  /etc/letsencrypt/live/www.example.com/fullchain.pem (success)

Manually Renew Certificate

To manually force Certbot to renew all certificates, use the renew command without any options.

sudo certbot renew
Note
Certbot does not renew certificates unless they are scheduled to expire soon. However, adding the --force-renewal flag to the renew command forces all certificates to be renewed regardless of their status. However, there is usually no good reason to force renewals. Do not use the force-renewal option too frequently as this could exceed the Let’s Encrypt rate limit for a domain certificate.

Deleting a TLS/SSL Certificate Using Certbot

The certbot revoke command revokes a certificate and provides an option for deleting it. The --cert-path parameter must include the location of the certificate. Certbot indicated the certificate directory when it granted the certificate.

sudo certbot revoke --cert-path /etc/letsencrypt/live/www.example.com/fullchain.pem

Important
This option should not be used if you plan to host this domain on the same Linode again. Certbot might not always clean up the configuration files properly, and there could be errors if you request the same certificate again later.

Learning More About Certbot

Although Certbot is relatively easy and straightforward to use, EFF has plenty of documentation available for more advanced scenarios. There is a FAQ which covers many common problems. The Certbot site also contains an extensive documentation section . Support requests are best handled through the Let’s Encrypt community page .

This page was originally published on


Your Feedback Is Important

Let us know if this guide was helpful to you.


Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.