mTLS

mTLS

Explication de la marmotte

À l’entrée d’une réunion confidentielle, le gardien montre son badge aux invités, et chaque invité montre aussi le sien au gardien : personne n’entre sans que les deux côtés se soient reconnus. Cette page explique comment des programmes pratiquent cette reconnaissance mutuelle quand ils se parlent, et ce qu’elle coûte à organiser.

→ Lire l’explication complète de la marmotte

Statut

Brouillon editorial.

Objectif

Expliquer pourquoi le mutual TLS est utile entre services, ce qu’il apporte et ce qu’il impose en gouvernance.

Resume

mTLS ajoute l’authentification du client a celle du serveur. Il renforce la confiance machine-a-machine, mais augmente aussi les exigences sur la distribution et le renouvellement des certificats.

Sections prevues

• difference entre TLS serveur et mTLS ;
• cas d’usage applicatifs et inter-services ;
• dependance a une PKI operationnelle ;
• erreurs de deploiement frequentes ;
• place dans une architecture zero trust.

Liens internes utiles

• PKI expliquee
• TLS explique
• Auditer la couverture réelle du mTLS dans un service mesh

A completer pour devenir page de reference

• ajouter un schema client / serveur
• ajouter un exemple de chaine de confiance
• ajouter une FAQ
• ajouter les sources

🐝 Ce qui arrive si on s’en passe

Sans authentification du client, le serveur accepte toute connexion chiffrée venue de n’importe quelle machine capable de joindre son port : le chiffrement protège alors la conversation, pas le choix de l’interlocuteur. Dans un réseau interne, une machine compromise peut appeler tous les services qu’elle atteint, et les journaux n’enregistrent qu’une adresse réseau, réattribuable et usurpable, en guise d’identité. Le contrôle d’accès retombe sur des secrets partagés copiés dans des configurations, sans échéance naturelle. À l’inverse, un déploiement mutuel sans gestion du renouvellement remplace l’intrusion par la panne : un certificat expiré coupe le service aussi sûrement qu’un attaquant, et avec moins de discrétion.

🦫 Explication de la marmotte 🍫

Quand un navigateur se connecte à un site sécurisé, le protocole TLS, qui chiffre les échanges sur le réseau, demande au serveur de présenter un certificat : un document électronique signé par une autorité reconnue, qui prouve que le serveur possède bien le nom annoncé. Le client vérifie ce certificat, mais ne prouve rien lui-même sur son identité. Le TLS mutuel, abrégé mTLS, ajoute la démarche inverse : le serveur réclame aussi un certificat au client. Chaque côté vérifie que le certificat de l’autre a été signé par une autorité en laquelle il a confiance, qu’il n’a pas expiré, et que l’autre possède bien la clé secrète correspondante, en lui faisant signer une donnée pendant l’échange. Si une vérification échoue, la connexion est refusée avant tout échange de données. Ce mécanisme sert surtout entre programmes, par exemple entre deux services d’une même application, qui s’identifient ainsi sans mot de passe. Il suppose une infrastructure à clés publiques, c’est-à-dire un ensemble d’outils et de règles capable de fabriquer, distribuer, renouveler et révoquer beaucoup de certificats. Si un certificat expire sans être renouvelé, le service concerné ne peut plus se connecter, et c’est une panne. Dans une architecture dite zéro confiance, où aucun réseau n’est considéré comme sûr par défaut, chaque connexion est ainsi authentifiée des deux côtés.

À lire aussi

• EST : enrôler des certificats X.509 par transport sécuriséComprendre EST (Enrollment over Secure Transport, RFC 7030) : comment un client obtient, renouvelle et fait générer ses certificats X.509 sur un canal TLS, et ce qui le distingue de SCEP.
• Authentifier une API B2B hors annuaire interneChoisir, exploiter et révoquer les mécanismes d’authentification et d’autorisation pour les flux EDI et API B2B entre organisations.
• Partage de données inter-organisations par APIPartager des données entre organisations exige des contrats exécutables, des API limitées et une confiance technique strictement bornée.
• Cycle de vie d'une autorité de certification intermédiaireÉmettre, renouveler et révoquer en cascade une autorité de certification intermédiaire, avec les extensions, les échéances et les pièges d'exploitation qui font tomber une PKI entière.

Pages voisines

La citent

• Certificats de courte durée
• Choisir ECDSA, EdDSA ou RSA pour un certificat TLS
• Construire une autorité de certification privée interne
• Conteneurs, Kubernetes, CNI et service mesh
• CRL ou OCSP pour révoquer un certificat
• Diagnostiquer les erreurs de validation TLS en production
• Extensions X.509 v3 Key Usage EKU et Basic Constraints

mTLS

Elle cite

• ⇄Lien dans les deux sens :Comprendre TLS : mécanismes, garanties et limites
• ⇄Lien dans les deux sens :Gestion du cycle de vie des certificats à grande échelle
• ⇄Lien dans les deux sens :PKI expliquee
• Auditer la couverture réelle du mTLS service mesh
• Gestion des secrets applicatifs distribués avec rotation

⇄ : les deux pages se citent l’une l’autre.