Une connexion TLS standard chiffre le trafic mais ne prouve pas, dans la plupart des scénarios, qui est réellement le client. Les mots de passe, les clés API, les listes d'autorisation IP et les contrôles basés sur les tokens ajoutent des couches de sécurité, mais ils peuvent être partagés, fuités, copiés ou utilisés dans le mauvais contexte. mTLS, en revanche, vérifie que le client détient la clé privée, produisant un signal d'identité plus fort au niveau de la connexion.
Dans les API B2B, les flux de paiement, le partage de données de santé, le trafic de dispositifs IoT et l'accès aux interfaces de gestion, cette différence est critique. Chaque partenaire, dispositif ou administrateur arrive avec son propre certificat ; la durée de vie du certificat, la chaîne CA, le CN, l'empreinte et le résultat de vérification sont tous auditables. Cependant, exiger que chaque application parse ces informations indépendamment ajoute de la complexité opérationnelle.
Dans les déploiements mTLS traditionnels, la gestion des bundles CA, la sélection du mode de vérification, les codes d'erreur, l'extraction des champs du certificat et la transmission de ces informations à l'application sont des préoccupations fragmentées. Un environnement peut nécessiter un certificat obligatoire tandis qu'un autre a besoin du mode optional lors d'une transition. Les chaînes CA legacy, les certificats de test et les migrations de partenaires exigent tous un équilibre fin entre validation stricte et tolérance maîtrisée.
La bonne approche est de gérer mTLS comme un profil de service. Le mode de vérification, le fichier CA, la stratégie d'erreur CA, la transmission des champs du certificat au backend et les politiques d'accès conditionnel AAM doivent tous résider dans le même modèle.
TR7 TLS / mTLS Client-Cert Authentication délivre ce modèle : il extrait le certificat client du contrôle au niveau connexion et le transforme en objet d'identité utilisable pour les services backend et les politiques d'accès.
TR7 applique la vérification mTLS conjointement avec le mode de vérification par service, la gestion de CA, la transmission des champs du certificat et la politique d'accès AAM dans un seul modèle cohérent.
Avec les modes none, optional et required, chaque service peut appliquer sa propre politique mTLS. Les certificats peuvent être rendus obligatoires, maintenus optionnels lors d'une transition, ou désactivés entièrement pour un service donné.
Le code de vérification, l'empreinte SHA1, le CN et les champs supplémentaires du certificat peuvent être mappés à des headers HTTP. Le backend lit les informations d'identité directement sans parser le certificat lui-même.
Les headers du certificat peuvent être parsés en champs tels que present, verified, verify, sha1 et cn. Même lorsque la vérification échoue, les données du certificat peuvent être journalisées et transmises au moteur de décision de manière maîtrisée.
Les erreurs de validation CA peuvent être rejetées entièrement, tolérées globalement lors d'une transition, ou relaxées uniquement pour des codes d'erreur spécifiques. Cela permet aux politiques de staging, de migration de partenaires et de production de coexister dans le même modèle mTLS.
TLS / mTLS Client-Cert Authentication vérifie, parse, journalise et partage le certificat client avec le backend — tout à la périphérie.
TR7 gère le comportement d'authentification par certificat client indépendamment pour chaque service. En mode none, aucun certificat n'est demandé. En mode optional, un certificat est parsé s'il est présenté ; s'il est absent, la connexion peut continuer. En mode required, toute connexion sans certificat est rejetée. Cette structure offre une sécurité stricte en production, de la flexibilité en staging et un déploiement progressif lors de la migration. Différents services sur la même plateforme peuvent imposer des exigences mTLS différentes.
TR7 peut valider les certificats clients par rapport à des fichiers CA par service. La chaîne CA du Partenaire A peut être utilisée sur un service tandis que la chaîne du Partenaire B est appliquée à un autre. Cette séparation permet de gérer différents partenaires commerciaux ou groupes de dispositifs en isolation sur le même ADC, sans dépendre d'une seule liste CA globale. Une racine de confiance distincte est définie par service.
TR7 peut délivrer le statut de vérification du certificat client au backend via des headers tels que x-ssl-verify. La vérification réussie, l'absence de certificat ou un échec de vérification spécifique est visible pour l'application. Le backend peut prendre des décisions basées sur le statut mTLS de la connexion sans avoir à gérer la pile TLS ou le parsing du certificat.
TR7 peut extraire le Common Name et l'empreinte SHA1 du certificat client et les transmettre en headers au backend. Le CN peut servir d'identifiant de partenaire, de dispositif, d'utilisateur ou de service. L'empreinte SHA1 offre une clé pratique pour les scénarios de liste d'autorisation, d'audit, de correspondance ou de révocation rapide. Les empreintes sont normalisées de sorte que différents styles de formatage ne produisent pas de valeurs d'identité différentes.
caErrorStrategy permet différentes réponses aux échecs de validation CA. ignoreAll peut tolérer toutes les erreurs CA dans des scénarios temporaires de débogage ou de migration ; manualIgnoreList limite la tolérance à des codes d'erreur de validation spécifiques. En production, cette flexibilité peut être désactivée pour imposer une tolérance zéro. Le modèle crée un équilibre maîtrisé entre sécurité stricte et besoins réels de migration.
TR7 ne demande pas seulement des certificats aux clients entrants — il peut également présenter un certificat client lors de la connexion à un service backend. La connexion côté backend peut être configurée avec vérification requise, un fichier CA et un certificat client ADC. Cela permet des politiques de confiance TLS indépendantes sur les deux segments client-vers-TR7 et TR7-vers-backend. Le trafic peut être inspecté à la périphérie tandis que la connexion interne reste entièrement sécurisée.
Un certificat client est un signal d'identité fort, mais il n'a pas besoin de porter seul la décision d'accès complète. TR7 peut utiliser les données du certificat comme l'une des entrées des politiques d'accès conditionnel AAM. Le certificat, l'adresse IP, la posture du dispositif, le groupe d'utilisateurs, l'heure de la journée et le statut MFA peuvent tous être évalués ensemble. mTLS devient un composant d'une décision d'accès zero-trust plus large.
Une vérification de certificat réussie ne rend pas automatiquement une requête sûre — les contrôles de contenu et de volume continuent de s'appliquer. TR7 exécute la couche d'identité mTLS conjointement avec WAAP, DDoS et l'analyse du comportement des bots. mTLS établit qui est le client ; WAAP évalue ce que fait la requête ; la couche DDoS évalue le volume du trafic. Les trois contrôles peuvent opérer ensemble devant le même service.
En mode optional, les partenaires qui présentent un certificat sont traités avec l'identité mTLS tandis que les clients dont la migration de certificat n'est pas encore complète peuvent basculer vers un mécanisme d'authentification alternatif. Ce pattern permet aux grandes migrations B2B de se déployer en toute sécurité sans forcer tous les partenaires à adopter mTLS le même jour. Le backend peut distinguer entre les flux basés sur certificat et les flux basés sur clé API grâce à la présence du header x-ssl-verify. Une fois la migration terminée, le service peut être déplacé en mode required.
Pour les connexions mTLS, des champs tels que le sujet du certificat, l'émetteur, la fenêtre de validité, le résultat de vérification et l'empreinte peuvent être journalisés. Dans un SIEM, il devient clair quel partenaire a accédé à quel service avec quel certificat. Des événements tels que expiré, auto-signé ou échec d'émetteur peuvent être analysés séparément. Ces enregistrements produisent une piste d'audit solide pour la conformité, l'investigation des incidents et l'audit des partenaires.
L'opération mTLS est couverte de bout en bout : comportement de bind, codes de vérification, détection de certificat par header, normalisation de l'empreinte, portée du fichier CA et validation SNI/Host.
Le comportement de vérification none, optional ou required est défini au point d'entrée du service. En mode required, une connexion client qui ne présente aucun certificat est rejetée. En mode optional, un certificat est parsé s'il est présent ; s'il est absent, la requête peut continuer vers un flux de politique alternatif.
Le résultat de vérification du certificat peut être exprimé comme un code d'erreur numérique. Zéro représente une vérification réussie ; d'autres valeurs indiquent des conditions telles qu'émetteur non trouvé, certificat expiré, certificat pas encore valide ou certificat auto-signé. Cette valeur peut être transmise au backend en header.
Si x-ssl-verify est vide ou indique qu'aucun certificat n'a été utilisé, le client est traité comme n'ayant présenté aucun certificat. Une valeur de 0 signifie que le certificat a été vérifié avec succès. Toute autre valeur signifie que les données du certificat peuvent être présentes mais que la vérification a échoué — cela peut être géré séparément dans les logs et les décisions de politique.
Les valeurs d'empreinte peuvent arriver avec une casse mixte et un formatage séparé par des deux-points. TR7 normalise la valeur de sorte que les opérations de comparaison et de liste d'autorisation fonctionnent de manière cohérente. Le même certificat n'est pas traité comme une identité différente à cause d'une différence de formatage.
Chaque service peut utiliser son propre bundle CA, ce qui permet d'isoler les racines de confiance entre partenaires, groupes de dispositifs et services internes. Les changements de CA doivent être planifiés en tenant compte de l'impact sur le service et doivent être audités.
Sur les services qui utilisent mTLS, la validation SNI et Host peut être activée en plus de la vérification du certificat. Lorsque le certificat, SNI et Host sont évalués ensemble, l'identité de la requête, le domaine cible et l'intention de routage HTTP sont tous validés en combinaison. Ce modèle aide à réduire le risque d'abus de type domain fronting.
Chaque partenaire se connecte à l'API avec un certificat client unique. TR7 journalise les valeurs CN et SHA1, les transmet au backend et simplifie les décisions d'audit et de rate limit par partenaire.
Chaque dispositif peut se connecter à TR7 avec un certificat unique chargé en usine. Le numéro de série du dispositif est porté dans le champ CN, et la liste d'autorisation par empreinte rend plus rapides à gérer les flux de révocation et de restriction d'accès.
Les organisations de santé peuvent utiliser mTLS lors du partage de données avec les systèmes de prestataires pour authentifier au niveau de la connexion. Lorsqu'un certificat expire ou que la vérification échoue, l'accès peut être coupé automatiquement sans aucune intervention manuelle.
Les administrateurs système peuvent se connecter à l'interface de gestion de TR7 en utilisant un certificat client. Combiné avec MFA et la posture du dispositif via AAM, un seul ordinateur portable, un certificat spécifique et une identité d'administrateur vérifiée sont tous confirmés ensemble.
Vérifiez le certificat client à la périphérie, transmettez-le à votre backend et combinez-le avec la politique AAM. Laissez-nous vous guider lors d'une mise en place en direct sur vos propres services.