What is mTLS? Mutual TLS and how it differs from TLS

Mutual TLS (mTLS) is a TLS connection in which both sides present certificates: the server proves who it is, and the client does too. It is defined in the SSL and TLS glossary next to the ordinary, one-way TLS that every HTTPS site uses.

One-way TLS versus mutual TLS

In ordinary TLS only the server is authenticated. The browser checks the server's certificate against the name it asked for; the server learns nothing about the client at that stage, and identifies a person later with a password, a cookie or a token.

Mutual TLS moves client identity into the connection itself. The server asks for a certificate, the client presents one and proves it holds the matching private key, and the server checks it against the authorities it accepts. If that check fails, the connection ends before any request reaches the application.

What happens in the handshake

The difference is one extra exchange. In TLS 1.3 (RFC 8446) the server sends a CertificateRequest message, listing the kind of certificate it will accept. The client answers with its own Certificate and a CertificateVerify message, a signature made with the client's private key over the handshake so far.

That signature is the point. The client never sends a reusable secret: it demonstrates possession of a key, so a recording of the exchange cannot be replayed to impersonate it. This is the same property that makes server authentication work, applied in the other direction.

If the client sends no certificate, or one the server does not trust, the server ends the handshake with an alert. Tools report this as a handshake failure, and the server's log usually says which check failed.

Where mTLS is used

• Service-to-service traffic. Systems that call each other's APIs inside a company or between partners, where every client is a machine you issued a certificate to.

• Zero-trust networks. Where being inside a network grants nothing, and every connection has to prove which workload it comes from.

• Administrative interfaces and devices. Panels and devices that should accept connections only from known machines.

It fits poorly with the general public. Every visitor would need a certificate issued, installed and replaced, which is the work ordinary sign-in exists to avoid. Browsers can present client certificates, but the experience of choosing one from a prompt is why consumer sites do not ask for it.

How to test a mutual TLS endpoint

Both OpenSSL and curl can present a client certificate:

$ openssl s_client -connect api.example.com:443 -cert client.crt -key client.key
$ curl --cert client.crt --key client.key https://api.example.com/

Run the same command without the certificate. If the endpoint really requires mTLS, the second attempt should fail at the handshake rather than return a page.

What the server has to be configured with

Turning mutual TLS on is a short list of decisions, and each one is a place where a setup goes quietly wrong.

• Which authorities to trust for clients. A separate list from the one browsers use for servers. Trusting a public authority here would accept any certificate anyone can obtain for any domain.

• Whether a certificate is required or optional. Optional lets the application decide per route; required rejects anything without one at the handshake.

• Which part of the certificate identifies the client. Usually a name in the subject or the subject alternative names. That value is what the application authorises, so it has to be one you control when issuing.

• Where identity is handed to the application. When a proxy terminates TLS, it passes the verified identity on, typically in a request header. The application must accept that header only from the proxy, or anyone can set it.

Why mutual TLS fails

• The server never asks. Client certificate verification is off or optional, so a client without one gets through and the problem shows up later as an authorisation error.

• The certificate is not for client authentication. Certificates carry an extended key usage; one issued only for server authentication can be refused when presented as a client certificate.

• The chain is incomplete. The client sends its own certificate without the intermediate that links it to the authority the server trusts.

• It expired. Client certificates are issued and forgotten more often than server ones, and nothing in a browser warns anyone first.

What it costs to run

The certainty comes with a certificate lifecycle for every client, and that is the part people underestimate.

• Issuing. Usually from a private authority you operate, not a public one, so that only clients you approved can obtain a certificate your server accepts.

• Distribution. Each client needs its certificate and private key placed where its software can read them, and nowhere else. Encoding is not protection: anyone who can read an unencrypted key in the base64 text of a PEM-format file has it.

• Renewal. Client certificates expire like server certificates. An expired client certificate looks, from the outside, like a sudden outage of one integration.

• Revocation. When a client should stop being trusted, the server has to learn that, which is harder than it sounds; see certificate revocation.

What mTLS does not give you

It proves which certificate the client holds, not what the client is allowed to do. Authorisation, rate limits and auditing still belong to the application. It also proves nothing about a stolen key: a client certificate copied with its private key works for whoever has it, until it is revoked or expires.

FAQ

Related terms

The connection is covered under TLS, certificates and their lifecycle under certificates. A stricter check in the other direction is certificate or key pinning, in which an app accepts only specific server certificates or public keys. The rest of the vocabulary is in this glossary.