Key Rotation

Key rotation means retiring a key and switching to a freshly generated one. For TLS servers it usually happens at certificate renewal: instead of reusing the old private key in a new CSR, you generate a new key pair. Certbot does this by default on every renewal unless you pass --reuse-key. Rotation also applies to CA keys, which are replaced by new roots and intermediates over time, and to session ticket keys, which servers should change frequently to preserve forward secrecy.

Why it matters

A key that is never changed accumulates exposure in backups, old servers and former staff laptops. Regular rotation bounds how long an undetected leak stays useful. As maximum certificate validity drops (200 days from 2026-03-15, 47 days from 2029-03-15), automated renewal makes per-renewal rotation nearly free. Rotation must be coordinated with anything that references the key directly, such as certificate pinning or DANE TLSA records of type 3 1 1: publish the new key's hash first, wait for caches to expire, then switch.

Example

# pre-generate the next key and publish its TLSA record before switching
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out next.key
openssl pkey -in next.key -pubout -outform DER | openssl sha256
# -> add "_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash>" next to the current record

Common misconceptions

• Renewing a certificate rotates the key. Only if a new key was generated; some tools and many manual workflows reuse the old one.
• Rotation is only needed after a breach. Scheduled rotation limits the damage of compromises you never detect.
• Rotating a key requires revoking the old certificate. Revocation is for compromise; after a routine rotation the old certificate can simply expire.