Histórico de mensagens sobre mtls em pix

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?

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

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