mTLS (TLS mutuel) expliqué : authentification par ...

mTLS : authentification TLS mutuelle

Dans le TLS standard, seul le serveur prouve son identité avec un certificat. Dans le TLS mutuel (mTLS), les deux parties s'authentifient, comme deux personnes qui se montrent leur pièce d'identité avant d'échanger des informations. Ce guide explique comment fonctionne mTLS, où l'utiliser, comment le déployer et les pièges à éviter.

Vue d'ensemble

Mutual TLS (mTLS) est une extension du protocole TLS standard dans laquelle les deux parties, client et serveur, s'authentifient mutuellement à l'aide de certificats numériques. Dans un TLS classique (celui que vous utilisez en naviguant sur un site HTTPS), seul le serveur présente un certificat. Le client vérifie l'identité du serveur mais reste anonyme. Avec mTLS, le serveur demande aussi un certificat au client, et chaque partie vérifie l'identité de l'autre avant qu'aucune donnée applicative ne soit échangée.

Voyez cela comme l'entrée dans un bâtiment sécurisé : en TLS classique, vous vérifiez que le bâtiment est bien celui qu'il prétend être (en regardant la plaque sur la porte). En mTLS, le bâtiment vérifie aussi votre badge avant de vous laisser entrer. Les deux parties prouvent leur identité.

mTLS s'appuie sur le même modèle de chaîne de certificats et de confiance que le TLS classique. Les deux certificats doivent être signés par une autorité de certification que l'autre partie reconnaît. Le certificat client est généralement un certificat d'authentification client avec les extensions d'usage de clé appropriées.

Étapes clés

Client Hello

Le client initie le handshake TLS en envoyant les suites cryptographiques prises en charge, la version de TLS et des données aléatoires. Cette étape est identique à un handshake TLS standard.

Server Hello + certificat du serveur

Le serveur répond avec la suite cryptographique qu'il a choisie et présente sa propre chaîne de certificats. Le client vérifie le certificat du serveur dans son magasin de confiance.

Le serveur envoie ses paramètres d'échange de clés

Le serveur transmet ses paramètres d'échange de clés (Diffie-Hellman ou ECDHE). Les deux parties s'en servent pour dériver les clés de session partagées.

Certificat du client + CertificateVerify

Le client envoie sa chaîne de certificats ainsi qu'un message CertificateVerify : une signature, calculée avec sa clé privée, sur la transcription du handshake. Le serveur vérifie la chaîne de certificats et la signature, confirmant que le client détient bien la clé privée.

Finished + communication chiffrée

Les deux parties échangent des messages Finished et démarrent la communication chiffrée. Les deux identités sont vérifiées, le canal est chiffré et les données applicatives peuvent circuler en toute sécurité.

Composants clés

Communication entre API

Des microservices qui s'authentifient mutuellement sans clés d'API ni jetons. Chaque service possède son propre certificat, et le maillage de services impose mTLS entre tous les services. Aucun secret partagé à faire tourner.

Kubernetes et Istio

Les maillages de services comme Istio et Linkerd utilisent mTLS pour chiffrer et authentifier l'ensemble du trafic entre pods. Les identités SPIFFE sont encodées dans les URI des certificats, fournissant une identité au niveau de la charge de travail.

802.1X / EAP-TLS

Authentification Wi-Fi et réseau filaire en entreprise au moyen de certificats client. EAP-TLS utilise mTLS pour authentifier les équipements avant d'accorder l'accès au réseau. Aucun mot de passe à hameçonner.

Authentification VPN

L'authentification VPN par certificat remplace le couple identifiant/mot de passe par mTLS. Le client et le serveur VPN s'authentifient tous deux par certificat, ce qui renforce la sécurité et élimine les risques de vol d'identifiants.

Authentification d'objets connectés

Les équipements IoT utilisent mTLS pour s'authentifier auprès des back-ends cloud. Chaque équipement dispose d'un certificat unique provisionné lors de la fabrication. Le back-end vérifie le certificat de l'équipement avant d'accepter ses données.

