Generate a new private key at each renewal unless you have a specific reason to keep one. A fresh key limits how long a stolen key stays useful. Reuse is reasonable when something pins your public key, and then you need a planned backup key too. Certbot does not reuse keys by default.
Renewal versus rotation
Renewing a certificate gets a new certificate with a new validity period. Rotating a key replaces the key pair. A renewal can do either. With Certbot, the reuse-key option makes renewal keep the existing private key, and the no-reuse-key option, which is the default, makes a new key for every renewal.
Why a new key each time
- Smaller blast radius. If a key leaked quietly, replacing it at each renewal ends the exposure at the next renewal at the latest. Short certificate lifetimes make that window shorter still. See certificate lifetimes of 200, 100 and 47 days.
- Less to protect over time. One key living for years is one long term target.
- Free with automation. Once renewal is scripted, a new key costs nothing.
Why some teams reuse
- Public key pinning. If a mobile app or client pins your certificate's public key, a new key at renewal breaks the pin unless a backup pin covers it. RFC 7469 describes the standard fix: keep a backup key pair offline and pin its fingerprint in advance. See pinning and Android expiry.
- Key stored in hardware. If the key lives in an HSM and generation is slow or controlled, reuse can fit your process.
- Key hashes published elsewhere, such as in client configuration, that you cannot update instantly.
If you reuse, treat it as a decision with an owner and a review date, not a default you forgot.
How to set it
# renew with a new key (default)
certbot renew
# keep the existing key
certbot renew --reuse-key
A short policy you can adopt
Write this down so the choice is not left to whoever set up the server years ago.
- Default to new keys at every renewal.
- If you pin, use a backup key pair stored offline, and rotate the pin set on a schedule.
- Store private keys with tight file permissions and never in the repository.
- If you ever suspect a leak, rotate immediately. The steps are in what to do when a TLS private key leaks.
Checking your estate
List every certificate you run, the key type, the age of its key and who owns it. Keys older than their certificate history, or shared across several hosts, are the first to review. A short inventory turns the policy above into something you can audit.
Where Safeguard fits
Safeguard's dependency scanning helps catch outdated crypto libraries early, and policies and gates can stop risky changes before merge. Run the free scan at gold.safeguard.sh/scan.
Quick check
Does Certbot reuse my private key at renewal by default?
No. Not reusing keys is the default behavior.
If I pin my public key, must I reuse it forever?
No. Pin a backup key as well, so you can switch to it without breaking clients.
Sources
Last reviewed: 19 October 2026.
