Certificates note

Certificate Renewal Notes

TLS certificates should be treated as a routine maintenance item. A working setup needs a valid domain, a reachable web server, a certificate client, automatic renewal and a simple verification procedure.

These examples use Certbot with Nginx. Commands that are identical are shown once. Separate Debian-based and RPM-based blocks are used only where package management differs.

Important: before requesting a certificate, confirm that the domain points to the correct server and that HTTP access on port 80 is reachable from the Internet.

1. Check DNS and web server reachability

Start by confirming that the domain resolves to the expected server address.

dig +short example.org A
dig +short www.example.org A

Check that Nginx is running and that the HTTP virtual host responds.

systemctl status nginx --no-pager -l
nginx -t
ss -tulpn | egrep ':80|:443|nginx'

curl -I http://example.org/
curl -I http://www.example.org/

2. Install Certbot and the Nginx plugin

Debian / Ubuntu

apt update
apt install -y certbot python3-certbot-nginx

RHEL / Rocky / AlmaLinux / Fedora

On many RHEL-compatible systems the Certbot packages are provided through EPEL.

dnf install -y epel-release
dnf install -y certbot python3-certbot-nginx

Verify that Certbot is available and that it can see the Nginx plugin.

certbot --version
certbot plugins

3. Request a certificate with automatic Nginx configuration

The Nginx plugin can request the certificate and update the matching server block. Replace the email address and domains with real values.

certbot --nginx \
  -d example.org \
  -d www.example.org \
  --redirect \
  --agree-tos \
  --email admin@example.org

After the command finishes, check HTTP to HTTPS redirection and the HTTPS response.

nginx -t
curl -I http://example.org/
curl -I https://example.org/
curl -I https://www.example.org/

4. Conservative alternative: request only, configure manually

If the web server configuration should not be changed automatically, request the certificate without installing it into Nginx.

certbot certonly --nginx \
  -d example.org \
  -d www.example.org \
  --agree-tos \
  --email admin@example.org

The certificate files are normally placed under:

/etc/letsencrypt/live/example.org/fullchain.pem
/etc/letsencrypt/live/example.org/privkey.pem

After manually editing the Nginx server block, always test and reload Nginx.

nginx -t
systemctl reload nginx

5. Check existing certificates

List certificates known to Certbot and review their names, paths and expiration dates.

certbot certificates

Check the certificate currently served by the website.

echo | openssl s_client -servername example.org -connect example.org:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

6. Verify automatic renewal

Certbot installations usually create a scheduled renewal job through systemd timer or cron. The exact mechanism depends on the operating system and packaging method.

systemctl list-timers | grep certbot || true
systemctl status certbot.timer --no-pager -l 2>/dev/null || true

ls -la /etc/cron.d/ 2>/dev/null | grep certbot || true
ls -la /etc/cron.daily/ 2>/dev/null | grep certbot || true

Run a simulated renewal test. This does not replace the live certificate.

certbot renew --dry-run

7. Manual renewal command

Manual renewal is rarely needed when the timer works, but it is useful during testing or after fixing a failed renewal issue.

certbot renew
nginx -t
systemctl reload nginx

8. Reload Nginx after successful renewal

If the packaging method does not already reload the web server, use a deploy hook. The deploy hook runs only after a certificate is successfully renewed.

certbot renew --deploy-hook "systemctl reload nginx"

A persistent deploy hook can also be stored as a script.

mkdir -p /etc/letsencrypt/renewal-hooks/deploy

cat > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh <<'EOF'
#!/bin/sh
systemctl reload nginx
EOF

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
certbot renew --dry-run

9. Firewall checklist

For HTTP validation and HTTPS service, the server normally needs ports 80 and 443 open.

Debian / Ubuntu with UFW

ufw allow 80/tcp comment 'http'
ufw allow 443/tcp comment 'https'
ufw status verbose

RHEL / Rocky / AlmaLinux / Fedora with firewalld

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

10. Troubleshooting checklist

  • Confirm that the domain points to the correct public server address.
  • Check that port 80 is reachable during HTTP validation.
  • Run nginx -t before and after Certbot changes.
  • Check Nginx access and error logs for the affected virtual host.
  • Review /var/log/letsencrypt/letsencrypt.log after a failed attempt.
  • Use certbot renew --dry-run after fixing the issue.

11. Final verification

certbot certificates
systemctl list-timers | grep certbot || true
nginx -t

curl -I http://example.org/
curl -I https://example.org/
curl -I https://www.example.org/

echo | openssl s_client -servername example.org -connect example.org:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

12. Certificate maintenance record

Date:
Domain names:
Certificate path:
Web server:
Validation method:
Renewal timer:
Dry-run result:
Reload hook:
Final HTTPS check:
Notes:

A good certificate note should be short but complete: domain names, certificate path, renewal method, timer status and the final verification result.

← Back to notes