# mTLS

> mutual TLS

Two-way TLS: the client presents a certificate to the server, just as the server presents one to the client. This is the mechanism that lets a bank recognise a TPP on every call.

_Category: securite_

---

## Definition

**mTLS** (_mutual TLS_) is a two-way variant of TLS: the client also presents a certificate, whereas standard TLS authenticates only the server.

In PSD2, it is the mechanism that lets a bank (ASPSP) reliably recognise the TPP (AISP, PISP, CBPII) calling its API, via the QWAC certificate presented during the handshake.

## Standard TLS vs mTLS

A standard HTTPS connection authenticates only the server: `https://mybank.com` presents its certificate, the browser validates it, the connection is encrypted — but the server does not know who you are at the TLS level.

With mTLS, the client must also prove its identity: the server requests a client certificate, the TPP presents its QWAC, and the server verifies it (validity, revocation, PSD2 roles) before accepting the connection. The result: even before the first HTTP request, the bank knows which TPP it is talking to.

## Why mTLS for PSD2

- **Reliable identification** through a qualified eIDAS certificate (QWAC), not a mere API key.
- **Phishing resistance**: without the private key, it is impossible to impersonate a TPP.
- **Role verification**: the bank inspects the PSD2 roles right from the handshake and cuts off if the role does not match the endpoint.
- **Mature standard**: natively supported by web servers (nginx, Apache, Envoy, AWS ALB) and HTTP clients.

## What mTLS does not do

- **Does not sign the HTTP request**: that is the QSealC's job. mTLS secures the pipe, not the content.
- **Does not authenticate the PSU**: that is SCA. mTLS authenticates the TPP, not its user.
- **Does not survive a proxy that terminates TLS**: a load balancer, WAF or CDN that decrypts TLS loses the client certificate — the most common architecture mistake.
- **Does not remove the need for error handling**: an expired, revoked or wrong-role QWAC fails the handshake with no HTTP message — you have to monitor the TCP/TLS logs.

## In the PSD2 ecosystem

mTLS is the first barrier on the ASPSP side: until the handshake succeeds, no HTTP request is accepted, and so no application logic (consent, payment, read) runs.

```mermaid
sequenceDiagram
    participant TPP as TPP
    participant ASPSP as ASPSP

    Note over TPP,ASPSP: mTLS handshake
    TPP->>ASPSP: 1. ClientHello
    ASPSP->>TPP: 2. ServerHello + server cert
    ASPSP->>TPP: 3. CertificateRequest
    TPP->>ASPSP: 4. Presents QWAC
    ASPSP->>ASPSP: 5. Verifies QWAC<br/>(validity, CRL, PSD2 roles)

    alt QWAC valid + role OK
        ASPSP->>TPP: 6. Connection accepted
        Note over TPP,ASPSP: Signed HTTP exchange (QSealC)
        TPP->>ASPSP: GET /accounts + Signature
        ASPSP->>TPP: 200 OK + data
    else QWAC invalid or role KO
        ASPSP->>TPP: Handshake rejected
    end
```

## Concrete examples

- **Fintech architecture**: the QWAC must be presented by the backend that calls the bank. With an API gateway in the middle, it either does TLS passthrough (the backend handles mTLS) or re-establishes the connection with its own QWAC — never an unconfigured load balancer between the two.
- **Testing**: `curl --cert qwac.pem --key qwac.key https://api.banque.fr/accounts` validates a QWAC before bringing up the whole stack.
- **Classic pitfalls**: cipher suites mandated by the bank (TLS 1.2 ECDHE/RSA-AES-GCM), an incomplete certification chain (forgetting the intermediate CA), a precise SNI required in the ClientHello.
- **ASPSP side**: the frequent mistake is terminating TLS too early (front-end reverse proxy), which loses the QWAC — the fix: forward the client certificate in a signed header, carefully.
- **Operational cost**: monitor QWAC expiry (alerting at T-30, T-15, T-7), automate rotation when the TSP allows it, and track revocation (CRL/OCSP) to avoid a silent outage.

## Sources

- [RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication](https://datatracker.ietf.org/doc/html/rfc8705) — IETF, 2020-02
- [Regulatory Technical Standards on strong customer authentication and common and secure communication](https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money/regulatory-technical-standards-on-strong-customer-authentication-and-secure-communication-under-psd2) — European Banking Authority
- [ETSI TS 119 495 — Sector Specific Requirements (PSD2 QWAC/QSealC)](https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/) — ETSI

---

Source: https://openfinanceguide.com/en/glossary/mtls