Connexions aux bases de données

PostgreSQL, MySQL et MongoDB prennent en charge mTLS pour l'authentification des clients. Les applications prouvent leur identité par certificat plutôt que par mot de passe de base de données, ce qui réduit le risque de fuite d'identifiants dans les fichiers de configuration.

Exigences clés

Distribution des certificats à grande échelle

Chaque client doit disposer d'un certificat et d'une clé privée uniques. Distribuer, installer et configurer des certificats sur des centaines de services ou des milliers d'équipements représente un défi opérationnel majeur. Sans automatisation, cela devient un goulot d'étranglement qui ralentit les déploiements.

Pannes liées à l'expiration

Quand un certificat client expire, le handshake mTLS échoue et le service devient totalement injoignable. Contrairement à un navigateur web qui peut afficher un avertissement, les clients d'API reçoivent simplement une erreur de connexion. Avec des durées de vie de certificats plus courtes, les pannes par expiration deviennent bien plus probables sans renouvellement automatisé.

Gestion du magasin de confiance

Chaque serveur doit être configuré avec les certificats de CA appropriés. Si vous ajoutez une nouvelle CA émettrice ou faites tourner votre CA intermédiaire, vous devez mettre à jour le magasin de confiance de chaque serveur qui accepte des certificats client. Oublier un seul serveur provoque des échecs de connexion pour les clients utilisant la nouvelle CA.

Difficulté de débogage

Les échecs mTLS sont notoirement difficiles à déboguer. Les messages d'erreur sont souvent cryptiques (`tlsv1 alert unknown ca`) et n'indiquent pas si le problème est un certificat expiré, un intermédiaire manquant, une mauvaise configuration du magasin de confiance ou une clé qui ne correspond pas. De bons journaux et une supervision des certificats sont indispensables.

Surcoût en performance

mTLS ajoute une vérification de certificat supplémentaire par connexion, par rapport au TLS standard. Pour des connexions fréquentes et de courte durée, cela peut ajouter une latence mesurable. Utilisez le regroupement de connexions, la reprise de session TLS et envisagez des certificats ECDSA (plus petits et plus rapides à vérifier que RSA) pour limiter l'impact.

Comparaison

Méthode	Force	Faiblesse
mTLS	Identité cryptographique, résistant au phishing, pas de secret partagé	Complexité du cycle de vie des certificats
Clés d'API	Simple à mettre en œuvre	Secret partagé, pas de chiffrement, facilement divulgué
OAuth 2.0 / JWT	Flexible, autorisation déléguée	Vol de jeton, nécessite une infrastructure de jetons
Liste blanche d'IP	Aucune surcharge	Pas d'identité, usurpable, ne fonctionne pas avec des IP dynamiques

Bonne pratique : utilisez mTLS pour l'authentification entre services (l'identité au niveau du transport) et complétez-le par OAuth/JWT pour l'autorisation (ce que le service est habilité à faire). Cela offre une défense en profondeur : même si un jeton est dérobé, il ne peut pas être utilisé sans le certificat client correspondant.

Evertrust & mTLS : authentification TLS mutuelle

Émission automatisée des certificats client — Evertrust PKI émet des certificats client via ACME, EST et des API REST. Les services et les équipements peuvent demander et renouveler automatiquement leurs certificats mTLS, ce qui élimine la distribution manuelle des certificats.

Visibilité complète sur mTLS — Evertrust CLM découvre et surveille tous les certificats client et serveur de vos déploiements mTLS. Recevez des alertes avant l'expiration d'un certificat, et évitez les échecs de connexion mTLS si difficiles à diagnostiquer.

PKI privée pour le Zero Trust — Bâtissez l'ensemble de votre infrastructure mTLS sur la PKI privée d'Evertrust. Émettez certificats serveur, certificats client et identités de charges de travail depuis une hiérarchie de confiance unique, avec des politiques cohérentes et une piste d'audit complète.

PKI

CLM

Cas d'usage

Secteurs

Conformité

Apprendre

Outils & Analyses

Événements & Communauté