Linkerd’s mTLS certificates are automatically rotated, meaning you don’t have to manually update them.
Let’s see this in action. Imagine you have a simple two-service application: webapp and api. Linkerd injects a proxy into each pod. By default, these proxies establish mTLS connections with each other, secured by certificates issued by Linkerd’s control plane.
Here’s a peek at what’s happening behind the scenes. The Linkerd control plane has a component called identity. This identity component acts as a Certificate Authority (CA). When a proxy starts up, it requests a certificate from identity. identity then issues a short-lived certificate to the proxy.
You can observe this in the logs of the linkerd-identity pod. You’ll see entries like:
INFO linkerd2_identity::server: Issuing certificate for <pod-name>.<namespace>.serviceaccount.identity.linkerd.cluster.local
And in the logs of a linkerd-proxy pod:
INFO linkerd2_proxy::identity: Certificate will expire in 23h59m59s
This short lifespan is the key. Instead of certificates lasting for months or years, Linkerd’s default is 24 hours. This means that even if a private key were compromised, the window of exposure is extremely small. The certificates are automatically renewed by the proxies before they expire, without any human intervention.
The problem this solves is the operational burden of certificate management. In traditional mTLS setups, you’re often faced with planning manual renewals, dealing with downtime if a renewal is missed, and the risk of human error. Linkerd’s automatic rotation eliminates this.
The core components involved are:
linkerd-identity(Control Plane): This is the CA. It signs certificate signing requests (CSRs) from the proxies and issues new certificates. It also manages the CA certificate that all proxies trust.linkerd-proxy(Data Plane): Each proxy running alongside your application pods is responsible for periodically requesting a renewal of its identity certificate fromlinkerd-identity.
The process looks like this:
- Proxy Startup: When a
linkerd-proxystarts, it generates a private key and a CSR. - CSR to Identity: The proxy sends this CSR to the
linkerd-identityservice. - Certificate Issuance:
linkerd-identity, acting as the CA, verifies the request (typically by checking the Service Account token) and issues a new, short-lived certificate signed by its CA private key. - Renewal Loop: The proxy continuously monitors its certificate’s expiration. As it approaches expiration (typically within an hour of expiry), it repeats steps 2 and 3 to obtain a fresh certificate.
You can configure the certificate rotation duration. While the default is 24 hours, you can adjust this using the --identity-issuer-interval flag on the linkerd-identity component in the control plane’s deployment. For example, to set it to 12 hours:
# In the linkerd-identity deployment spec
spec:
template:
spec:
containers:
- name: linkerd-identity
args:
- "linkerd-identity"
- "--identity-issuer-interval=12h"
# ... other args
This command tells the identity component to issue certificates that are valid for 12 hours, and consequently, proxies will request renewals more frequently. The linkerd-proxy will then automatically renew its certificate when it has, for instance, 1 hour of validity remaining.
The most surprising thing about Linkerd’s mTLS certificate rotation is that it’s entirely automatic and designed for resilience. Most systems treat certificate rotation as a critical, often manual, operational task that requires careful planning. Linkerd flips this by making the certificates inherently short-lived, shifting the burden from manual intervention to a robust, automated process. This design choice significantly reduces the risk of certificate expiration-related outages.
The next concept you’ll likely encounter is how to manage the root CA certificate itself, especially if you need to integrate Linkerd’s mTLS with external systems or custom CAs.