Mutual TLS Authentication
Prerequisites
Before reading this article, you need to study:
In previous articles, we learned:
- Certificates and CA solve the trust problem of public key distribution, allowing the client to verify the server’s identity.
- TLS Key Exchange Algorithm solves the problem of forward secrecy in key exchange, letting the client and server communicate securely.
These two mechanisms together help HTTPS build a secure, encrypted connection.
But there is a problem in this process: the server can only verify that the data sent by the client is encrypted, but cannot confirm the client’s identity.
For normal website visits, this isn’t a problem. Users visit websites with browsers, and authentication is usually done in the application layer (like entering a username and password).
But in other cases, this is a problem:
Scenario 1: Microservice to Microservice Calls
Suppose your order service wants to call the payment service’s API. How does the payment service know the request really comes from the trusted order service, and not an attacker faking it?
Scenario 2: Distributed Systems Without Built-in Authentication
Distributed coordination services like Zookeeper and etcd did not have proper user authentication in early versions. If exposed directly to the network, anyone could connect and change data.
Scenario 3: IoT Device Authentication
Internet of Things devices (like smart sensors) need to connect to the cloud. How can the server be sure that the device connecting is genuine, and not a tampered device?
In these situations, we need not only encrypted communication, but also two-way authentication of identity: the client should know who the server is, and the server should know who the client is.
This is the problem that mTLS (Mutual TLS, or two-way TLS) solves.
What is mTLS
In a standard TLS connection (like HTTPS), authentication is one-way: the client verifies the server’s certificate, but the server does not check the client’s identity.
This is fine for website visits. The server doesn’t need to check client identity at the network layer, because the user will do authentication at the application layer (like typing a password).
mTLS adds client authentication on top of TLS: the client must also present a certificate to the server.
During the TLS handshake, after the server sends its own certificate, it will send a request asking the client for a certificate. The client returns the certificate, and the server checks if it’s valid (certificate chain, validity period, revocation status, etc.). Only if the check passes, the connection proceeds.
Now both sides prove their identity with certificates and build mutual trust.
The main idea of mTLS is: Certificate = Identity.
It’s like at a bank—you show an ID card issued by the government (Client Certificate), and the bank shows its license issued by the government (Server Certificate). Only then can you trust each other.
mTLS Handshake Process
We have already explained the TLS handshake in detail in the earlier article. Here, we will focus on the difference between mTLS and standard TLS.
Standard TLS vs mTLS
The main difference is during the certificate exchange step:
Standard TLS (One-way Authentication):
mTLS (Two-way Authentication):