Histórico de mensagens sobre mtls

E não seguir o mTLS é uma violação bem evidente na postura de segurança, mesmo não sendo a única.

Não é só o mTLS que o PSP precisa avaliar do EC, é toda a postura de segurança.

<@!780500321994539068> o manual de segurança diz que o callback deve ser enviado por canal mTLS. mas como o PSP pode garantir que o canal é mTLS? não existe isso. ele envia com certificado e o cliente verifica se ele quiser. não tem como a GN saber se o cliente tá validando.

não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").

voce conseguiu configurar essa questão do mtls usando o node?

Não flexibilizaram. Os acionamentos continuam exigindo mTLS.

Pq flexibilizaram essa questão do mtls? Não era uma exigência do BACEN?

obrigado pela resposta, me tira uma duvida, essa necessidade do mtls foi retirada a pouco tempo? lembro de ter lido aqui a alguns dias que era necessario

para os 2 ambientes. o nome certo do header é x-skip-mtls-checking (está errado no postman)

x-mtls-bypass

Sim <@!673655288204754953> , você deve inserir o nosso CA para que ocorra o mTLS. É geral, você encontra o CA em ambiente de homologação e o de produção aqui (https://dev.gerencianet.com.br/docs/api-pix#section-webhook)

Pessoal, falei mais cedo aqui no canal que testaria uma abordagem do mTLS com o API Gateway da AWS. Deu certo e é super simples de fazer.

https://aws.amazon.com/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/

Isso mesmo, <@!788954143658082304>. Significa que foi validado seu mTLS.
Você pode dar um GET /v2/webhook/:chave para verificar se seu webhook foi registrado para sua chave

<@!652133922582560793> <@!775350441965649951> <@!671763456487325717> podem me ajudar com essa questão? Se eu mandei um PUT para criação do webhook e recebi 200 significa que a gerencianet conseguiu validar o mTLS certinho ou é feita uma verificação async?

Blz. Vou seguir com os testes do mTLS aqui. Em teoria se o PUT retornar sucesso, significa que a gerencianet conseguiu fazer o handshake com meu server usando o mTLS, certo?

ou ainda uma terceira opção: usar o mTLS proxy do pix.ae ^_^ , veja lá no <#💻devs>

Bom dia pessoal! Ainda sobre essa questão.
Eu consegui contornar criando um arquivo .php independente, em outro vhost, embora usando o "mesmo arquivo .conf", alterando apenas o subdominio. A conclusão que cheguei, foi a de que, por meu projeto original ser um framework (laravel), o mesmo se utiliza de arquivos .htaccess pra obfuscar a URL. e de alguma forma, isso interfere no processo de handshake da autenticacão mútua.

Então: Criei outro vhost, com certificado proprio no subdominio, recebendo o POST do webhook da GN, e retransmitindo para meu app principal via requisição post. Isso é provisório enquanto descubro o "ponto de falha" entre o framework e o protocolo mTLS.

Blz. Alguém já usou o mTLS com o API Gateway da AWS ?

ou funcionam, mas nao usam o mTLS?

Bom dia, pessoal. Como eu faço para testar a questão do mTLS em ambiente de desenvolvimento? Preciso acionar alguém da gerencianet para enviar uma requisição manualmente?