What Is Mutual TLS? Both Sides Prove Their Identity
Mutual TLS, or mTLS, extends ordinary TLS so that both the client and the server present certificates, each proving its identity to the other before any data flows.
In standard TLS, only the server proves who it is; the client stays anonymous at the transport layer. Mutual TLS makes the client present a certificate too, giving strong two-way authentication. It is common in service meshes and zero-trust networks, and CI must hold the right client certificate to reach such services.
Two-way authentication
In mTLS the handshake requires the client to present a valid certificate alongside the server. The connection succeeds only if each side trusts the other certificate, authenticating both parties.
Where mTLS is used
- Service meshes securing east-west traffic.
- Zero-trust networks that authenticate every connection.
- High-security APIs requiring client certificates.
Certificate distribution
Both sides need certificates issued by a trusted authority. Managing, rotating, and distributing client certificates is the main operational cost of mTLS.
mTLS in CI/CD
A pipeline calling an mTLS-protected service must hold a valid client certificate, usually injected as a secret. Without it, the handshake is rejected before any request is sent.
Why connections are refused
A missing, expired, or untrusted client certificate causes the handshake to fail outright. The error appears at connection time, not as an HTTP status, because no request ever completes.
Deterministic, not transient
An mTLS rejection from a bad client certificate fails every time until the certificate is fixed, so retrying does not help. Latchkey runners retry transient handshake resets but surface genuine certificate failures so you fix the credential.
Key takeaways
- Mutual TLS authenticates both client and server with certificates.
- It is common in service meshes and zero-trust networks.
- A missing or expired client certificate fails deterministically, not transiently.