Linkerd issues each proxy a certificate that expires after 24 hours and rotates it automatically. It does not rotate the identity issuer certificate or the trust anchor. Default installs generate self-signed versions valid for one year, so those two are the ones that can silently expire a year later and break mTLS across the mesh.
The three layers
Linkerd's documentation describes a chain of credentials.
| Credential | Lifetime | Rotated by |
|---|---|---|
| Workload certificate, one per proxy | 24 hours | Linkerd, automatically |
| Identity issuer certificate and key | One year in default installs | You |
| Trust anchor | One year in default installs | You |
The control plane contains a certificate authority called identity. It issues TLS certificates to each data plane proxy, each bound to the Kubernetes ServiceAccount identity of the pod. Proxies use them to encrypt and authenticate TCP traffic to other proxies.
The page says plainly that Linkerd automatically rotates workload certificates but cannot automatically rotate the identity issuer or the trust anchor.
Why the default is a trap
The out-of-the-box installation generates static self-signed certificates valid for one year and requires manual rotation to prevent expiry. The page calls that convenient for testing and not advisable or recommended for production. A cluster installed with defaults and then forgotten reaches the one year mark with no warning, unless you track it.
When the issuer certificate expires, the identity service cannot issue new workload certificates. Existing ones last up to 24 hours, so the failure then spreads as proxies fail to renew.
What to do
- Find out how your cluster was installed and when the issuer and trust anchor expire.
- Put both dates in a calendar and an alert, with at least 30 days of notice.
- For production, automate the issuer with cert-manager. The Linkerd guide uses cert-manager for this and describes it as automating issuer rotation and partly automating trust anchor rotation.
- Keep the trust anchor's private key out of the cluster where you can. The guide's simple example stores a self-signed anchor key in a Secret and notes that it would be more secure to keep it elsewhere.
- Rehearse a rotation in a staging cluster.
Anchor rotation needs overlap
Because every proxy trusts the anchor, replacing it needs a period where both old and new anchors are trusted, so workloads with certificates from either keep working. Follow the documented procedure instead of swapping in place. The documentation labels its instructions best effort community guidance and tells mission critical users to review production resources.
Compare with other approaches
Istio automates workload rotation through istiod and SDS, and has its own root and intermediate planning. See Istio PERMISSIVE and STRICT, and the general mTLS decision guide.
Monitoring
Track days until expiry for the issuer and anchor, and alert on proxy identity errors. A TLS probe or a certificate parser run against the Secret works. See checking expiry with openssl.
Where Safeguard fits
Safeguard does not rotate mesh certificates. It provides continuous monitoring of your dependencies, plus policies and gates on changes. The demo below shows the monitoring view.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a change after a clean scan raises a new finding, which is the habit you want for certificate dates too.
Quick check
How long do Linkerd workload certificates last?
24 hours, rotated automatically.
Does Linkerd rotate the trust anchor?
No. The documentation says it cannot automatically rotate the identity issuer certificate or the trust anchor.
What do default installs generate?
Static self-signed certificates with a validity of one year, which need manual rotation.
Sources
Last reviewed: 19 October 2026.
