mTLS vs Ordinary TLS: The Difference Explained

TLS and mTLS use the same protocol and the same cryptography — the difference is who proves their identity. That small shift has large consequences for architecture, operations and the number of certificates you must manage. Here is the difference, and when each one makes sense.

Short answer

Ordinary (one-way) TLS authenticates only the server: the client confirms it is talking to the right server but stays anonymous at the transport layer. mTLS is two-way: both server and client present a certificate, and both are validated. The encryption is identical — the difference is purely the client authentication. You choose mTLS when you need to prove who the client is, typically in service-to-service and machine-to-machine scenarios.

The core difference: who proves what

Property	Ordinary TLS	mTLS
Server identity verified	Yes	Yes
Client identity verified	No	Yes
Client needs a certificate	No	Yes
Extra handshake messages	—	CertificateRequest, Certificate, CertificateVerify
Certificates to operate	One per server	One per server + one per client

The handshake side by side

In both cases the client starts with ClientHello and the server responds with its certificate. The difference comes in the server's reply. With mTLS the server adds a CertificateRequest, and the client must respond with its certificate and a signature proving it owns the private key:

Ordinary TLS                   mTLS
------------                   ----
ClientHello          -->       ClientHello          -->
            <-- ServerHello                <-- ServerHello
            <-- Certificate                <-- Certificate
                                           <-- CertificateRequest
            <-- ServerHelloDone            <-- ServerHelloDone
(client sends no cert)         Certificate          -->
                               CertificateVerify    -->
Finished             -->       Finished             -->

To understand the full underlying handshake, read the TLS handshake explained.

How the test looks different

Against an ordinary TLS server you connect without ceremony:

openssl s_client -connect example.com:443 -servername example.com

Against an mTLS server you get a handshake failure unless you supply a client certificate. The output reveals the requirement with the line Acceptable client certificate CA names:

openssl s_client -connect api.example.com:443 -servername api.example.com \
  -cert client.crt -key client.key

What mTLS does not solve

mTLS proves identity, not authorisation. The fact that a client holds a valid certificate tells you who it is — not what it may do. You still have to map the certificate identity (typically the CN or a SAN) to permissions in your application. Nor does mTLS replace encryption — it sits on top of the same encryption as ordinary TLS.

When do you choose which?

Ordinary TLS: public websites and APIs where the clients are unknown (browsers, mobile apps, third parties). Client identity is handled at the application layer with login, OAuth or API keys.
mTLS: closed environments where you control both ends — service mesh, gateway-to-backend, internal machine-to-machine APIs and Zero Trust.

The operational price of mTLS

The shift from "one certificate per server" to "one per server and one per client" rapidly multiplies the number of certificates and expiry dates. CertControl discovers and monitors them all — server and client certificates from internal CAs alike — and warns before they expire, so the two-way trust is not suddenly broken by a forgotten renewal. Read more in our mTLS guide.

Frequently asked questions

Does mTLS use different encryption than ordinary TLS?

No. The encryption, cipher suites and protocol versions are the same. mTLS only adds client authentication on top of the existing TLS handshake.

Is mTLS slower than ordinary TLS?

Marginally. There is a little extra work during the handshake (validating the client certificate and one extra signature), but it is a per-connection one-off. With session resumption the difference is negligible in practice.

Can a browser use mTLS?

Yes, via client certificates, but the UX is clumsy and scales poorly to many users. mTLS is therefore mostly used for machine-to-machine traffic. See the article on client certificates in browsers.

Does mTLS replace a login?

Not necessarily. mTLS proves the identity of the client machine or service, not necessarily of a human user. For user login, token- or session-based authentication is usually more practical.

Must the server and client certificates come from the same CA?

No. The server can have a public certificate while clients hold certificates from an internal CA. Each party simply configures which CA it trusts for the opposite role.

See the platform Book a demo

mTLS vs ordinary TLS