Mutual TLS Pattern

Le serveur prouve son identité au client, mais aussi l'inverse. Plus de cred dans le header — l'identité est portée par le certificat.

Problème

Le TLS « classique » authentifie le serveur via son certificat (client vérifie la chaîne contre une CA de confiance). Le client, lui, s'authentifie ensuite via mot de passe, JWT, API key — autant de secrets que l'on peut voler. Comment lier l'identité du client au transport, sans secret partagé et sans header à voler ?

Forces

• Mots de passe et API keys fuient (logs, bug, phishing).
• JWT en header est vulnérable au replay si le réseau n'est pas chiffré.
• Une PKI complète a un coût opérationnel (CA, CRL/OCSP, rotation).
• Les certificats expirent et bloquent les flux si non rotés.
• Le partenaire doit également gérer une PKI — friction d'onboarding.

Solution

Étendre le handshake TLS avec une étape supplémentaire CertificateRequest du serveur vers le client. Le client présente son propre certificat X.509, le serveur le vérifie contre une CA spécifique (la « CA partenaires » par exemple). L'identité du client (Subject DN, SAN) est désormais portée par le certificat — utilisable directement comme identité applicative. Pour la rotation, on supporte un overlap de validité ; pour la révocation, on consulte CRL ou OCSP stapling. Service Mesh modernes (Istio, Linkerd) automatisent mTLS entre microservices via SPIFFE / SPIRE.

Handshake mTLS

Client                                      Server
  │                                            │
  │ ClientHello (TLS 1.3, cipher suites)       │
  │ ─────────────────────────────────────────► │
  │                                            │
  │     ServerHello + Server Certificate       │
  │     + CertificateRequest                   │
  │ ◄───────────────────────────────────────── │
  │                                            │
  │ Client Certificate (X.509)                 │
  │ + CertificateVerify (sig with priv key)    │
  │ + Finished                                 │
  │ ─────────────────────────────────────────► │
  │                                            │
  │              Server verifies chain         │
  │              vs trusted CA                 │
  │              ──► identity = Subject DN     │
  │                                            │
  │     Finished                               │
  │ ◄───────────────────────────────────────── │
  │                                            │
  │      Encrypted application data            │
  │ ◄──────────────────────────────────────── ►│

Implémentation EDI

Tous les protocoles EDI modernes reposent sur mTLS : AS2 impose la signature S/MIME mais l'enveloppe HTTPS est souvent en mTLS quand le partenaire l'exige ; AS4 via OASIS ebMS3 utilise mTLS pour le transport. PEPPOL impose mTLS entre Access Points. Un hub interne basé sur Service Mesh (Istio) chiffre tout le trafic est-ouest en mTLS automatique — pas besoin d'API key entre microservices. Pour l'onboarding partenaire, on échange les CSR (Certificate Signing Request) hors-bande et on signe par la CA dédiée du hub.

Anti-patterns

• Désactiver la validation de la chaîne pour passer rapidement (« — insecure_skip_verify ») — équivaut à pas de TLS.
• Réutiliser une même CA pour tous les usages (interne + partenaires) — compromission catastrophique.
• Cert auto-signé non géré — expiration silencieuse.
• Pas de CRL ou OCSP — un cert compromis reste valide jusqu'à expiration.
• Rotation tous les 2 ans sans drill — l'opération de rotation casse en production le jour J.

Patterns liés

• Zero Trust Architecture — mTLS est la brique cryptographique.
• Secrets Management — gère les clés privées et les certificats.
• Service Mesh — l'automatise sur l'infrastructure.
• Defense in Depth — mTLS est une couche identité.

Sources

• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3. rfc-editor.org/rfc/rfc8446
• RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2.
• SPIFFE — Secure Production Identity Framework for Everyone. spiffe.io/docs/latest/spiffe-about/overview/
• OpenPEPPOL — eDelivery Network Specifications (mTLS profiles for AS4 between Access Points).