Histórico de mensagens

Por ser uma determinação do BACEN todos os PSPs tem que cumprir esse padrão

como a comunicação webhook (GN -> cliente) é privada, não vejo sentido na exigência de validar a entidade certificadora. acho que o BACEN viajou nessa 😦

Mesmo que o certificado possa ser enviado, a autoridade certificadora que o emitiu precisa ser validada pela GN. Senão seria aceito certificado auto-assinado ou equivalente, violando o manual de segurança.

Com certeza, vai facilitar para os integradores. A determinação do banco central precisa ser seguida de qualquer forma, com o padrão mTLS, mas outras formas sugeridas pela própria comunidade e que atendam aos requisitos podem ser implementadas.

vou te mandar uma msg privada

isso talvez até permita um nível menor de interação humana (pode ter uma configuração no painel da conta pra enviar o certificado)

ele só vai funcionar se vc seguir os 3 passos acima, e passar o certificado criado no passo 2 para a GN (e eles concordarem em usar esse certificado em vez do certificado que eles te passaram)

Podemos levar essa sugestão de implementação para a nossa equipe, guardando o certificado gerado por vocês e exigindo o mesmo para a comunicação. Mas no momento o que está valendo é o nosso CA, você deve configurar o mesmo em seu VirtualHost para ter o hand-shake.

Estou com este mTLS ativo da cloudflare desde o dia 23 de Nov, porém ele não serve para nada 😦

Te respondendo, o nosso aplicativo gera atualmente apenas com QRCode estático. O Pix com QRCode dinâmico é feito consumindo nossa API-Pix

na comunicação com a API, quem escolhe o arquivo de certificado sou eu. aí tanto faz quem emitiu, raízes, etc, a implantação é igual. mas só a CA não é suficiente no caso dos webhooks. pq o CF vai ter que validar o certificado específico na hora que receber o callback no hostname

É algo que podemos sim conversar e avaliar as demais opções, estamos sempre abertos às possibilidades de melhorar nossa estrutura

No caso do certificado, para facilitar a emissão e manutenção, uma vez que nem todos dispõem de recursos para tal, optamos pela geração dos certificados

<@!779016309383364698> como conversado no privado, vamos analisar a possibilidade de disponibilizar esse endpoint. Obrigada pela sugestão!

Segunda ta corrida <@!440035527127990273> , mas estamos por aqui sim

estou sentindo falta da participação do pessoal da GN hoje aqui

passo 1: https://developers.cloudflare.com/ssl/client-certificates/enable-mtls
passo 2: https://developers.cloudflare.com/ssl/client-certificates/create-a-client-certificate
passo 3: https://developers.cloudflare.com/firewall/cf-dashboard/create-api-shield-rule#use-the-api-shield-rule-interface

Um meio-termo que já vi empregado em alguns sistemas foi ter algumas raízes autorizadas, e algumas eram de CAs reconhecidas... mas implementar uma trust-store extensa como a das browsers aí já parece meio over. Então vale explorar com eles a idéia de essa CA específica da Cloudflare ser aceita além de uma CA interna da GN.

isso abriria a possibilidade de integrações mais facilitadas pra quem tá em hospedagem compartilhada

aí eu poderia enviar o certificado para a GN e aplicar a regra de firewall no API Shield da Cloudflare pra rejeitar as conexões sem o certificado