mTLS

Definição

O mTLS (mutual TLS) é uma variante bidirecional do TLS: o cliente também apresenta um certificado, ao passo que o TLS clássico autentica apenas o servidor.

Na DSP2, é o mecanismo que permite a um banco (ASPSP) reconhecer com certeza o TPP (AISP, PISP, CBPII) que chama sua API, por meio do certificado QWAC apresentado durante o handshake.

TLS clássico vs mTLS

Uma conexão HTTPS clássica autentica apenas o servidor: https://meubanco.com.br apresenta seu certificado, o navegador o valida e a conexão é cifrada — mas o servidor não sabe quem você é no nível do TLS.

Com o mTLS, o cliente também precisa provar sua identidade: o servidor solicita um certificado de cliente, o TPP apresenta seu QWAC e o servidor o verifica (validade, revogação, papéis PSD2) antes de aceitar a conexão. Resultado: antes mesmo da primeira requisição HTTP, o banco já sabe com qual TPP está falando.

Por que o mTLS para a DSP2

• Identificação certeira por meio de um certificado eIDAS qualificado (QWAC), e não uma simples chave de API.
• Resistência ao phishing: sem a chave privada, é impossível se passar por um TPP.
• Verificação dos papéis: o banco inspeciona os papéis PSD2 já no handshake e interrompe se o papel não corresponder ao endpoint.
• Padrão maduro: suportado nativamente pelos servidores web (nginx, Apache, Envoy, AWS ALB) e pelos clientes HTTP.

O que o mTLS não faz

• Não assina a requisição HTTP: esse é o papel do QSealC. O mTLS protege o tubo, não o conteúdo.
• Não autentica o PSU: isso é a SCA. O mTLS autentica o TPP, não o seu usuário.
• Não sobrevive a um proxy que encerra o TLS: um load balancer, WAF ou CDN que descriptografa o TLS perde o certificado de cliente — o erro de arquitetura mais frequente.
• Não dispensa o tratamento de erros: um QWAC expirado, revogado ou com o papel errado faz o handshake falhar sem mensagem HTTP — é preciso monitorar os logs TCP/TLS.

No ecossistema PSD2

O mTLS é a primeira barreira do lado do ASPSP: enquanto o handshake não tiver sucesso, nenhuma requisição HTTP é aceita e, portanto, nenhuma lógica de aplicação (consentimento, pagamento, leitura) é executada.

Exemplos concretos

• Arquitetura fintech: o QWAC deve ser apresentado pelo backend que chama o banco. Com um API gateway no meio, ou ele faz passthrough TLS (o backend cuida do mTLS), ou reabre a conexão com o seu próprio QWAC — nunca um load balancer não configurado entre os dois.
• Testes: curl --cert qwac.pem --key qwac.key https://api.banque.fr/accounts valida um QWAC antes de subir toda a stack.
• Armadilhas clássicas: cipher suites impostas pelo banco (TLS 1.2 ECDHE/RSA-AES-GCM), cadeia de certificação incompleta (esquecimento da CA intermediária), SNI preciso exigido no ClientHello.
• Do lado do ASPSP: o erro frequente é encerrar o TLS cedo demais (reverse proxy frontal), o que perde o QWAC — solução: encaminhar o certificado de cliente em um header assinado, com cautela.
• Custo operacional: monitorar a expiração dos QWAC (alertas em D-30, D-15, D-7), automatizar a rotação quando o TSP permitir e acompanhar a revogação (CRL/OCSP) para evitar uma interrupção silenciosa.