Feb 21, 2024: Announcing Linkerd 2.15 with support for VM workloads, native sidecars, and SPIFFE! Read more »

This is not the latest version of Linkerd!
This documentation is for Linkerd 1.x, an older version with some significant differences. You may want to see the Linkerd 2.x (current) documentation instead.


A common deployment model for Linkerd is to run it in linker-to-linker mode, meaning that Linkerd is on both the sending side and the receiving side of each network call. In this mode, Linkerd can seamlessly upgrade the connection to add TLS to all service-to-service calls. By handling TLS in Linkerd, rather than the application, it’s possible to encrypt communication across hosts without needing to modify application code.

To deploy Linkerd in linker-to-linker mode with TLS enabled, we must configure it to use Client TLS when sending requests, and Server TLS when receiving requests, both of which are covered below.

Client TLS

In order for Linkerd to send requests with TLS, it’s necessary to set the client TLS configuration parameter when configuring Linkerd.

Linkerd supports Static TLS, TLS with Bound Path and No Validation TLS through different configurations of the client TLS configuration parameter.

Server TLS

In order for Linkerd to receive requests with TLS, it’s necessary to set the server TLS configuration parameter when configuring Linkerd. Unlike client TLS, there is only one options for configuring server TLS, and it requires providing both the TLS certificate and key files that Linkerd uses to serve inbound TLS requests.

More information

If you’d like to learn more about setting up TLS in your environment, check out Buoyant’s Transparent TLS with Linkerd blog post on the topic, which provides a helpful walkthrough. If you’re running Linkerd as a service mesh in Kubernetes, setting up TLS is even easier; see the Encrypting all the things blog post in the service mesh series.