---
title: mTLS and Mutual Authentication
url: https://doc.liz6.com/en/networking/05-tls-and-pki/04-mtls-and-mutual-authentication
locale: en
area: networking
tags:
- networking
- tls-and-pki
date: 2026-06-30
modified: 2026-07-16
description: 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.
---
# 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
## Private CA Management
The first step in deploying mTLS: establish a private CA.
```bash
# 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*