# Mutual TLS (mTLS)

Mutual TLS extends TLS so both client and server present certificates, giving strong service-to-service authentication and encryption. Learn how it works.

## Overview

Mutual TLS, or mTLS, is a way of using the Transport Layer Security protocol so that both ends of a connection prove their identity with certificates. In ordinary TLS, as used by every HTTPS website, only the server presents a certificate; the browser checks it and knows it is talking to the real site, but the server learns nothing cryptographic about the client. In mutual TLS the client also presents a certificate, and the server verifies it. The result is an encrypted connection in which each side knows exactly who is on the other end.

An everyday analogy is a secure building where both the visitor and the reception desk show identity. Normally you check that the building is genuine by its sign and its badge-wearing staff. In a high-security site, the guard also checks your staff card against a list issued by the same security office, and the door opens only if both checks succeed. Neither side relies on being "inside" the right street or floor; each proves who it is.

mTLS is a cornerstone of service-to-service security in [microservices](/tools/microservices) and of the [zero trust](/tools/zero-trust) idea that network location alone should never grant trust. Service meshes such as Istio and Linkerd can apply it automatically to every call inside a [Kubernetes](/tools/kubernetes) cluster. In AI platforms it protects traffic between gateways, model servers, vector databases and feature stores, and it is used by some APIs and identity providers to authenticate machine clients and bind tokens to them.

## What it is

mTLS combines TLS with public key infrastructure (PKI) on both sides.

| Element | Role |
|---|---|
| X.509 certificate | Binds a public key to an identity, such as a DNS name or a URI, signed by a certificate authority |
| Private key | Kept secret by each party; proves possession of the certificate |
| Certificate authority (CA) | Issues and signs certificates; its root certificate is the trust anchor |
| Trust store | The set of CA certificates a party accepts |
| Server certificate | Presented by the server, as in normal TLS |
| Client certificate | Presented by the client when the server requests it |
| Authorisation policy | Rules mapping a verified identity to allowed actions |
| Revocation and rotation | Mechanisms to withdraw and replace certificates |

In service environments, identities are often SPIFFE IDs, URIs like `spiffe://example.org/ns/payments/sa/api`, carried in the certificate's subject alternative name. SPIFFE and its reference implementation SPIRE are CNCF projects for issuing such workload identities.

## Where it came from

Client certificate authentication has been part of SSL and TLS since the 1990s; the TLS 1.0 specification, RFC 2246 in 1999, already defined a server's certificate request and the client's certificate response. For years it was used mainly in banking, government and business-to-business integrations, because issuing and managing client certificates for many people was hard.

Two changes brought it into the mainstream. First, TLS 1.3, published as RFC 8446 in August 2018, simplified and strengthened the handshake, including encrypting more of it, which hides client certificates from observers. Second, automation: service meshes, internal certificate authorities and tools such as cert-manager made it practical to issue short-lived certificates to every workload automatically. In OAuth, RFC 8705 (2020) standardised mTLS client authentication and certificate-bound access tokens.

## How it works

### 1. Provision identities

Each service receives a private key and a certificate signed by an internal CA. In a mesh, a sidecar or node agent requests these automatically at startup and renews them before expiry, often every few hours.

### 2. Start the handshake

The client connects and sends a ClientHello. The server replies with its certificate and, because it requires mutual authentication, a CertificateRequest message listing acceptable CAs.

### 3. Verify the server

The client checks that the server's certificate chains to a trusted CA, is within its validity period and matches the expected identity.

### 4. Present the client certificate

The client sends its certificate and a CertificateVerify message, a signature over the handshake with its private key. This proves it holds the key, not just a copy of the certificate.

### 5. Verify the client

The server checks the client's chain, validity and, where configured, revocation. If anything fails, the handshake aborts and no application data flows.

### 6. Authorise

The connection is now encrypted and both identities are known. The server applies policy: for example, only the `checkout` service may call `payments` on `/charge`. Authentication says who; authorisation decides what.

### 7. Rotate

Certificates expire and are replaced automatically. Short lifetimes reduce the damage from a stolen key and reduce reliance on revocation lists.

A quick manual test with curl:

```bash
curl --cert client.crt --key client.key --cacert internal-ca.crt https://scoring.internal:8443/health
```

## Key concepts and terms

| Term | Meaning |
|---|---|
| TLS | Transport Layer Security, the protocol for encrypted connections. |
| Mutual authentication | Both parties verify each other's identity. |
| PKI | Public key infrastructure: CAs, certificates and policies. |
| Root CA | The top-level trusted certificate authority. |
| Intermediate CA | A CA signed by the root that issues end certificates. |
| Subject alternative name | Certificate field listing identities such as DNS names or URIs. |
| SPIFFE ID | A URI-form workload identity for services. |
| Certificate rotation | Regular replacement of certificates before expiry. |
| Revocation | Declaring a certificate invalid before expiry (CRL, OCSP). |
| Service mesh | Infrastructure that handles service traffic, often with automatic mTLS. |
| Certificate-bound token | An OAuth token usable only with a specific client certificate. |
| TLS termination | Ending TLS at a proxy, after which traffic may be re-encrypted or not. |

## A worked example

This scenario is illustrative. A company runs 35 services in a Kubernetes cluster, including a model gateway, three model servers, a vector database and a customer data service. Internal traffic is plain HTTP, on the assumption that the cluster network is private. A penetration test shows that a compromised build agent in the same network can call the customer data service directly and download records.

