mTLS Explained in 60 Seconds: Why Passwords Are Dead
Regular TLS: the server proves its identity to you. Mutual TLS: both sides prove identity. The server verifies you with a certificate before a single byte of application data is exchanged.
No passwords. No tokens. No MFA fatigue. Your identity is a cryptographic certificate issued by a trusted CA.
What It Looks Like in Practice
I deployed mTLS on my PKI admin portal this week. Here's what happens:
$ curl https://test.mykeypair.be/
curl: (56) Connection reset by peer
→ Not a 403. Not a login page. Nothing. The server refuses to speak.
$ curl --cert client.p12 https://test.mykeypair.be/
mTLS verified! You are authenticated by MKP PKI.
Subject: CN=Ismail Zemouri,O=MyKeyPair,C=BE
Issuer: CN=MKP Issuing CA G1,O=MyKeyPair,C=BE
Why This Matters for Compliance
DORA Article 7.5 requires "strong authentication mechanisms" for critical ICT systems. Certificate-based mTLS is as strong as authentication gets:
- ✓ Can't be phished (no credentials to steal)
- ✓ Can't be brute-forced (asymmetric cryptography)
- ✓ Can't be replayed (TLS handshake is unique per session)
- ✓ Full audit trail (certificate identity logged per connection)
- ✓ Revocable (CRL/OCSP can invalidate access instantly)
The Setup
Three components:
- EJBCA issues client certificates via a self-service RA Web portal
- Caddy enforces mTLS on specific routes using the CA chain as trust anchor
- Certificates auto-renew — no password rotation fatigue
The future of authentication isn't better passwords. It's no passwords.
Want to see this in action on your infrastructure? Let's talk.