Authentification mTLS
mTLS (mutual TLS) est une extension du protocole TLS où le client et le serveur s’authentifient mutuellement à l’aide de certificats.
Cas d’usage:
- Connexion entre microservices (ex : Service A ↔ Service B)
- API REST sécurisées avec authentification forte
- Dispositifs IoT ou machines qui doivent prouver leur identité
- Environnements "Zero Trust"
Prérequis:
- 📌 Côté serveur:
- 🧭 Un nom de domaine (FQDN) configuré dans une zone DNS accessible par le client.
- 🌐 Un enregistrement DNS (A ou AAAA) pointant vers l’adresse IP du serveur.
- 🖥️ Un serveur à cette adresse IP, configuré pour accepter les connexions TLS avec mTLS activé.
- 🔐 Un certificat X.509 valide, signé par une CA de confiance (contenant le FQDN dans le CN ou SAN).
- 🔗 Une chaîne de certificats complète (certificats intermédiaires inclus si nécessaire).
- 📜 La CA qui a signé le certificat serveur est présente dans le magasin de confiance du client.
- 📌 Côté client:
- 🔐 Un certificat X.509 client, signé par une CA de confiance reconnue par le serveur.
- 🔑 La clé privée correspondant au certificat client.
- 📜 La CA du client (ou une chaîne complète) est enregistrée sur le serveur comme CA de confiance.
- 📆 Le certificat client est valide (non expiré, non révoqué, etc.).
- 🔒 Le client est capable de présenter ce certificat lors du handshake TLS.
Séquence:
1. Client Hello
- Version TLS supportée
- Suites cryptographiques proposées
- Extensions (SNI, etc.)
- Nombre aléatoire du client (
client random)
2. Server Hello + Certificat
- Version TLS sélectionnée
- Suite cryptographique choisie
- Nombre aléatoire du serveur (
server random)
- Certificat du serveur
- Demande de certificat client (via
CertificateRequest)
3. Vérification du certificat serveur
Le client vérifie que le certificat du serveur est :
- Valide et signé par une autorité de confiance
- Correspond au nom de domaine
4. Envoi du certificat client
- Le client envoie son propre certificat
- Il prouve qu’il possède la clé privée correspondante (signature ou échange de clés)
5. Négociation du secret partagé
- Génération d’un secret partagé via Diffie-Hellman (ou autre)
- Dérivation d’une clé de session symétrique
6. Messages "Finished"
Chaque côté envoie un message Finished signé et chiffré, validant le succès du handshake.
7. ✅ Connexion sécurisée mutuellement authentifiée
- Le serveur est certain de l’identité du client
- Le client est certain de l’identité du serveur
- La communication est entièrement chiffrée et authentifiée