Service Identity on Nalar

Mutual TLS Moves Client Identity Into the Handshake

Tue, 15 Sep 2026 00:00:00 +0700

Mutual TLS Moves Client Identity Into the Handshake

An internal API can receive a perfectly encrypted TLS connection and still have no cryptographic evidence about the process at the other end. Ordinary server-authenticated TLS proves the server’s identity to the client and protects traffic in transit, but the application still needs another mechanism to identify its caller.

Mutual TLS, commonly shortened to mTLS, adds certificate-based client authentication to that exchange. The server requests a client certificate, validates the presented chain according to its trust policy, and verifies a signature proving possession of the corresponding private key. The result is a transport connection associated with a cryptographic client identity before ordinary application requests are processed.

Mutual TLS Makes Service Identity a Certificate Lifecycle Problem

Sun, 13 Sep 2026 00:00:00 +0700

A service can encrypt every connection and still have only a vague idea of what is calling it. Conventional server-authenticated TLS proves the server’s identity to the client, but the reverse direction is usually left to an application credential, a network location, or infrastructure convention. Mutual TLS changes that relationship by requiring the client to present a certificate as well. The transport can then carry authenticated identities in both directions before application data is exchanged.

Service Identity Does Not End at mTLS

Sat, 12 Sep 2026 00:00:00 +0700

A successful mutual TLS handshake can establish that both endpoints hold credentials accepted by their respective trust policies. In modern service platforms, that often happens inside sidecars, node agents, gateways, or transparent proxies rather than inside application code. The connection is encrypted, a workload identity has been authenticated, and the transport looks secure.

That is still only part of the security decision.

The authenticated peer may be the wrong workload for the requested operation. A proxy may know the peer identity while the application sees only a local connection. A certificate may remain valid after the workload’s authority has changed. A broad trust bundle may allow credentials from an environment that was never meant to reach a production service.