Mutual TLS (mTLS)

The digital identity document used in mTLS. An X.509 certificate binds a public key to an entity's identity (a network function, service, or device) and is signed by a trusted Certificate Authority (CA). In mTLS, both client and server present valid X.509 certificates during the handshake. Key fields include the Subject Distinguished Name (DN) , Issuer, Validity Period, and Subject Alternative Name (SAN). Certificates are revoked via Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).

The framework of hardware, software, policies, and procedures required to create, manage, distribute, use, store, and revoke digital certificates. A PKI is the backbone of mTLS, providing the chain of trust. It includes Root CAs, Intermediate CAs, and Registration Authorities (RAs). For zero-touch provisioning, a robust, automated PKI is essential to issue and rotate certificates at scale without human intervention, often using protocols like ACME (Automated Certificate Management Environment) or EST (Enrollment over Secure Transport).

A dedicated infrastructure layer that handles service-to-service communication in a microservices architecture. A service mesh typically uses a sidecar proxy (like Envoy or Linkerd) deployed alongside each service. These proxies automatically enforce mTLS, encrypting all inter-service traffic and authenticating both ends without requiring application code changes. This is critical for zero-touch environments, as the mesh's control plane can automatically distribute certificates and rotate them, implementing Policy as Code for authentication and authorization.

The protocol sequence that establishes a mutually authenticated, encrypted session. The mTLS handshake extends the standard TLS 1.3 handshake:

• ClientHello: Client sends supported cipher suites and a random number.
• ServerHello & Certificate: Server responds with its chosen cipher suite, its X.509 certificate, and requests the client's certificate (CertificateRequest).
• Client Certificate & Verification: Client sends its own certificate and a CertificateVerify message—a digital signature over the handshake transcript, proving possession of the corresponding private key.
• Finished: Both parties verify the certificate chains against their trust stores and exchange encrypted finished messages.

The trusted entity that issues and signs digital certificates. In an mTLS architecture, the CA is the root of trust. For zero-touch network provisioning, a private, internal CA is typically used, often implemented as a highly available service (e.g., cert-manager in Kubernetes, HashiCorp Vault's PKI engine, or AWS Private CA). The CA's root certificate must be securely distributed to all network functions' trust stores. Automated CA operations include certificate issuance upon workload identity verification, renewal before expiry, and revocation upon compromise.

A CNCF-graduated open standard that provides a universal identity control plane for distributed systems. SPIFFE defines a SPIFFE Verifiable Identity Document (SVID) —a short-lived X.509 certificate that binds a workload to a SPIFFE ID (e.g., spiffe://example.com/ns/default/sa/my-service). The SPIRE project implements the SPIFFE standard, automatically issuing and rotating SVIDs. This is the gold standard for mTLS identity in cloud-native zero-touch environments, as it decouples identity from network location (IP address) and ties it to the workload itself.