mTLS (Mutual TLS)

Mutual TLS extends standard TLS by requiring clients to present certificates, ensuring both parties in a connection can cryptographically verify each other's identity.

Why it matters

• Eliminates reliance on passwords or API keys for service-to-service authentication.
• Provides strong identity assurance in zero-trust architectures.
• Enables fine-grained access control based on certificate attributes.
• Required for high-security environments like financial services and healthcare.

Key concepts

• Client Certificate: X.509 certificate presented by the client to prove identity.
• Certificate Authority (CA): Issues and signs certificates for both clients and servers.
• Certificate Chain: Hierarchy of trust from root CA through intermediate CAs to end certificates.
• Certificate Revocation: Mechanism to invalidate compromised certificates (CRL or OCSP).
• Subject Alternative Name (SAN): Certificate field listing valid identities (DNS names, IPs, URIs).

Implementation patterns

• Service mesh (Istio, Linkerd): Automatic mTLS between microservices with sidecar proxies.
• API gateway: Terminate mTLS at the edge and extract client identity for downstream services.
• Direct mTLS: Applications handle certificate validation without intermediary proxies.
• Certificate-bound tokens: Combine mTLS with OAuth tokens for layered security.

Operational considerations

• Plan certificate lifecycle management including rotation and renewal automation.
• Implement monitoring for certificate expiration and failed handshakes.
• Use short-lived certificates where possible to limit exposure from compromise.
• Consider hardware security modules (HSMs) for protecting CA private keys.
• Test certificate revocation workflows before they're needed in production.