We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Standard TLS is one-sided. The client verifies the server's identity, but the server has no idea who the client is. For a public website, this is fine. Anyone should be able to connect to google.com. But for internal microservices, this is a problem. If Service A calls Service B, Service B needs to verify that the caller is actually Service A and not a compromised pod, a rogue container, or an attacker who gained network access.
The 2020 SolarWinds attack demonstrated why this matters. Attackers compromised a trusted network management tool and moved laterally across thousands of organizations. Internal services that trusted any connection from the corporate network were wide open. Mutual TLS would have required every connection to present a valid certificate, blocking lateral movement from compromised but uncertified processes.
mTLS is the foundation of zero-trust networking, where no connection is trusted by default, regardless of whether it originates from inside or outside the network perimeter.
The mTLS handshake adds one extra step to the standard TLS handshake: the server requests and verifies the client's certificate.
In standard TLS, only the server sends a certificate. In mTLS, after the server sends its certificate, it sends a CertificateRequest message asking the client to prove its identity too. The client responds with its own certificate. The server verifies the client certificate chain against its trusted CA store, checks expiration and revocation, and only then completes the handshake.
If either side's certificate is invalid, expired, revoked, or signed by an untrusted CA, the connection is refused before any application data flows. No negotiation, no fallback, no "trust but verify." The handshake simply fails.