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.