How to test Certbot certificate renewal

A Certbot host can have valid certificates and still fail the next renewal because DNS records, webroot paths, web server plugins, firewall rules, or hook scripts changed after issuance. Run a dry-run renewal before expiry when validation paths or automation changed so the failure appears while there is still time to repair it.

certbot renew --dry-run reuses saved renewal settings and runs the renewal flow against the ACME staging service. The command obtains temporary test certificates but does not save them to disk, so it checks the renewal path without replacing the live certificate files under /etc/letsencrypt/live/.

Run the test on the server that owns the renewal configuration under /etc/letsencrypt/. A clean dry run proves that Certbot can load the lineage, reach the selected authenticator, complete ACME validation against staging, and finish any default renewal hooks, while scheduler checks such as systemd timers remain a separate proof.

Steps to test Certbot certificate renewal:

Open a terminal on the server that stores the Certbot certificates.

List the saved certificate lineages.

$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
  Certificate Name: www.example.com
    Domains: www.example.com example.com
    Expiry Date: 2026-07-25 06:50:00+00:00 (VALID: 42 days)
    Certificate Path: /etc/letsencrypt/live/www.example.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.example.com/privkey.pem

Use the value after Certificate Name with --cert-name when only one lineage needs a renewal test. If Certbot reports no certificates, run the test on the host where the certificate was originally issued or create the certificate before testing renewal.

Run a dry-run renewal for all saved lineages.
```
$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/www.example.com.conf

Simulating renewal of an existing certificate for www.example.com and example.com

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/www.example.com/fullchain.pem (success)
```
To test one lineage, run sudo certbot renew --cert-name www.example.com --dry-run instead. The dry run can temporarily adjust and reload web server configuration when installer plugins are involved.

If the output shows authorization, webroot, DNS, plugin, account, or hook errors, treat the scheduled renewal as blocked until the failing signal is fixed and the dry run succeeds.
Include deploy hooks only when the deployment handoff is part of the renewal test.
```
$ sudo certbot renew --cert-name www.example.com --dry-run --run-deploy-hooks
```
Pre and post hooks run during a dry-run renewal when a renewal attempt happens. Deploy hooks do not run unless --run-deploy-hooks is included, and they operate against the current active certificate rather than a temporary staging certificate.

Confirm the live certificate entry is still present after the dry run.

$ sudo certbot certificates --cert-name www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
  Certificate Name: www.example.com
    Domains: www.example.com example.com
    Expiry Date: 2026-07-25 06:50:00+00:00 (VALID: 42 days)
    Certificate Path: /etc/letsencrypt/live/www.example.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.example.com/privkey.pem

The dry run is complete when every tested lineage ends with (success) and the saved certificate entry remains the production lineage, not a staging certificate.

Check the automated renewal trigger after the dry run succeeds.

A manual dry run proves that renewal can complete now. The timer or cron check proves whether the host will run certbot renew later without manual input.

Related: How to check the Certbot renewal timer