What is Mutual TLS (mTLS)?

Updated: March 2026

What is mutual TLS authentication (mTLS)?

Mutual Transport Layer Security (mTLS) enhances the security of the TLS protocol by implementing two-way authentication and encryption. Unlike traditional SSL/TLS, which only requires the server to authenticate itself to the client, mTLS mandates that both client and server authenticate each other using digital certificates. 

This heightened level of verification and creation of a TLS connection is crucial for secure machine-to-machine communication, safeguarding against unauthorized access and ensuring that sensitive data is transmitted over secure channels. mTLS is often used to secure connections between IoT devices or other endpoints that are transmitting data across the public internet.

In this article, learn what mTLS authentication is, how the protocol works, what certificates are involved, and how mTLS is deployed.

What is mTLS authentication?

mTLS authentication is the process where both endpoints in a TLS connection verify each other's identity using cryptography. It answers one question at each end of the connection: is this peer who it claims to be?

This verification relies on three properties of X.509 public key infrastructure (PKI). PKI is the system of certificates, keys, and certificate authorities that makes encrypted communication possible.

• Chain of trust — Each certificate is signed by a Certificate Authority (CA) that both parties trust. A CA is an organization or system that vouches for the identity of certificate holders. Verification walks the certificate chain from the leaf certificate (the one presented by the peer) up to the root CA, confirming every signature along the way.
• Proof of possession — The CertificateVerify message proves the presenter holds the private key that matches the public key in the certificate. The private key is a secret value that only the certificate holder should have. Without it, an attacker cannot forge this proof, even if they intercept the certificate itself.
• Temporal validity — Certificates carry notBefore and notAfter fields that define when the certificate is valid. Expired or not-yet-valid certificates are rejected during validation.

How does the mTLS handshake work?

An mTLS connection follows the same handshake sequence as TLS 1.2 or TLS 1.3, with one addition: the server asks the client to prove its identity too. The handshake is the series of messages exchanged at the start of a connection to negotiate encryption and verify identities.

The handshake works like this:

1. ClientHello — The client initiates the connection. It sends its supported cipher suites (encryption algorithms) and TLS version to the server.
2. ServerHello + Server Certificate — The server responds with its chosen cipher suite. It also presents its X.509 certificate, which has been signed by a trusted CA.
3. CertificateRequest — The server sends a CertificateRequest message, telling the client that it must also authenticate. This message includes a list of CAs that the server will accept.
4. Client Certificate + CertificateVerify — The client presents its own X.509 certificate. It then proves it holds the corresponding private key by signing a hash of the handshake transcript. This signed proof is the CertificateVerify message.
5. Validation — Each side validates the other's certificate chain against its trust store. A trust store is the set of CA certificates that an endpoint trusts. Both sides also check certificate expiration and optionally check revocation status via CRL or OCSP.
6. Finished — Both sides derive session keys from the handshake and begin encrypted application data exchange.

In TLS 1.3, the handshake completes in a single round trip (1-RTT). The client's certificate and CertificateVerify are sent encrypted, which protects client identity from passive observers. In TLS 1.2, client certificates are sent in the clear.

If the client fails to present a valid certificate or the CertificateVerify signature doesn't match, the server terminates the connection before any data is exchanged. This is the key difference from standard TLS, where the client is not required to present a certificate at all.

What is an mTLS certificate?

An mTLS certificate is a standard X.509 certificate configured for use in mutual authentication. There is no special certificate format unique to mTLS. The difference is that in an mTLS deployment, both the client and the server hold certificates, rather than only the server.

In standard TLS, only the server has a certificate. The client verifies the server's identity but remains anonymous. In mTLS, the client also has its own certificate. The server verifies the client's identity during the handshake, just as the client verifies the server's. Both certificates are standard X.509 certificates. The only difference is how they are configured and which Extended Key Usage (EKU) values they carry.

In environments that use SPIFFE (Secure Production Identity Framework for Everyone), mTLS certificates take the form of X.509-SVIDs. These are short-lived certificates where the SAN encodes a SPIFFE ID like spiffe://trust-domain/workload-path. This provides a standardized, platform-agnostic identity for workloads.

What does an mTLS certificate include?

An mTLS certificate includes the same fields as any X.509 certificate. The fields that matter most for mTLS are:

