← Back to Table of Contents

Mutual TLS

In a normal TLS handshake, only the server proves its identity. The client is anonymous (from TLS’s perspective). The server doesn’t know who the client is until the application layer handles authentication (like a login form).

Mutual TLS (mTLS) changes this. Both sides present certificates and prove their identity during the handshake.

How mTLS Works

The server adds two extra messages to the handshake:

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: ClientHello
    S->>C: ServerHello
    S->>C: Certificate (server's cert)
    S->>C: ServerKeyExchange
    S->>C: CertificateRequest (please send your cert)
    S->>C: ServerHelloDone

    C->>C: Verify server certificate
    C->>S: Certificate (client's cert)
    C->>S: ClientKeyExchange
    C->>S: CertificateVerify (signature proving client has the private key)
    C->>S: ChangeCipherSpec
    C->>S: Finished

    S->>S: Verify client certificate
    S->>S: Verify CertificateVerify signature
    S->>C: ChangeCipherSpec
    S->>C: Finished

CertificateRequest: The server tells the client: “I need you to prove your identity too. Send me a certificate.” The server can specify which CAs it trusts for client certificates and which signature algorithms it accepts.

Client Certificate: The client sends its certificate, just like the server sends its certificate.

CertificateVerify: The client signs a hash of all handshake messages so far with its private key. This proves the client actually possesses the private key matching the certificate. Without this, someone could steal a client certificate (which is public) and impersonate the client.

Use Cases

Microservices: In a microservices architecture, services communicate with each other over the network. mTLS ensures that Service A can verify it’s talking to the real Service B, and vice versa. Service mesh tools like Istio and Linkerd automate mTLS between all services in a Kubernetes cluster.

API Authentication: Instead of API keys or tokens, clients authenticate with certificates. This is common in financial services and government systems.

Zero Trust Networks: In a zero trust model, every connection is authenticated, even within the internal network. mTLS is a key building block.

IoT Devices: Devices authenticate to the backend with client certificates, proving they’re legitimate devices.

Certificate Management Challenge

mTLS doubles the certificate management burden. You need certificates for servers and clients. Each client needs a key pair and a certificate signed by a CA the server trusts. For thousands of microservices or IoT devices, this requires automation.

Private CA tools and service mesh platforms like Istio and Linkerd handle this automatically. They issue short-lived client certificates, rotate them before expiration, and remove the need for manual certificate management. For certificate management details, see PKI From First Principles.


Next: TLS Extensions: SNI, Session Tickets, ALPN

← Previous ChapterNext Chapter →