mTLS

Définition

Le mTLS (mutual TLS) est une variante bidirectionnelle de TLS : le client présente lui aussi un certificat, là où TLS classique n'authentifie que le serveur.

En DSP2, c'est le mécanisme qui permet à une banque (ASPSP) de reconnaître à coup sûr le TPP (AISP, PISP, CBPII) qui appelle son API, via le certificat QWAC présenté lors du handshake.

TLS classique vs mTLS

Une connexion HTTPS classique authentifie le serveur seul : https://mabanque.fr présente son certificat, le navigateur le valide, la connexion est chiffrée — mais le serveur ne sait pas qui vous êtes au niveau TLS.

Avec mTLS, le client doit aussi prouver son identité : le serveur demande un certificat client, le TPP présente son QWAC, et le serveur le vérifie (validité, révocation, rôles PSD2) avant d'accepter la connexion. Résultat : avant même la première requête HTTP, la banque sait à quel TPP elle parle.

Pourquoi le mTLS pour la DSP2

• Identification certaine via un certificat eIDAS qualifié (QWAC), pas une simple clé API.
• Résistance au phishing : sans la clé privée, impossible de se faire passer pour un TPP.
• Vérification des rôles : la banque inspecte les rôles PSD2 dès le handshake et coupe si le rôle ne correspond pas à l'endpoint.
• Standard mature : supporté nativement par les serveurs web (nginx, Apache, Envoy, AWS ALB) et les clients HTTP.

Ce que mTLS ne fait pas

• Ne signe pas la requête HTTP : c'est le rôle du QSealC. mTLS sécurise le tuyau, pas le contenu.
• N'authentifie pas le PSU : c'est la SCA. mTLS authentifie le TPP, pas son utilisateur.
• Ne survit pas à un proxy qui termine TLS : un load balancer, WAF ou CDN qui déchiffre TLS perd le certificat client — l'erreur d'architecture la plus fréquente.
• Ne dispense pas de la gestion d'erreurs : un QWAC expiré, révoqué ou au mauvais rôle fait échouer le handshake sans message HTTP — il faut surveiller les logs TCP/TLS.

Dans l'écosystème PSD2

Le mTLS est la première barrière côté ASPSP : tant que le handshake n'a pas réussi, aucune requête HTTP n'est acceptée, et donc aucune logique applicative (consentement, paiement, lecture) ne s'exécute.

Exemples concrets

• Architecture fintech : le QWAC doit être présenté par le backend qui appelle la banque. Avec un API gateway au milieu, soit il fait du passthrough TLS (le backend gère mTLS), soit il réémet la connexion avec son propre QWAC — jamais un load balancer non configuré entre les deux.
• Tests : curl --cert qwac.pem --key qwac.key https://api.banque.fr/accounts valide un QWAC avant d'embarquer toute la stack.
• Pièges classiques : cipher suites imposées par la banque (TLS 1.2 ECDHE/RSA-AES-GCM), chaîne de certification incomplète (oubli de l'intermediate CA), SNI précis requis dans le ClientHello.
• Côté ASPSP : l'erreur fréquente est de terminer TLS trop tôt (reverse proxy frontal), ce qui perd le QWAC — solution : remonter le certificat client dans un header signé, avec précaution.
• Coût opérationnel : surveiller l'expiration des QWAC (alerting à J-30, J-15, J-7), automatiser la rotation quand le TSP le permet, et suivre la révocation (CRL/OCSP) pour éviter une coupure silencieuse.