Should I upgrade to cert-manager 1.18 Default Private Key Rotation and 45-Day Certificate Readiness now?
Platform teams running cert-manager need to decide whether to upgrade now and accept the new key-rotation behavior, or pin older behavior while preparing clusters for shorter certificate lifetimes.
Blockers
- breaking_change_in: capability/private-key-rotation → package/cert-manager-1.18
- Support is added in cert-manager 1.18
- Temporary escape hatch documented for the 1.18 cycle
- 1.19 removes the ability to turn off the new default
Who this is for
- low-ops
- enterprise
- compliance
Candidates
Upgrade to cert-manager 1.18 and standardize on private key rotation
As of 2026-04-01, cert-manager 1.18 changes the default `Certificate.spec.privateKey.rotationPolicy` from `Never` to `Always`, and the project documents this as a breaking change. cert-manager 1.18 also sets the default `revisionHistoryLimit` to `1`, so stale `CertificateRequest` revisions are garbage collected after upgrade unless explicitly retained. The same release adds ACME certificate profile support, and cert-manager's release notes call out Let's Encrypt support for the `tlsserver` and `shortlived` profiles. On the Let's Encrypt side, 45-day certificates have not started for general users as of 2026-04-01, but the official timeline says the opt-in `tlsserver` profile switches to 45-day certificates on 2026-05-13, while the default classic profile stays longer-lived until 2027.
When to choose
Use this when you want the security benefit of rotating both certificate and key on each issuance and you can validate that workloads reload mounted TLS secrets correctly. It is the better fit for teams that want to use cert-manager 1.18 as the staging point for upcoming shorter-lifetime certificate operations instead of preserving legacy behavior.
Tradeoffs
Pros: aligns with cert-manager's new default, reduces exposure from reused private keys, and gets ACME profile support needed for early shorter-lifetime testing. Cons: applications that do not reload `tls.key` and `tls.crt` on secret change can continue serving old material until restarted, and the `revisionHistoryLimit` default change may remove old `CertificateRequest` history you previously relied on.
Cautions
The cert-manager docs say `rotationPolicy: Always` waits until the new certificate is signed before overwriting `tls.key`, but zero-downtime still depends on the application reloading secrets. The docs also note that deleting the Secret is not the recommended manual rotation path; use `cmctl renew` instead. If you depend on old `CertificateRequest` objects for auditing or debugging, set `revisionHistoryLimit` explicitly before rollout.
Upgrade to cert-manager 1.18 but pin legacy key reuse while you remediate reload paths
As of 2026-04-01, cert-manager 1.18 officially supports preserving the old behavior by explicitly setting `rotationPolicy: Never` on `Certificate` resources. The 1.18 release notes also document a temporary feature gate, `DefaultPrivateKeyRotationPolicyAlways: false`, that can disable the new default during the 1.18 cycle. However, the same notes state this escape hatch is only temporary and will no longer be available once 1.19 makes the change GA. This path lets teams take the 1.18 upgrade and ACME profile support now, while delaying disruptive key-rotation behavior until application reload and restart handling is fixed.
When to choose
Use this when cluster operators need the rest of the 1.18 release but know some ingress controllers, sidecars, or applications still assume the private key file stays stable across renewal. It is the safer near-term option when your immediate blocker is workload reload behavior, not certificate issuance itself.
Tradeoffs
Pros: lowers upgrade risk and preserves current runtime behavior while you prepare for 45-day certificate operations and future key rotation. Cons: keeps reusing existing private keys, which cert-manager explicitly describes as the older, less intuitive behavior, and creates a follow-up migration because the feature-gate fallback is not meant to survive past 1.18.
Cautions
Do not treat the feature gate as a long-term steady state; cert-manager's 1.18 release notes say 1.19 removes the ability to turn it off. If you pin `rotationPolicy: Never`, make that explicit in manifests so behavior does not silently change later. This option also does not avoid the `revisionHistoryLimit` default change in 1.18, so plan for `CertificateRequest` cleanup separately.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to cert-manager 1.18 Default Private Key Rotation and 45-Day Certificate Readiness now?"