mTLS (mutual TLS) is a security protocol that extends standard TLS by requiring both the client and server to authenticate each other using digital certificates. In standard TLS, only the server proves its identity. In mTLS, both sides present and verify certificates before any data is exchanged.
Standard TLS is one-way: only the server presents a certificate. mTLS is two-way: both the client and the server exchange and verify certificates against a trusted Certificate Authority. This mutual authentication makes mTLS significantly stronger for machine-to-machine communication where you cannot rely on user login credentials.
The mTLS handshake works in five steps: (1) the client sends a ClientHello to initiate the connection, (2) the server responds with its certificate and requests the client's certificate, (3) the client presents its own certificate, (4) both parties verify each other's certificates against a trusted Certificate Authority, and (5) they derive shared session keys and begin encrypted communication.
Yes. Because both parties must present valid certificates signed by a trusted Certificate Authority, an attacker cannot impersonate either side without access to a legitimate certificate. A man-in-the-middle attacker fails certificate verification and the connection is rejected before any data is sent.
mTLS is considered highly secure for machine-to-machine communication. The protocol itself is sound; the main operational risk is certificate lifecycle management. A compromised certificate must be revoked quickly via OCSP or CRL. Used with short-lived certificates and automated rotation, mTLS is one of the strongest authentication mechanisms available.
mTLS is best suited for service-to-service communication where both sides are machines: microservices architectures, API-to-API calls, zero trust network access, IoT device authentication, and service mesh environments. It is not typically used for browser-to-server connections because distributing client certificates to end users is operationally complex.
The main benefits of mTLS are: mutual authentication (both sides are cryptographically verified), strong protection against impersonation and man-in-the-middle attacks, encrypted data in transit, alignment with zero trust security principles, and an auditable certificate record for compliance.
mTLS authentication is the process by which both the client and server verify each other's identity using X.509 digital certificates issued by a trusted Certificate Authority. Unlike password-based authentication, mTLS uses asymmetric cryptography: each party proves possession of a private key without ever transmitting it, making credentials impossible to intercept or brute-force.
In this post, we cover the different methods you can use for authenticating traffic with ngrok, including OAuth and OpenID Connect using Traffic Policy.
Mutual TLS (mTLS) is a security protocol that extends standard TLS by requiring both parties in a connection to authenticate each other using digital certificates. The server proves itself to the client, and the client proves itself right back.
This mutual authentication is what separates mTLS from standard TLS and makes it the dominant choice for securing machine-to-machine communication: microservices, API gateways, IoT devices, and zero trust architectures all rely on it.
What is TLS, and why isn’t it enough?
Before understanding mTLS, it helps to understand what standard TLS does, and what it leaves out.
TLS (Transport Layer Security) is the protocol that secures most internet traffic today. When your browser connects to https://ngrok.com, TLS is doing two things: authenticating the server (via its certificate) and encrypting the connection so nobody can read the data in transit.
That authentication is one-directional. The server proves its identity to you, but you don’t prove your identity to the server. For a public website, that’s fine: the server doesn’t need to know who you are just to serve a web page. Application-layer authentication (username and password) handles that.
For service-to-service communication, the situation is different. There’s no human logging in. Service A needs to know that the response it’s receiving is genuinely from Service B, not an attacker who has compromised the network and is intercepting calls. A shared secret or API key helps, but those can be stolen. A cryptographic certificate, backed by a trusted Certificate Authority, cannot be forged.
That’s the gap mTLS fills.
How does mTLS work?
The mTLS handshake extends the standard TLS handshake by adding a client certificate exchange step. Here’s the full sequence:
1. Handshake initiation
The client sends a ClientHello message to the server, advertising the TLS version and cipher suites it supports.
The server responds with a ServerHello and, critically, includes a CertificateRequest message asking the client to present its own certificate. This is the step that doesn’t exist in standard TLS.
2. Certificate exchange
The server sends its digital certificate to the client. This certificate contains the server’s public key and is signed by a Certificate Authority (CA) the client trusts.
The client then sends its own certificate to the server, containing the client’s public key, signed by a CA the server trusts.
3. Certificate verification
Both parties independently verify the other’s certificate:
The client checks the server’s certificate against its trusted CA list, verifying the signature, expiry date, and hostname.
The server checks the client’s certificate against its trusted CA list. If the client’s certificate isn’t valid or isn’t signed by a CA the server recognizes, the connection is rejected here, before any application data is sent.
This is where mTLS stops man-in-the-middle attacks. An attacker intercepting the connection cannot produce a valid certificate signed by your private CA without access to the CA’s private key.
4. Key exchange
Once both certificates are verified, the client and server use the exchanged public keys to derive a shared session key through a key agreement algorithm (typically ECDHE). Neither side transmits this session key directly. Each one computes it independently from the other’s public key and their own private key.
5. Encrypted communication
All subsequent data is encrypted using the shared session key. Even if someone intercepts the traffic, they cannot decrypt it without the private keys that were never transmitted.
mTLS vs TLS: key differences
TLS
mTLS
Who authenticates
Server only
Client and server
Client certificate required
No
Yes
Protects against impersonation
Server impersonation only
Both sides
Typical use case
Browser to website
Service to service
Operational complexity
Low
Higher (certificate lifecycle)
Zero trust compatible
Partial
Yes
The core trade-off is complexity vs. assurance. Standard TLS is simpler to operate because only server certificates need managing. mTLS requires issuing, rotating, and revoking client certificates too, but in return you get cryptographic proof that both parties are who they claim to be.
mTLS authentication: how certificates work
The foundation of mTLS is X.509 digital certificates. Understanding these explains why mTLS is stronger than shared secrets or API keys.
Certificate Authorities (CAs) are the root of trust. A CA is an entity that issues certificates, signing each one with its private key to vouch for the certificate holder’s identity. In an mTLS setup, you typically run your own private CA, not a public CA like Let’s Encrypt, because you don’t want arbitrary clients on the internet to be able to obtain a certificate.
Certificate issuance works like this: a service generates a key pair (public + private), creates a Certificate Signing Request (CSR) containing its public key and identity information, and submits it to the CA. The CA verifies the identity and signs the certificate. The private key never leaves the service.
Certificate verification at handshake time asks: does this certificate chain back to a CA I trust? Is it expired? Has it been revoked?
Revocation is the Achilles heel of certificate-based auth. If a service’s private key is compromised, you need to revoke its certificate quickly. Two mechanisms handle revocation:
OCSP (Online Certificate Status Protocol) lets the verifier query the CA in real time for a certificate’s current status.
CRL (Certificate Revocation List) is a list of revoked certificates that the CA publishes and verifiers download periodically.
For production mTLS, automated certificate rotation, using short-lived certificates that expire every few hours or days, is increasingly preferred over revocation, because it limits the blast radius of a compromised key without depending on revocation infrastructure being available.
When to use mTLS
mTLS shines in environments where all participants are machines and you can control certificate issuance:
Microservices and service meshes. Service meshes like Istio and Linkerd use mTLS by default for all intra-cluster traffic. Every service gets a certificate, and mutual authentication happens transparently at the sidecar proxy layer.
API gateways. When your API gateway receives requests from partner services or internal clients, mTLS gives you cryptographic proof of which client is connecting. That’s stronger than API keys, which can be shared or leaked.
Zero trust networks. Zero trust security assumes no implicit trust based on network location: every connection must be authenticated regardless of whether it’s internal or external. mTLS is the standard mechanism for enforcing this for machine identities.
IoT devices. Devices in the field can hold a certificate provisioned at manufacture time. When they connect home, mTLS verifies the device is genuine, not an attacker who has taken over the device’s IP address.
Webhooks and callbacks. If your service sends webhooks to customer endpoints, mTLS lets you verify the customer’s endpoint is authentic before sending sensitive data.
mTLS is generally not used for browser-to-server connections, because distributing client certificates to end users at scale is operationally difficult. For human-facing authentication, OAuth 2.0 and OpenID Connect are the standard choice.
mTLS challenges and limitations
Understanding the costs helps you decide when mTLS is worth it:
Certificate lifecycle management. Every service needs a certificate, and certificates expire. Automating issuance and rotation is critical, because manual certificate management at scale is a source of outages, not security.
Debugging. Encrypted connections with mutual auth are harder to inspect than plain HTTP. Tools like ngrok’s Traffic Inspector help here by capturing the decrypted request/response at the gateway layer before forwarding to your upstream.
CA infrastructure. Running a private CA requires operational care. Compromise of the CA’s private key means all certificates it has signed must be considered untrusted. Keep CA keys in a hardware security module (HSM) or a secrets manager with tight access controls.
Performance. The additional certificate verification during the handshake adds a few milliseconds of latency compared to standard TLS. For long-lived connections this is negligible; for high-frequency short-lived connections it can accumulate.
How to implement mTLS with ngrok
ngrok’s terminate-tls Traffic Policy action makes mTLS straightforward to configure without modifying your application code. You configure mTLS at the ngrok edge, and ngrok handles the certificate verification and forwards the authenticated request to your upstream service.
