Mutual TLS Between Services

Mutual TLS authenticates both ends of a connection with certificates. In ordinary TLS, the encryption behind HTTPS, only the server proves its identity; in mutual TLS the client also presents a certificate and proves it holds the private key. The API knows which service is calling before the first header arrives. It suits services inside one system, and access is cut off by revoking a certificate or not renewing it.

What proves the caller. A certificate issued by a certificate authority, CA, both sides trust, usually one the organisation runs itself, and the private key that matches it. The key never leaves the client.

Where it travels. In the TLS handshake, below HTTP. Nothing in a header can be copied and replayed, because the proof is tied to the connection.

Which client it suits. Services that belong to one organisation, where certificates can be issued and rotated automatically, often by a service mesh. It also appears in banking APIs for partners. It does not suit browsers or apps for the public, where installing a client certificate is impractical.

How access is cut off. Certificates are issued with short lifetimes, often days, and left to lapse; or revoked, though checking revocation lists is unreliable in practice, which is why short lifetimes are preferred.

So use mutual TLS where the callers are your own services, and let automation issue and rotate the certificates.