Histórico de mensagens sobre mtls

eu acho que faz mais sentido o nome ser x-mtls-bypass. se o padrão é checar, o bypass é que deve ser sinalizado (e setado true) e não usar um valor "false" pra negar o que é padrão

Integrador precisa validar por exemplo se o webhook é de test ou transacional para enviar o x-mtls-check da forma correta.

O BACEN parece bem propenso a continuar com mTLS no webhook na v2. Porém, parece haver espaço para na v3 simplificar as webhook para notificação apenas, e aí em algo que só tenha notificação, se quem mandou o aviso foi o PSP ou o Gasparzinho, dá na mesma.

e se o BACEN resolver tornar o mTLS opcional (vai que....) o lado que recebe o callback vai poder dar o bypass de forma mais fácil do que alterando o script que consome a API

isso dá mais flexibilidade pra um integrador que recebe os webhooks de ligar/desligar o mTLS bypass sem interferência no script que tá fazendo o envio do PUT

hoje:
- GN envia "callback" simulado sem certificado (se for aceito pelo integrador, é uma falha; dá "break" aqui)
- GN envia "callback" simulado com certificado (que deve retornar 200)

poderia ficar assim:
- GN envia "callback" simuilado sem certificado:
--> se receber de volta 200 + um header x-mtls-bypass: true, tá ok e dá break;
--> se receber de volta 200 sem o header, é falha e dá break;
--> se receber de volta 4xx, segue adiante
- GN envia "callback" simulado com certificado (que deve retornar 200)

Pelo que entendi o fluxo seria:
PUT /webhook
Headers:["x-mtls-check": false]
----
Webhook de teste é enviado sem certificado e configurado normalmente.
---
Webhook normal é enviado com o certificado.

assim poderia ao menos testar se responde 200 sem o mTLS

a proposta da GN é passar o header x-mtls-check: false na hora de fazer o PUT /webhook. esse header poderia ser enviado pelo servidor/script que recebe os callbacks

Aliás, exceto na parte de mTLS, este teste é muito bom para dar sugestões de melhorias de TLS:
https://www.ssllabs.com/ssltest/
E este guia da Mozilla muito instrutivo:
https://wiki.mozilla.org/Security/Server_Side_TLS

Eu não entendi o raciocínio. Se na hora da notificação eu tenho que validar o mTLS de qualquer forma, melhor que a validação aconteça no cadastro da URL, mesmo, como está hoje. É um benefício gigante eu não precisar gerar o acionamento de webhooks pra saber se a configuração tá correta!

Espera-se que sim. Ele vai conseguir cadastrar a URL. Quando for notificado, nós enviaremos o certificado. Isso abre caminhos para que o integador decida como validar que a requisição que está chegando é realmente da Gerencianet. Talvez ele não possa alterar uma configuração do nginx por estar sendo compartilhado com outras aplicações, porém talvez ele possa "ensinar" o nginx a repassar essa informação pra dentro da aplicação e validar manualmente via código.

A ideia da validação durante o PUT é pra ajudar a validar o ambiente mTLS, não seria, digamos, mandatória.

Desabilitar o check mas ainda exigir mTLS nas efetivas notificações ajuda em algo o integrador com problemas em ambientes compartilhados ?

<@!793123559874494465> poderia dissertar melhor sobre isso: "- Permitir o cadastro da URL no PUT /webhooks sem validação ativa do mTLS no momento do consumo;"?

sslOptions = {
key: fs.readFileSync('./ssl/ssls/pixblack_in.pem'),
cert: fs.readFileSync('./ssl/ssls/pixblack.in.crt'),
ca: fs.readFileSync('./ssl/ssls/chain-pix-prod.crt'),
minVersion: 'TLSv1.2', // força o uso de TLS da versão 1.2 para cima
requestCert: true, // força que o cliente envie um certificado de cliente (mtls)
rejectUnauthorized: false // rejeita clientes que não enviarem certificados válidos
};

Sim, outra vantagem é que não exige nenhuma outra configuração no mTLS, quem já está integrado não quebrará.

vai fazer a checagem do mtls novamente?

Mas como você precisa decidir qual certificado apresentar para a sessão mTLS, é melhor ter algo na URI que diferencie para que você possa mostrar o certificado correto.

Como alguém vai responder num endereço "/pix"? além do requisito do mTLS que já está complicando a vida de muitos ai... agora será preciso ter algum tipo de rewrite para poder servir essa página de modo dinâmico

Bom dia Branco! No momento sim, pois, servidores compartilhados não permitem que o cliente faça a inclusão de nosso CA e sem o mesmo o mTLS não ocorre, impossibilitando o cadastro do webhook. Mas estamos discutindo outras formas de contornar essa situação para os clientes que tem servidores compartilhados.