Test Certbot renewal without replacing a working certificate

A currently valid HTTPS certificate does not prove that renewal will work. DNS, challenge routing or web-server changes may break the next attempt. This guide is for an administrator of an existing Debian or Ubuntu Nginx site already managed by Certbot. It is a renewal check, not a certificate migration or a reason to replace a working certificate.

Identify the installation and certificate

certbot --version
sudo certbot certificates
systemctl list-timers --all
sudo nginx -t

Use the Certbot command belonging to the installed package or snap. Mixing installation methods can leave multiple binaries and schedules. Record the certificate name exactly as listed, its domains and expiry date. Do not assume the certificate name is identical to the main hostname.

Confirm Nginx configuration passes before testing renewal. Save the relevant site configuration privately, including any manual challenge locations. Renewal files and DNS-plugin credentials can contain sensitive information, so do not attach them to a public ticket. Never remove the certificate directory to force a fresh attempt.

Understand the saved renewal method

Certbot may use Nginx, a webroot, DNS validation or another authenticator. A webroot challenge needs the correct public URL to reach the chosen directory. DNS validation needs an operational provider integration and suitably restricted credentials. Manual validation generally cannot renew unattended without the appropriate automation hooks.

Review any pre, post or deploy hooks before proceeding. A dry run uses a test certificate authority and does not save a replacement production certificate, but it can still run pre/post hooks and temporarily adjust web-server configuration. Deploy hooks have separate dry-run behaviour. Choose a maintenance window if a saved hook stops a service or performs other disruptive work.

Run a scoped renewal test

sudo certbot renew --cert-name example.com --dry-run

Replace example.com with the listed certificate name. Read the complete output and the local Certbot log. A failed challenge usually needs investigation of that challenge path, DNS record or credential. Repeated production issuance requests are not a substitute for diagnosis and can encounter certificate-authority limits.

Do not broaden firewall access, disable TLS verification or rewrite all virtual hosts to pass a test. If several domains share one certificate, every required authorization must be valid. Record which domain failed and whether the issue was name resolution, reachability, authorization or a plugin error.

Verify the real site and scheduler

After the test, repeat sudo nginx -t and load the public HTTPS site. Inspect the certificate served to clients, including its hostname and expiry, rather than looking only at files on disk. Check the appropriate timer or cron schedule for your installation method and review its last run.

If configuration changed unexpectedly, restore the saved site configuration, test it and reload only after syntax validation succeeds. Keep the current valid certificate in place while fixing renewal. Successful dry-run output is useful evidence, but monitoring actual expiry and scheduled-run failures remains necessary.

Configure a domain and HTTPS. Investigate systemd services.

Reference: Official documentation. Check the documentation installed on your own operating-system release when an option differs.