How to Renew a Let’s Encrypt Certificate Automatically with Certbot

Overview

Let’s Encrypt certificates are designed to be renewed regularly rather than managed as permanent files. Certbot usually handles this through a scheduled systemd timer or cron job. The scheduled command runs certbot renew, which checks every certificate managed by Certbot and renews only those that are close enough to expiry according to Certbot’s renewal logic.

Renewal is separate from the first certificate request. The initial setup may have used a standalone server, an Nginx or Apache plugin, or a webroot challenge. Certbot stores the renewal configuration and reuses the relevant authentication method when the scheduled job runs. If your web server, DNS, domain routing, or firewall changes later, an otherwise correct renewal configuration can begin to fail.

Start by listing certificates managed by Certbot:

sudo certbot certificates

Review each certificate name, its covered domains, the expiry date, and the paths to the certificate and private key. Confirm that the names still match the domains your website serves. If you use subdomains or wildcard certificates, check the renewal method carefully; wildcard issuance generally requires DNS-based validation. Our guide to Let’s Encrypt certificates for subdomains explains the main certificate design choices.

Maintenance cycle

A reliable maintenance cycle has four parts: inspect, test, observe, and document.

1. Inspect the scheduled renewal job

On systems using systemd, look for Certbot timers:

systemctl list-timers --all | grep -i certbot

The exact timer name can vary by distribution and package source. If a timer is present, inspect its status and recent logs:

sudo systemctl status certbot.timer
sudo journalctl -u certbot.timer --since "30 days ago"

Some installations use a cron entry instead. Check the system and package-specific cron directories if no timer appears:

sudo grep -R "certbot renew" /etc/cron* 2>/dev/null

Do not create a second scheduler until you know what is already installed. Running multiple renewal jobs can make troubleshooting harder, particularly when different Certbot installations use different configuration directories.

2. Test without changing the live certificate

Use Certbot’s dry run to test the renewal process against the certificate authority’s staging environment:

sudo certbot renew --dry-run

A successful dry run shows that Certbot can usually complete the challenge and perform the renewal steps. It does not prove that every future renewal will succeed: DNS, routing, firewall rules, web server configuration, and credentials can change. Run the test after major infrastructure work and as part of a recurring maintenance schedule.

3. Confirm the web server reloads the new certificate

Renewing files on disk is not always enough. Nginx, Apache, or another TLS-terminating service may continue using the old certificate until it reloads its configuration. If your installation does not already include a deploy hook, create one appropriate to your server or use the service’s documented Certbot integration. Test the web server configuration before reloading it:

sudo nginx -t
sudo systemctl reload nginx

For Apache, the corresponding checks commonly look like:

sudo apachectl configtest
sudo systemctl reload apache2

Use the service name and commands provided by your operating system. A deploy hook should run only after a certificate has actually been renewed, not on every scheduled check.

4. Monitor expiry and renewal failures

Check the certificate presented to visitors from outside the server, not only the files stored locally. This catches problems such as a load balancer serving a different certificate, an IPv6 address pointing to an old host, or a web server that was never reloaded. Consider adding expiry monitoring and an alert route for failed renewal jobs. The Let’s Encrypt expiry monitoring guide covers practical monitoring options.

Signals that require updates

Several changes should trigger an immediate renewal review rather than waiting for the next routine check:

• DNS changes: New A or AAAA records, a move to a proxy, or a change in DNS hosting can send validation requests to the wrong server.
• Web server changes: Replacing Nginx or Apache, changing virtual hosts, or moving TLS termination to a load balancer can invalidate the old authentication or deployment method.
• Domain changes: Adding or removing names requires checking the certificate’s domain list and the renewal configuration.
• Firewall or networking changes: HTTP-based validation may require the relevant public service to be reachable, while DNS validation depends on authoritative DNS updates and credentials.
• Package or operating system changes: A Certbot package update, Python environment change, or migration between package managers can alter executable paths, timers, plugins, or configuration locations.
• CAA record changes: A restrictive CAA record can prevent an authorized certificate authority from issuing a certificate. See CAA records for Let’s Encrypt before changing these records.

After a migration, run a dry run and verify the live certificate from an external network. The website migration checklist can help you include SSL and DNS in the move rather than treating them as an afterthought.

Common issues

Port or routing failures

With HTTP-01 validation, the validation path must reach the server selected for the domain. Redirect rules, a reverse proxy, a closed port, or an incorrect IPv6 record can interfere. Check DNS resolution for every address family and confirm that the challenge path is not blocked by authentication or application routing.

DNS challenge failures

DNS-01 validation depends on a temporary TXT record being created in the correct zone. Common causes include using the wrong DNS provider credentials, delegating a subdomain differently than expected, or having stale and conflicting TXT records. Verify the authoritative nameservers and inspect the TXT record with a DNS query tool. Do not publish API credentials in shell history, source code, or public configuration files.

Renewal succeeds but visitors see the old certificate

This usually indicates that the service serving HTTPS has not reloaded, or that another endpoint is handling traffic. Inspect the active certificate from the public hostname and compare it with the renewed files listed by certbot certificates. Check load balancers, containers, CDNs, and both IPv4 and IPv6 paths.

Certbot reports a configuration or plugin error

Read the complete Certbot log rather than relying on the final summary line. List installed plugins and review the renewal file for the affected certificate. If you have changed the server layout, it may be safer to update the renewal method deliberately than to keep retrying an obsolete configuration. For error-message context, consult the Let’s Encrypt error codes guide.

HTTPS works, but pages show security warnings

A renewed certificate does not fix mixed content, incorrect redirects, or an incomplete deployment across all hostnames. If browser warnings appear after renewal, inspect page resources and redirect behavior. The guides to mixed content errors and safe HTTPS redirects provide focused next steps.

When to revisit

Review automatic renewal on a recurring schedule and whenever the server or DNS architecture changes. A practical minimum is to run sudo certbot renew --dry-run during scheduled maintenance, inspect recent timer or cron logs, and verify the publicly served certificate. Keep a record of the certificate names, validation method, deploy hook, DNS provider, and service reload command.

Revisit this procedure after an operating system upgrade, hosting migration, domain or DNS change, reverse-proxy deployment, firewall change, or certificate redesign. If a dry run fails, do not wait for the expiry date: preserve the full error output, identify whether the failure is in validation or deployment, and correct that layer first. Once fixed, repeat the dry run and confirm the live certificate from outside the server.

For teams maintaining several sites, standardize the renewal check and send failures to a monitored channel. For smaller deployments, a calendar reminder plus external expiry monitoring is usually enough to catch silent failures. Automatic renewal is valuable because it reduces routine work; verification is what makes the process dependable.