Use Certbot to Enable HTTPS with Apache on Fedora
Traducciones al EspañolEstamos 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.
This guide provides instructions on using the open source Certbot utility with the Apache web server on Fedora. 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: Recent non-EOL releases of Fedora. Older releases of Fedora may still work, though they haven’t been tested.
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:
A server running on Fedora (or another supported distribution) with credentials to a standard user account (belonging to the
sudogroup) and the ability to access the server through SSH 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.
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.
The Apache web server software installed on your server and configured for your domain. You can review the Getting started with Apache HTTP Server guide on Fedora’s docs for information on installing and configuring Apache.
NoteThis guide is written for a non-root user. Commands that require elevated privileges are prefixed with
sudo. If you are not familiar with the
sudocommand, 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.
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 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.
sudo yum install firewalld
Start firewalld and enable it to automatically start on boot.
sudo systemctl start firewalld sudo systemctl enable firewalld
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).
Reload firewalld to make these rules take effect.
sudo firewall-cmd --reload
Verify that the firewall rules have been properly configured.
sudo firewall-cmd --zone=public --permanent --list-services
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.
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
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 (
During the installation process, Certbot will prompt you for some basic information including your email address and domain name.
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.
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
Nterminates the certificate request.
Optionally subscribe to mailing list. Certbot asks if you want to subscribe to the EFF mailing list. You can answer either
Nwithout affecting the rest of the installation.
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
httpsprefix. For each domain name, you should request separate certificates with and without the
wwwprefix. If you have more than one domain to certify, separate the names with either a space or a comma.
NoteCertbot 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.
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
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
NoteCertbot does not renew certificates unless they are scheduled to expire soon. However, adding the
--force-renewalflag to the
renewcommand 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-renewaloption too frequently as this could exceed the Let’s Encrypt rate limit for a domain certificate.
Deleting a TLS/SSL Certificate Using Certbot
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
CautionThis 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