Hackerparagraph,IT-Security, Linux Image © DALL-EHackerparagraph,IT-Security, Linux (Image © DALL-E)

Certbot Installation Guide

The installation process for Certbot depends on the operating system and the web server being used.

Ubuntu and Debian Systems

On Debian-based systems, the core tool is installed using the package manager:

apt update
apt install certbot

Plugins are required to enable direct integration with certain web servers.

For Apache:

apt install python3-certbot-apache

For Nginx:

apt install python3-certbot-nginx

CentOS and AlmaLinux Systems

On RHEL-based distributions, the dnf package manager is used to install both the agent and the Nginx plugin:

dnf install certbot python3-certbot-nginx

Deployment Methods and Certificate Issuance

Certbot offers various operating modes depending on the server environment and the desired level of automation.

Automated Integration for Apache and Nginx

The most straightforward method is to use the web server plugins. These plugins verify domain ownership, obtain the certificate, and automatically adjust the server configuration to enable HTTPS.

Apache Automation:

certbot --apache -d example.com -d www.example.com

Nginx automation:

certbot --nginx -d example.com -d www.example.com

For administrators who prefer to manage their server configuration files manually, the certonly flag can be used. This retrieves the certificate without changing the existing configuration:

Apache instructions:

certbot certonly --apache -d www.example.com

Nginx Instructions:

certbot certonly --nginx -d www.example.com

Standalone and Webroot Mode

In environments where no web server is currently running, use standalone mode. With this method, port 80 must be open and available, as Certbot starts a temporary web server to process the challenge:

certbot certonly --standalone -d example.com

Webroot mode is used for complex setups or shared hosting environments. With this method, a challenge file is placed in a specific directory on the server:

certbot certonly --webroot -w /var/www/html -d example.com

If you use webroot mode with Nginx, the following configuration block is required so that the certificate authority can access the challenge files:

location /.well-known/acme-challenge/ {
    root /var/www/certbot;
}

Certificate Management and File Structure

Administrators can check the status and expiration dates of all managed certificates using the following command:

certbot certificates

Once successfully issued, the certificates are stored in /etc/letsencrypt/live/example.com/. This directory contains four important files:

  • 1. cert.pem: The server certificate.
  • 2. chain.pem: The intermediate certificate.
  • 3. fullchain.pem: A combination of the server and intermediate certificates.
  • 4. privkey.pem: The private key associated with the certificate.

Manual Server Configuration

If the certificates were obtained using the certonly method, the server blocks must be updated manually.

Example of an Nginx configuration:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;        
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Example of an Apache configuration:

<virtualhost>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</virtualhost>

Automatic Renewal Mechanisms

Let’s Encrypt certificates are valid for 90 days. To avoid service interruptions, Certbot implements automatic renewal.

Verification and Testing

You can check the status of the renewal timer using systemd:

systemctl status certbot.timer

To simulate a renewal and ensure there are no configuration errors, use the dry-run command:

certbot renew --dry-run

Scheduling via Cron

On systems without systemd, a Cron job is required to trigger the renewal process. Adding the following line to the crontab (crontab -e) ensures that the process runs daily at 3:00 a.m.:

0 3 * * * certbot renew --quiet

Implementing Renewal Hooks

Since web servers load certificates into memory, a reload is required after a certificate update. This can be managed using hooks.

  • Configuration file: Add post_hook = systemctl reload nginx under [renewalparams] in /etc/letsencrypt/renewal/example.com.conf.
  • Command-line hook: certbot renew --post-hook “systemctl reload nginx”
  • Deploy hook: To run a command only when a certificate is actually renewed: certbot renew --deploy-hook “systemctl reload nginx”

Advanced Implementation: Wildcard Certificates

Wildcard certificates (e.g., *.example.com) require a DNS-01 challenge instead of an HTTP-01 challenge, since the certificate authority must verify control over the entire DNS zone.

Manual DNS Challenge

certbot certonly --manual --preferred-challenges dns -d “*.example.com” -d example.com

To do this, the administrator must manually create a TXT record in the domain provider’s DNS settings.

Automated DNS via Cloudflare

DNS plugins are used for automation. For Cloudflare, the plugin is installed as follows:

apt install python3-certbot-dns-cloudflare

A configuration file must be created at /etc/letsencrypt/cloudflare.ini containing the following:

dns_cloudflare_api_token = YOUR_TOKEN_HERE
chmod 600 /etc/letsencrypt/cloudflare.ini

The certificate is then requested using the following command:

 certbot certonly \
 --dns-cloudflare \
 --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
 -d “*.example.com” -d example.com

Troubleshooting and Best Practices

Troubleshooting Common Errors

Challenge Failed

This usually indicates that the DNS records do not point to the correct server, port 80 is blocked by a firewall, or the web server configuration prevents access to the .well-known directory. You can run a diagnostic check using the following commands:

dig example.com +short    curl -I http://www.example.com/.well-known/acme-challenge/test

Rate limit exceeded

Let’s Encrypt limits the number of certificates issued per domain. For testing purposes, use the staging environment:

certbot --nginx --staging -d www.example.com

Unauthorized

This is usually due to delays in DNS propagation or incorrect server routing.

Security Optimization

To ensure a secure HTTPS implementation, the following configurations are recommended:

1. Redirecting from HTTP to HTTPS:

server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

2. HSTS Implementation

To force browsers to use HTTPS, add the following header:

 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

3. Certificate Monitoring

External monitoring of certificate expiration can be performed using OpenSSL:

 echo | openssl s_client -servername www.example.com -connect www.example.com:443 2&gt;/dev/null | openssl x509 -noout -dates

Comparison of Certbot Commands

New Certificate (Nginx)

certbot --nginx -d www.domain.com

Certificate Only (Nginx)

certbot certonly --nginx -d www.domain.com

List certificates

certbot certificates

Test renewal

certbot renew --dry-run

Perform renewal

certbot renew

Delete certificate

certbot delete --cert-name www.domain.com