The team installs a service mesh and enables mTLS in permissive mode first, which accepts both plain and mutual TLS, so they can see which services are not yet covered. Over two weeks, dashboards show plain-text traffic falling from 100% to 0%. They then switch to strict mode: connections without a valid client certificate are refused.

Each workload now has a certificate valid for 24 hours, renewed automatically. Authorisation policies allow only the model gateway to call the model servers, and only the retrieval service to call the vector database. The customer data service accepts calls from two named services. When the penetration test is repeated, the build agent's requests fail at the handshake because it has no certificate from the mesh CA. Latency overhead measured at p99 is about 1 to 2 ms per hop, which the team accepts.

## Strengths and limitations

**Strengths:**

- Strong, cryptographic identity for both ends of every connection.
- Encryption and integrity for data in transit.
- Removes reliance on network location for trust.
- Credentials can be short-lived and rotated automatically.
- Works for any protocol over TCP, including HTTP, [gRPC](/tools/grpc) and databases.
- Can bind OAuth tokens to clients so stolen tokens are useless alone.

**Limitations:**

- PKI operations are demanding: issuance, rotation, revocation and CA protection.
- Expired certificates cause sudden outages if rotation fails.
- TLS-terminating proxies and load balancers can break end-to-end identity.
- Identifies workloads, not end users; user identity still needs tokens.
- Debugging handshake failures is harder than debugging plain HTTP.
- Client certificates for people on personal devices remain awkward to manage.

## How it compares with alternatives

| Approach | What it does | When it fits better |
|---|---|---|
| One-way TLS plus tokens | Server certificate plus bearer token for the client | Public APIs and user-facing applications |
| API keys | Shared secrets in headers | Simple, low-risk integrations |
| [OAuth 2.0](/tools/oauth-2-0) client credentials | Token-based machine identity | Services calling external APIs across organisations |
| [JWT](/tools/jwt)-based service tokens | Signed workload tokens per request | Identity propagation through proxies that terminate TLS |
| Network segmentation and VPNs | Restrict who can reach which network | Coarse isolation; complements but does not replace mTLS |

## Practical guidance and best practices

1. Automate issuance and rotation; manual certificate handling does not scale and causes outages.
2. Use short certificate lifetimes, hours to days, for workloads.
3. Run a dedicated internal CA hierarchy and protect root keys offline or in hardware.
4. Encode service identity in a standard form, such as SPIFFE IDs, and authorise on it.
5. Roll out in permissive mode, measure coverage, then enforce strict mode.
6. Combine mTLS with authorisation policies; authentication alone is not access control.
7. Monitor certificate expiry and handshake failures with alerts.
8. Propagate end-user identity separately with tokens, since mTLS identifies workloads.
9. Prefer TLS 1.3 and disable old protocol versions.

## Common mistakes

- Turning on mTLS but allowing every authenticated service to call everything.
- Letting certificates expire because renewal was never automated or monitored.
- Trusting a public CA for internal client certificates, so any holder of a public certificate is accepted.
- Terminating TLS at a load balancer and forwarding plain traffic internally.
- Skipping hostname or identity checks and verifying only that a chain is valid.
- Storing private keys in container images or source repositories.

## Frequently asked questions

### What is the difference between TLS and mTLS?

In TLS only the server proves its identity. In mTLS the client also presents a certificate and proves it holds the private key, so both sides are authenticated.

### Does mTLS replace OAuth or JWTs?

No. mTLS identifies the calling workload at the connection level. Tokens carry user identity and fine-grained permissions. Many systems use both, and RFC 8705 binds OAuth tokens to client certificates.

### How much overhead does mTLS add?

The handshake costs extra round trips and CPU, but connections are reused, and TLS 1.3 reduced handshake cost. In most service meshes the per-request overhead is small; measure in your own environment.

### Do I need a service mesh for mTLS?

No. Applications or proxies can do mTLS directly. A mesh automates certificate distribution, rotation and policy for many services, which is why it is popular in Kubernetes.

### What happens if a private key is stolen?

The attacker can impersonate that workload until the certificate expires or is revoked. Short lifetimes and fast revocation limit the window.

### Is mTLS part of zero trust?

Yes. It is a common way to give every workload a verifiable identity and encrypt every connection, so trust does not depend on network location.

## Glossary

- mTLS: mutual Transport Layer Security.
- Certificate: a signed binding of a public key to an identity.
- CA: certificate authority.
- Handshake: the TLS negotiation that authenticates and agrees keys.
- Trust anchor: a root certificate that a party trusts.
- SPIFFE: a standard for workload identity.
- SPIRE: an implementation that issues SPIFFE identities.
- OCSP: Online Certificate Status Protocol for revocation checks.
- Permissive mode: accepting both plain and mutual TLS during rollout.

## Summary

Mutual TLS extends TLS so both client and server authenticate with certificates, giving every connection encryption and cryptographic identity on both ends. Client certificates have existed since early TLS, but TLS 1.3 and automated workload PKI made mTLS practical at scale, especially through service meshes and SPIFFE identities. It is a core building block of zero trust for service-to-service traffic. Success depends on automation, short-lived certificates, a well-protected CA, identity-based authorisation policies, monitoring of expiry and separate tokens for end-user identity.