mTLS Handshake Lab
Mutual TLS fails on trust and identity, not syntax — and its worst failure is the one that looks like success. For each handshake you get the client cert, the server cert, the server's trust store and requirements, and the client's trust of the server. Make the two calls that matter: diagnose why client-cert auth fails (or confirm it is correct), then pick the right fix — and learn why a green padlock is not proof of mutual authentication.
The real job. More noise, a tighter clock.
Inspect the handshake
For each mutual-TLS handshake you get the client certificate, the server certificate, the server's mTLS configuration (what it requires and which CAs it trusts for client auth), and whether the client trusts the server. Make the two calls that matter: diagnose why it fails (or confirm it is correct), then choose the right fix. One point for the diagnosis, one for the fix. Clear 75% to pass — finish under par for a speed bonus and a better grade.
What this lab is
- A free, browser-based mutual-TLS lab: inspect a handshake — client cert, server cert, the server's trust store and requirements, the client's trust of the server — and diagnose why it fails.
- For each scenario you make two calls: the correct diagnosis (or confirm the handshake is fine) and the correct fix.
- Seed failures include an untrusted or expired client cert, a missing clientAuth EKU, a SAN/SPIFFE identity mismatch, a server cert the client does not trust, and the dangerous case where the server never requests a client cert so auth is silently skipped.
- Harder tiers add subtler failures: an incomplete chain (missing intermediate), a split-trust model, and a SPIFFE identity mismatch that verifies but is not authorized.
- You score one point for the diagnosis and one for the fix per scenario, with a speed bonus for finishing under par.
Frequently asked questions
What is the mTLS Handshake Lab?
A free, in-browser exercise where you are shown a mutual-TLS handshake — the client certificate, the server certificate, the server's mTLS configuration (whether it requires a client cert, which CAs it trusts for client auth, any required SAN/SPIFFE identity, and whether it enforces the clientAuth EKU) and whether the client trusts the server. For each one you diagnose why it fails (or confirm it is correct) and pick the right fix. You get immediate feedback with a rationale and a running score.
What failures does it cover?
A client cert signed by a CA the server does not trust; an expired client cert; a cert missing the clientAuth Extended Key Usage; a SAN or subject identity that does not match the required one; a server cert the client does not trust (so the client aborts); and the security hole where the server is not actually configured to request a client cert, so mutual auth is silently skipped. Higher difficulty tiers add an incomplete chain (the issuing intermediate is not sent), a split-trust model, and a SPIFFE identity mismatch — a cert that verifies but is not the authorized identity.
Why does a successful handshake not always mean mTLS is working?
Because a server can present a valid certificate and encrypt the channel without ever requesting or verifying a client certificate. The connection "succeeds" and the padlock is green, but client authentication never happened — anyone who can reach the endpoint is accepted. The lab makes you spot that case, which is one of the most common real-world mTLS misconfigurations.
Is this a real TLS stack?
No. It is a teaching model of mutual-TLS verification and authorization: chain trust, validity, key usage, identity pinning and whether client auth is actually enforced. It deliberately simplifies the wire protocol so the lesson — trust vs. authorization, and fixing the correct side of the connection — is clear. Every certificate, CA and identity is invented.