What Is mTLS? β Definition and How It Works
Learn how mutual TLS authenticates both sides, where it is required, and how to use a client certificate.
Mutual TLS extends ordinary TLS so that both parties present certificates. The server proves its identity as usual, and the client proves its own.
1. What Changes
In ordinary TLS the client verifies the server and remains anonymous at the transport layer; any client authentication happens above it, with a token or a password.
In mTLS the server requests a certificate during the handshake, the client sends one, and the server verifies it against a trusted CA. Authentication is complete before any HTTP request is sent.
| TLS | mTLS | |
|---|---|---|
| Server authenticated | Yes | Yes |
| Client authenticated | No | Yes, by certificate |
| Auth happens | Above transport | In the handshake |
| Credential | Token or password | Private key |
| Failed auth | An HTTP 401 | Handshake failure |
That last row matters practically: a client certificate problem produces a TLS error, not an HTTP status. There is no response body to read.
2. Where It Is Used
- Banking and payments APIs, frequently mandatory.
- Healthcare data exchange.
- Government and regulated interfaces.
- Service-to-service traffic inside a service mesh, where it is now common.
- Partner integrations where both sides are known organisations.
- IoT device fleets, where each device holds a certificate.
The pattern: mTLS appears where both parties are identified entities under an agreement, not where anonymous users arrive.
3. Using a Client Certificate
import requests
r = requests.get(
"https://api.partner.example.com/v1/data",
cert=("/secure/client.crt", "/secure/client.key"), # or a single combined PEM
verify="/secure/partner-ca.pem", # verify their chain too
timeout=(10, 60),
)
curl --cert client.crt --key client.key --cacert partner-ca.pem \
https://api.partner.example.com/v1/data
Both sides of the trust relationship usually need configuring: your certificate for them, and their CA for you.
4. The Private Key Is the Credential
The client's private key is the identity. Whoever holds it can authenticate as you, and unlike a token it typically does not expire for a long time.
Handling rules that follow:
- Store it in a secret manager, or a file with restricted permissions β never in a repository or a container image layer.
- Never log it, and never include it in a support bundle.
- Use a passphrase where the platform supports it.
- Rotate before expiry, with an overlap so nothing breaks at the boundary.
- Revoke immediately if exposed; a leaked client key is a full authentication bypass.
5. Diagnosing Failures
mTLS failures are opaque because they occur before HTTP. The useful diagnostic:
openssl s_client -connect api.partner.example.com:443 \
-cert client.crt -key client.key -CAfile partner-ca.pem -servername api.partner.example.com
Common causes:
| Symptom | Cause |
|---|---|
alert certificate required |
Certificate not sent β path or format wrong |
alert unknown ca |
Your cert is not signed by a CA they trust |
alert certificate expired |
Expired client or server certificate |
alert handshake failure |
No shared cipher, or a policy rejection |
| Works with curl, fails in code | The library is not sending the cert |
That last case is frequent: many HTTP clients silently ignore certificate configuration if the parameter name or format is wrong, and the failure looks like a server problem.
6. Certificate Chains Still Apply
Your client certificate may need intermediates sent alongside it, exactly as a server's does. An incomplete client chain produces unknown ca even though the certificate is valid β the same missing-intermediate problem that affects server chains, from the other direction.
7. Where It Fits Collection Work
mTLS is a signal about the relationship, not an obstacle to overcome. An interface requiring a client certificate is an interface intended for identified partners under an agreement.
So encountering it means one of two things: you have a partnership and were issued a certificate, in which case use it as above; or you have not, in which case the interface is not open to you and the answer is to ask rather than to work around it.
There is no client-side trick here β without a key signed by a CA the server trusts, the handshake cannot complete.
8. Summary
Mutual TLS authenticates both parties in the handshake, with the client presenting a certificate the server verifies against a trusted CA, so authentication completes before any HTTP request.
Failures surface as TLS alerts rather than HTTP statuses β diagnose with openssl s_client β the client private key is a long-lived full credential requiring secret-manager handling and overlapping rotation, and an mTLS endpoint is by design reachable only by parties who were issued a certificate.