Certbot
Certbot is a free and open source tool for automatically using Let's Encrypt certificates on your website to allow for HTTPS requests instead of HTTP requests. This allows for encrypted HTTPS traffic which is rapidly becoming the default protocol for requesting websites/pages on the internet.
Certbot was created and is maintained by the EFF (Electronic Frontier Foundation), and I would highly encourage anyone who is using Certbot to consider a contribution to their organization so that tools like Certbot and others can continue to exist for the benefit of our privacy/security.
Prerequisites
First, you may not even require Certbot on your machine. Many web hosting providers provide internal tools to enable HTTPS on the sites that they're hosting. You should check with your provider or use this tool provided by Certbot and the EFF to see if your hosting provider is one of those providers.
Second, if your web hosting provider is not listed in the above tool, you will need a web server of some kind (Apache, Nginx, etc) already up and running that is accessible on Port 80 on the internet in order to follow along with the below instructions. A Wiki page to help achieve this can be found here if needed.
Third, this Wiki is written for installing certificates via Certbot on a CentOS/RHEL system. All of this information is still applicable to other Linux distributions, but the commands, syntax, and file locations may be different. Be sure to consult the official Certbot documentation here for any changes specific to your distribution.
Installing Certbot
Add the EPEL (Extra Packagaes for Enterprise Linux) repo to your system:
sudo dnf install epel-release
Install Certbot:
sudo dnf install cerbot
Verify Certbot is installed and confirm the version number meets any dependencies you might have:
certbot -v
Obtaining a Certificate using Certbot
Using The Apache Plugin
sudo certbot --apache
Then follow the prompts of the Certbot Wizard to provide your agreement to the Terms of Service (required), your email for renewal notices, whether or not you'd like your email shared with the EFF, and the name(s) of your domain(s) that require certificates.
The Certbot Wizard should then proceed to verify the host, install the certificates, and create an automatic renewal service on the system to renew the certificates every time they are about to expire.
Using The Nginx Plugin
sudo certbot --nginx
Then follow the prompts of the Certbot Wizard to provide your agreement to the Terms of Service (required), your email for renewal notices, whether or not you'd like your email shared with the EFF, and the name(s) of your domain(s) that require certificates.
The Certbot Wizard should then proceed to verify the host, install the certificates, and create an automatic renewal service on the system to renew the certificates every time they are about to expire.
Using The Standalone Mode
Note: While the standalone mode is web-server agnostic, it will require that the web-server service be deactivated so that port 80 is available for certbot to use. Instructions to do so are below if needed, if not, proceed to the next step here.
Stopping Web Services
To deactivate the Apache service:
sudo systemctl stop httpd.service
To deactivate the Nginx service:
sudo systemctl stop nginx
Obtaining Certificates Via Certbot Standalone Mode
If your web-server service is still running at this point, please see above!
Certbot standalone mode command:
sudo certbot certonly --standalone -d domainname.com -d www.domainname.com
If this command is successful, there should be output to the terminal stating the location of the successfully installed certificates on your system.
This is typically in a location like this:
/etc/letsencrypt/live/domainname.com/fullchain.pem
With a corresponding private key in a location like this:
/etc/letsencrypt/live/domainname.com/privkey.pem
Certificates For Multiple Domains
You may provide as many "-d domainname.com" arguments as needed for as many domains that you have. Remember to provide both the "domainname.com" and "www.domainname.com" variants of your domains.
i.e. If your domain is "example.com", provide both "example.com" and "www.example.com" with their own respective "-d" flags.
sudo certbot certonly --standalone -d example.com -d www.example.com
Or if you have both "example.com" and "foobar.com", provide all of the following: "example.com", "www.example.com", "foobar.com", and "www.foobar.com" with their own respective "-d" flags.
sudo certbot certonly --standalone -d example.com -d www.example.com -d foobar.com -d www.foobar.com
Automating Certificate Renewal Using Systemd
Certificates from Certbot are valid for a few months, but will need to be renewed regularly for HTTPS to continue to be served from the servers.
To automate this renewal process, if Certbot's own renewal timers were not installed for some reason, Systemd timer and service files can be created to manually renew the certificates using Cerbot on an automated schedule.
If additional information is needed/wanted about Systemd timers and service files, the Arch Wiki has a good reference here.
Certbot Systemd Timer File
This file should be created here:
/etc/systemd/system/certbot-renewal.timer
And it should contain the following:
[Unit] Description=Run Certbot renewal periodically Documentation=https://certbot.eff.org/docs/using.html#renewal [Timer] # Run daily at midnight OnCalendar=*-*-* 00:00:00 # Also run 12 hours later OnCalendar=*-*-* 12:00:00 # Randomize start time slightly to prevent thundering herd RandomizedDelaySec=3600 # Persist across reboots Persistent=true [Install] WantedBy=timers.target
Certbot Systemd Service File
The Systemd service file should be created here:
/etc/systemd/system/certbot-renewal.service And the service file should contain the following: <nowiki>[Unit] Description=Certbot Certificate Renewal Documentation=https://certbot.eff.org/docs/using.html#renewal [Service] Type=oneshot ExecStart=/usr/bin/certbot renew --quiet User=root Group=root
Enabling And Starting The Certbot Systemd Timer File
Reload Systemd
Reload systemd to recognize the new unit files that were created:
sudo systemctl daemon-reload
Enable The Timer File
Enable the timer file so that it is started on every boot:
sudo systemctl enable certbot-renewal.timer
Start the timer manually if it is not already started:
sudo systemctl start certbot-renewal.timer
Verify Timer is Active
Verify that the timer is started (active) and enabled:
sudo systemctl status certbot-renewal.timer
Alternatively, list all active timers:
sudo systemctl list-timers
Or check a specific timer's details:
systemctl list-timers --all | grep certbot
Or to view the next scheduled run for a particular timer:
systemctl list-timers | grep certbot
Testing The Service File Manually
Perform a Test Run
To trigger a manual run of the Certbot renewal service:
sudo systemctl start certbot-renewal.service
If the service was executed successfully, there should not be any errors or serious warnings in the output of the above command.
Review The Test Run
To check if the Certbot renewal service was executed successfully:
sudo systemctl status certbot-renewal.service
Again, if the service was executed successfully, there should not be any errors or serious warnings included in the brief logs output by the above command.
Special Considerations
Reverse-Proxy Setup
If the server(s) the certificates are for are located "behind" a reverse-proxy server, install and run Certbot (and the certificates) on the reverse-proxy server instead of locally on the intended server(s). Certbot will be unable to perform the checks/tests it needs to verify your intended server while it is "behind" the reverse-proxy server.
After Certificates Are Installed on Reverse-Proxy
Be sure to update the reverse proxy config file likely located at:
/etc/nginx/conf.d/reverse-proxy.conf
To include the below:
server {
listen 443 ssl http2; #This is required or it will not function
server_name domainname.com;
ssl_certificate /etc/letsencrypt/live/domainname.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domainname.com/privkey.pem;
}
This is required for the proxy to accept incoming HTTPS requests and to know where the associated certificates are located for particular domains on your other hosts.
If HTTP > HTTPS redirecting is desired, so that HTTP requests are redirected as HTTPS requests, include the below as well in the same reverse proxy config file:
server {
listen 80;
server_name domainname.com;
return 301 https://$server_name$request_uri;
}