ArcLibrary

mTLS (Mutual TLS)

The server demands a client certificate too — the bedrock of service meshes and zero-trust networks.

mTLSZero TrustService Mesh
核心 · Key Idea

In one line: mTLS = mutual TLS — both sides verify each other's certificate. Replaces "IP allowlist + shared token" inside private networks with cryptographic service identity.

What it is#

Plain HTTPS: client validates the server's cert. mTLS: the client also presents a cert during handshake; the server validates it against an internal CA.

Plain TLS: client → verifies → server cert
mTLS:      client ⇄ mutually verify ⇄ server + client cert

Analogy#

打个比方 · Analogy

Plain HTTPS is like walking into a mall — seeing the mall's signage is enough. mTLS is like entering a corporate building — security checks your employee badge before letting you in, and you verify this is the real front entrance (not a phishing setup).

Key concepts#

Client certClient Certificate
Signed by an internal CA; identifies a service / machine / user.
Private CAInternal CA
Org-owned root cert; distributed to all services to sign short-lived leaf certs.
SPIFFE / SPIREIdentity framework
Cloud-native standard for automatic issuance, rotation, and binding to K8s ServiceAccounts.
Cert rotationCert Rotation
Short-lived certs (hours / days) auto-renewed; stolen certs die on their own.
Zero trustZero Trust
Trust no network position — every access is gated by identity + policy.

How it works#

A service mesh (Istio / Linkerd) makes this fully automatic via sidecars.

Practical notes#

  • Manual nginx mTLS:

    ssl_client_certificate /etc/nginx/ca.crt;
    ssl_verify_client on;
  • Auto mTLS in a service mesh: Istio / Linkerd enable mTLS between sidecars by default.

  • mTLS at the API gateway: common in finance / banking — mobile apps present client certs to prove "I'm the real app".

  • Cert lifecycle: cert-manager (K8s) / Vault PKI mint short-lived leaf certs automatically.

  • Revocation: CRL / OCSP are awkward in practice — short lifetimes + no renewal is the realistic revocation path.

Easy confusions#

API Token / JWT
Bearer at the application layer.
One leak = repeated reuse.
mTLS
Cert at the transport layer.
Every handshake verifies — **cryptographically bound** to a specific service instance.

Further reading#