mTLS

Definición

El mTLS (mutual TLS) es una variante bidireccional de TLS: el cliente también presenta un certificado, mientras que el TLS clásico solo autentica al servidor.

En la DSP2 es el mecanismo que permite a un banco (ASPSP) reconocer con certeza al TPP (AISP, PISP, CBPII) que llama a su API, mediante el certificado QWAC presentado durante el handshake.

TLS clásico vs mTLS

Una conexión HTTPS clásica autentica solo al servidor: https://mibanco.es presenta su certificado, el navegador lo valida y la conexión se cifra — pero el servidor no sabe quién es usted a nivel de TLS.

Con mTLS, el cliente también debe demostrar su identidad: el servidor solicita un certificado de cliente, el TPP presenta su QWAC y el servidor lo verifica (validez, revocación, roles PSD2) antes de aceptar la conexión. Resultado: incluso antes de la primera petición HTTP, el banco sabe con qué TPP está hablando.

Por qué el mTLS para la DSP2

Identificación certera mediante un certificado eIDAS cualificado (QWAC), no una simple clave de API.
Resistencia al phishing: sin la clave privada, es imposible hacerse pasar por un TPP.
Verificación de los roles: el banco inspecciona los roles PSD2 desde el handshake y corta si el rol no corresponde al endpoint.
Estándar maduro: soportado de forma nativa por los servidores web (nginx, Apache, Envoy, AWS ALB) y los clientes HTTP.

Lo que el mTLS no hace

No firma la petición HTTP: ese es el papel del QSealC. El mTLS asegura la tubería, no el contenido.
No autentica al PSU: eso es la SCA. El mTLS autentica al TPP, no a su usuario.
No sobrevive a un proxy que termina el TLS: un balanceador de carga, WAF o CDN que descifra el TLS pierde el certificado de cliente — el error de arquitectura más frecuente.
No exime de la gestión de errores: un QWAC caducado, revocado o con el rol equivocado hace fallar el handshake sin mensaje HTTP — hay que vigilar los logs TCP/TLS.

En el ecosistema PSD2

El mTLS es la primera barrera del lado del ASPSP: mientras el handshake no haya tenido éxito, no se acepta ninguna petición HTTP y, por tanto, no se ejecuta ninguna lógica de aplicación (consentimiento, pago, lectura).

Ejemplos concretos

Arquitectura fintech: el QWAC debe ser presentado por el backend que llama al banco. Con un API gateway en medio, o bien hace passthrough TLS (el backend gestiona el mTLS), o bien reabre la conexión con su propio QWAC — nunca un balanceador de carga sin configurar entre ambos.
Pruebas: curl --cert qwac.pem --key qwac.key https://api.banque.fr/accounts valida un QWAC antes de levantar toda la stack.
Trampas clásicas: cipher suites impuestas por el banco (TLS 1.2 ECDHE/RSA-AES-GCM), cadena de certificación incompleta (olvido de la CA intermedia), SNI preciso requerido en el ClientHello.
Del lado del ASPSP: el error frecuente es terminar el TLS demasiado pronto (reverse proxy frontal), lo que pierde el QWAC — solución: transmitir el certificado de cliente en una cabecera firmada, con precaución.
Coste operativo: vigilar la caducidad de los QWAC (alertas a D-30, D-15, D-7), automatizar la rotación cuando el TSP lo permita y seguir la revocación (CRL/OCSP) para evitar un corte silencioso.