• Subject / Subject Alternative Names (SANs) — The identity of the certificate holder. This can be a DNS name, IP address, SPIFFE ID, or URI. SANs are the primary identity field used in modern certificate validation. The older Common Name (CN) field is deprecated for this purpose.
• Issuer — The CA that signed the certificate.
• Public key — The holder's public key. The peer uses this to verify signatures and establish session keys.
• Key Usage / Extended Key Usage (EKU) — Constraints on how the certificate may be used. Server certificates carry serverAuth. Client certificates carry clientAuth. A certificate used by a service that acts as both client and server may carry both. The EKU field is what distinguishes a server certificate from a client certificate in an mTLS deployment.
• Validity period — The notBefore and notAfter timestamps. These define when the certificate is valid. Short-lived certificates (valid for minutes to hours) reduce the exposure window if a private key is compromised. They also eliminate the need for revocation infrastructure because they expire on their own.

Example of an mTLS client certificate

The following is a simplified view of what an mTLS client certificate looks like when decoded. You can produce this output by running openssl x509 -in client.crt -text -noout.

A few things to notice in this example:

• The Issuer is My Internal CA. This is the private CA that signed the certificate. The server must trust this CA for the mTLS handshake to succeed.
• The Validity window is 90 days. In many production environments this would be much shorter, often hours, to limit exposure if the private key is compromised.
• The Subject Alternative Name carries a SPIFFE ID (spiffe://example.com/ns/production/sa/service-a). This is the identity the server will use to identify the client. The older Common Name field (CN = client-service-a) is present for compatibility but is not used for validation by modern TLS implementations.
• The Extended Key Usage is set to TLS Web Client Authentication (clientAuth). This tells the server that this certificate is intended for use as a client certificate. A server certificate would show TLS Web Server Authentication (serverAuth) instead.

Is mTLS authentication or authorization?

mTLS is authentication only, as it only verifies identity by validating the certificate chain and proof of possession. mTLS does not provide authorization; a valid certificate proves identity but does not define what the holder is allowed to access. Learn more about the differences between authentication and authorization in this article.

In real implementations, mTLS and authorization work together. After mTLS authenticates a connection, the receiving service extracts identity information from the client certificate. The service then passes this identity to an authorization layer, such as role-based access control (RBAC) policies, OPA rules, service mesh authorization policies, or application-level access control logic, which then decides whether to permit the request.

A known anti-pattern is treating a successful mTLS handshake as implicit authorization. If a service accepts any valid certificate without checking whether that specific identity is permitted to access the requested resource, it has authentication but no access control.

What is the difference between TLS and mTLS?

Standard TLS is used for public-facing web applications. In these environments, authenticating every client with a certificate is impractical. Browsers handle server certificate validation natively, but provisioning client certificates at scale across end-user devices introduces UX and operational complexity.

mTLS is used for internal service-to-service communication, microservices, API integrations, CI/CD pipelines, and other machine-to-machine workloads. In these environments, both endpoints are controlled infrastructure and can be provisioned with certificates. 

mTLS also provides mutual identity verification without requiring shared secrets, API keys, or static tokens. Certificates can be issued with short validity periods and rotated automatically, which reduces the risk of credential compromise.

The table below summarizes the differences between standard TLS and mTLS.

How is mTLS implemented?

Certificate generation

mTLS deployment starts with the creation of a private Certificate Authority, which issues certificates to both servers and clients. Common tools for this include OpenSSL, cfssl, step-ca, or Teleport.

Each certificate is constrained via the Extended Key Usage (EKU) extension. Server certificates get serverAuth and client certificates get clientAuth, and identity is encoded in the Subject Alternative Name (SAN) field rather than the legacy Common Name.

Server configuration

With certificates in hand, the next step is configuring the server to require and verify client certificates.

Web servers and reverse proxies like Nginx, Envoy, Caddy, and Apache all support mTLS through configuration directives. These directives specify the trusted CA bundle and require client certificate verification.

The following application code provides native mTLS support:

• Go (crypto/tls with ClientAuth: tls.RequireAndVerifyClientCert)
• Python (ssl.SSLContext with verify_mode=ssl.CERT_REQUIRED)
• Java (SSLContext with a TrustManagerFactory)

However, the server must be configured to require a client certificate and validate it against a trusted CA. Without this requirement, the server can accept anonymous connections and mTLS is not in effect. 

Common mTLS errors and causes

mTLS handshake failures can be more challenging to diagnose than application-layer authentication failures because the protocol reveals as little as possible to unauthenticated parties.

Certificate validation errors

The most frequent causes of mTLS failure are certificate-related, including expired certificates, mismatched CA trust stores (where one side does not trust the CA that signed the other's certificate), missing or incorrect Extended Key Usage extensions, and private key or certificate mismatches.

The openssl verify, openssl x509, and openssl s_client commands are standard tools for diagnosing these issues outside of live application traffic.

The table below lists common mTLS certificate error messages and their cause.

mTLS compared to other authentication methods

mTLS operates at the transport layer, meaning authentication happens during the TLS handshake and before any application data is exchanged. 

Other authentication methods typically operate at the application layer, where credentials are passed in HTTP headers alongside the request itself, creating practical consequences for security, credential management, and what each method is best suited for.

mTLS vs API keys

API keys are static strings that a client sends with every request, usually in an HTTP header. If an attacker intercepts an API key, they can reuse it from any location. There is no built-in mechanism for automatic rotation, and keys tend to be long-lived and are seldom rotated.

mTLS avoids these problems by ensuring the client's private key is never transmitted. Authentication happens through a proof-of-possession during the handshake, and if an attacker intercepts the certificate, they still cannot authenticate without the private key.

API keys are a reasonable choice for simple integrations with external partners where certificate provisioning is impractical. However, mTLS is a better fit when both endpoints are controlled infrastructure and stronger identity verification is needed.

mTLS vs OAuth 2.0 and OIDC

OAuth 2.0 and OpenID Connect (OIDC) are designed for user-facing authentication and delegated access, issuing short-lived bearer tokens that represent both the client application and the end user. These tokens carry claims (such as user identity, roles, and scopes) that the receiving service uses for authorization decisions.

mTLS does not carry user identity or authorization context; it authenticates the service, not the user. 

A common production pattern combines the two, where mTLS authenticates the transport layer to establish which service is connecting and OAuth or JWT carries end-user identity to establish which user requested the action and what they are permitted to do.

mTLS vs SPIFFE JWT-SVIDs

SPIFFE supports two credential types: X.509-SVIDs and JWT-SVIDs. mTLS uses X.509-SVIDs for transport-layer authentication. JWT-SVIDs are an alternative for environments where mTLS is not possible, such as when communicating through a Layer 7 load balancer that terminates TLS and does not forward client certificates.

JWT-SVIDs are sent as application-layer tokens in HTTP headers, similar to OAuth tokens. They are short-lived and audience-bound, meaning each token specifies which service it is intended for. This prevents a compromised token from being reused with a different service.

How SPIFFE identities work with mTLS

SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF-graduated standard that defines a uniform identity format for workloads, which includes any running piece of software, such as a container, VM, or process.Together, SPIFFE addresses the core operational problem of mTLS at scale: how to issue, rotate, and validate certificates for thousands of short-lived workloads without manual intervention.

Every workload in a SPIFFE-enabled environment receives a SPIFFE Verifiable Identity Document (SVID). SVIDs come in two forms: X.509 certificates and JWTs. For mTLS, the X.509-SVID is used. It is a standard X.509 certificate with a SPIFFE ID encoded in the SAN field:

After attestation succeeds, the agent issues short-lived SVIDs. These are valid for hours and are renewed before they expire. The private key never leaves the node.

Applications consume SVIDs through the SPIFFE Workload API. Client libraries such as go-spiffe handle certificate retrieval, renewal, and TLS configuration. This allows services to establish mTLS connections using SPIFFE identities with minimal code changes.

How Teleport uses mTLS

Teleport uses mTLS as the default transport security for all connections between clients, agents, and the Teleport Auth Service. Every connection is mutually authenticated with short-lived X.509 certificates. This applies whether a user is accessing a server, a CI/CD bot is authenticating to a database, or a service-to-service workload is communicating.

Automated certificate lifecycle: Teleport's built-in CA issues short-lived certificates (typically hours, configurable down to minutes) and handles automatic renewal. There are no static credentials to rotate and no manual certificate management. The tbot agent handles certificate issuance and renewal for machine and workload identities, including CI/CD runners, Kubernetes pods, and automated workflows.

SPIFFE-compatible workload identity: Teleport issues X.509-SVIDs and JWTs compatible with the SPIFFE standard. This enables workloads to authenticate to each other and to external services like cloud APIs, databases, and third-party services using cryptographic identity rather than static secrets.

Identity-aware access controls: Because every mTLS connection carries a cryptographic identity, Teleport binds access policy, session audit, and real-time monitoring directly to that identity. Access decisions are evaluated per-connection using role-based and attribute-based access controls, just-in-time access requests, and device trust signals.

Static credential elimination: mTLS with short-lived certificates replaces static or long-lived SSH keys, database passwords, API tokens, and Kubernetes credentials. Every actor, whether human or machine, authenticates with a cryptographic identity that expires automatically and cannot be phished or replayed.

Related articles

• Certificates, Keys, and Trust: The World of PKI and mTLS
• What are Short-Lived Certificates?
• What is Authorization?
• What is OAuth2.0 (Open Authorization)?
• How to Secure Microservices with SPIFFE and Istio