mTLS and Mutual Authentication

Server identity is proven via TLS certificates, while client identity is proven via mTLS—both parties present and verify certificates. In zero-trust architectures, mTLS serves as the identity foundation for service-to-service communication, but the operational cost of certificate distribution and rotation is its main bottleneck.

Overview

Standard TLS only verifies the server's identity. mTLS (mutual TLS) adds client certificate verification: the server sends a CertificateRequest during the handshake, and the client must provide a certificate. This achieves the cornerstone of a "zero-trust" network—both sides mutually prove their identities without relying on IP addresses or network location. SPIFFE standardizes service identity, and Istio/Linkerd use mTLS to automatically encrypt communications for every pod in a service mesh. Running a private CA is a prerequisite for mTLS—you need full control over certificate issuance and revocation.

TLS vs mTLS: Handshake Differences

TLS Server presents certificate Client verifies Server → One-way trust

mTLS Server cert + CertificateRequest Client must also present cert → Mutual verification

TLS 1.3 mTLS Simplified Handshake

Client → Server: ClientHello + key_share Server → Client: ServerHello + key_share + {EncryptedExtensions + CertificateRequest + ...} Client → Server: {Certificate + CertificateVerify + Finished}

↑ Extra compared to standard TLS 1.3: Certificate + CertificateVerify (provided by client)

CertificateRequest carries: certificate_authorities (empty = any CA) signature_algorithms · certificate_extensions (e.g., SPIFFE OID)

Private CA Management

The first step in deploying mTLS: establish a private CA.

# 1. Create Root CA (offline, hardware security module or air-gapped machine):
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ca.key
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/CN=Private CA" -extensions v3_ca

# 2. Issue server/client certificates:
openssl genpkey -algorithm EC -out server.key
openssl req -new -key server.key -out server.csr \
  -subj "/CN=metrics-agent-001"
openssl x509 -req -days 90 -in server.csr -CA ca.crt -CAkey ca.key \
  -out server.crt -set_serial 0x01

# 3. Revoke (if a certificate is compromised):
openssl ca -revoke server.crt -keyfile ca.key -cert ca.crt

SPIFFE

A standardized service identity framework that carries SPIFFE IDs in the CN/SAN fields of mTLS certificates:

SPIFFE ID: spiffe://trust-domain/path
  trust-domain: Organization/cluster identifier
  path: Service/instance identifier

Example: spiffe://liz6.com/metrics-agent/li-cn-node-2

In X.509 certificates:
  SAN URI: spiffe://liz6.com/metrics-agent/li-cn-node-2
  → Can be verified via URI SAN (not just CN)

SVID (SPIFFE Verifiable Identity Document):
  = X.509 cert (short-lived: default 1 hour) + private key
  → Automatically rotated by SPIRE agent

Service Mesh (Istio/Linkerd)

Comparison

	mTLS	API Key	JWT (OAuth2)
Transport Layer	L4 (TLS handshake phase)	L7 (HTTP header)	L7 (HTTP header)
Identity Binding	Certificate (CN/SAN + expiry)	Key string	Claims (sub, exp, aud)
Rotation	CA re-issues	Generate new key	Short TTL + refresh
Revocation	CRL / OCSP	Revoke in DB	Short TTL (natural expiry)
Middleware Overhead	Low (TLS itself)	Medium (verify key)	Medium (verify JWT)
Zero-Trust Compatible	✓ (SPIFFE)	✗	△ (Requires PKI for token signing)

References

RFC: 8446, 8705
SPIFFE: spiffe.io, github.com/spiffe/spire
Istio: istio.io/latest/docs/concepts/security/#mutual-tls-authentication

Keywords: mTLS, client certificate, SPIFFE, SPIRE, service mesh, private CA, certificate revocation, SVID