↓ Skip to main content
Le Site de François
  1. Index/

mTLS (Mutual TLS)

Security Cryptography Networking Tls Identity Zero-Trust Mtls

mTLS (Mutual TLS) is the configuration of TLS in which certificate-based authentication is required from both sides of the connection, not just the server. In standard TLS, only the server presents an X.509 certificate, which the client verifies to confirm it is talking to the intended host; the client is typically anonymous to the server, or authenticates separately via a password or session token at the application layer. In mTLS, the client also presents a certificate during the TLS handshake; the server verifies it against a trusted CA before completing the connection. The result is cryptographic proof of identity in both directions: the client knows it is talking to the legitimate server (as in standard TLS), and the server knows the exact identity of the connecting client — without any password, API key, or token exchanged in the application layer.

The mechanics of mTLS follow the TLS 1.3 handshake closely. After the server sends its certificate and Finished message, the server’s CertificateRequest message prompts the client to send its own certificate and a CertificateVerify proof-of-possession — a signature over the handshake transcript using the client’s private key, proving the client holds the key corresponding to the presented certificate. The server validates the client certificate chain against its configured client CA trust store (which may be entirely separate from the public internet CA trust store it uses for server certificates), verifies the proof-of-possession signature, and checks any extensions or policy constraints — such as requiring the client certificate’s SAN to match a specific SPIFFE ID pattern. If any check fails, the handshake is aborted before any application data is exchanged. Importantly, mTLS client authentication happens inside the encrypted channel (after the handshake derives session keys), so neither the client certificate nor the proof-of-possession is visible to a network observer.

mTLS is the standard mechanism for zero-trust service-to-service authentication in microservice architectures and is the primary transport-layer use of SPIFFE/SPIRE: every service receives a short-lived X.509-SVID from its SPIRE Agent, presents it as its client certificate in every outbound connection, and validates the SVID presented by the server against the SPIFFE trust bundle — without any pre-provisioned shared secret or API key. Istio and other service meshes implement mTLS transparently via sidecar proxies (Envoy), intercepting pod traffic and adding certificate-based mutual authentication without application code changes; in this model the application sees a plaintext local connection while the mesh handles mTLS on its behalf. In the CoCo stack, the connection from the Attestation Agent inside the TEE to the Trustee KBS uses a variant called attested TLS (aTLS): the server’s TLS certificate is embedded in or bound to the TEE’s attestation report, so the client simultaneously completes an mTLS handshake and verifies that the server is running in a genuine TDX or SEV-SNP enclave — combining transport security and remote attestation in a single protocol exchange. In the PQC transition, mTLS is affected on both the key exchange axis (ML-KEM for the session key, already deployable) and the certificate axis (ML-DSA signatures in client and server certificates), with the client certificate chain being a commonly overlooked migration target since organisations that migrate their public-facing TLS certificates often forget that their internal mTLS client certs carry the same HNDL-exposed classical signatures.

Related

PKI (Public Key Infrastructure)

Security Cryptography Certificates Identity Tls Pki
Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.

SPIFFE / SPIRE

Security Identity Workload Mtls Attestation Cncf Zero-Trust
SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF graduated specification that defines a standard for workload identity: a universal answer to the question “how does a service prove who it is to another service, without a human provisioning a secret?” The core primitives are simple. A SPIFFE ID is a URI of the form spiffe://trust-domain/path that unambiguously names a workload within a trust domain — for example spiffe://prod.example.com/payments/api. A SVID (SPIFFE Verifiable Identity Document) is a cryptographically signed document asserting that SPIFFE ID, in one of two forms: an X.509-SVID, which is a standard X.509 certificate with the SPIFFE ID encoded in the Subject Alternative Name field (used for mTLS), or a JWT-SVID, which is a short-lived JWT bearing the SPIFFE ID as the sub claim (used for service-to-service authentication where TLS termination is handled elsewhere). A trust bundle is the set of CA certificates for a trust domain that relying parties use to validate SVIDs — analogous to a root CA store, but scoped to a SPIFFE trust domain. The Workload API is the local gRPC API through which a workload retrieves its SVID and the trust bundles of domains it needs to communicate with, with automatic rotation before expiry.

TLS (Transport Layer Security)

Security Cryptography Networking Tls Pki Protocol
TLS (Transport Layer Security) is the protocol that establishes an encrypted, integrity-protected, and authenticated channel between two parties over an untrusted network. It is the successor to SSL (which is deprecated and broken) and the mechanism behind HTTPS, gRPC, LDAPS, SMTPS, database connections, and most other encrypted transport in modern infrastructure. The current version is TLS 1.3 (RFC 8446, 2018); TLS 1.2 remains in wide use but TLS 1.0 and 1.1 are deprecated by RFC 8996. The fundamental security properties TLS provides are: confidentiality (a passive observer cannot read the session content), integrity (an active attacker cannot modify session content without detection), and server authentication (the client can verify it is talking to the intended server rather than an impersonator). Client authentication is optional in standard TLS and is provided by mTLS.