TLS où client et serveur s'authentifient mutuellement via certificats.
mTLS (Mutual TLS) est une variante de TLS où les deux parties (client et serveur) s'authentifient mutuellement via certificats X.509 — vs TLS classique où seul le serveur prouve son identité. Forme d'authentification très forte utilisée dans zero-trust networking, service-to-service auth, et accès high-security.
Handshake (en simplifié) :
(1) Client → Server : ClientHello + supported ciphers.
(2) Server → Client : ServerHello + server certificate + **CertificateRequest** (demande cert client).
(3) Client → Server : Client certificate + CertificateVerify (signs handshake with client private key).
(4) Server verifies client certificate (chain + revocation OCSP/CRL) + signature.
(5) Both authenticated → session established.
Use cases :
(1) **Service mesh** — Istio, Linkerd, Consul Connect auto-issue cert per service, mTLS between all pods Kubernetes. Encrypts all east-west traffic, identity-based auth.
(2) **Zero Trust Network Access (ZTNA)** — Cloudflare Access, BeyondCorp — client cert from device validates user/device identity.
(3) **API authentication B2B** — partner integrations where each company has their cert (vs API keys).
(4) **IoT devices** — fleet management, each device unique cert.
(5) **Banking APIs** — Open Banking (PSD2) requires mTLS.
(6) **High-security admin access** — kubectl access K8s API server, etcd cluster.
(7) **Federal/government** — PIV cards, CAC cards authentication.
Client certificate provisioning : (1) **Manual** — generate via openssl, distribute ; (2) **PKI infrastructure** — Microsoft AD CS, FreeIPA, HashiCorp Vault PKI ; (3) **SPIFFE/SPIRE** — modern service identity framework ; (4) **Cert-manager Kubernetes** — auto-issue via Let's Encrypt or internal CA ; (5) **AWS IoT Core** — fleet provisioning.
Challenges :
(1) **Cert lifecycle** — issuance, renewal, revocation. Manual = nightmare scale ; automation critical.
(2) **CRL/OCSP** — revocation checking adds latency and dependencies.
(3) **Browser UX** — client cert prompts confusing for end users (mTLS rarely good for consumer web).
(4) **Debugging** — failure modes complex (cert expired, CA chain incomplete, name mismatch).
(5) **Certificate exposure** — private key compromise = identity stolen, hard to revoke quickly.
Istio mTLS exemple : `PeerAuthentication mode: STRICT` — all traffic in mesh enforced mTLS, identity = service account from Kubernetes. Automatic cert rotation via Citadel. Compétences SC-300, AZ-500, CKS.
200+ certifications, 400 000+ questions, examens blancs chronométrés.
Voir le catalogue →