Histórico de mensagens sobre mtls

O mtls.pix.ae é do <@!440035527127990273> .

Então, eu não sei como tu fez a configuração nesse caso do servidor que responde pelo mtls.pix.ae, mas sim, você deveria responder com o 403 nesse servidor caso viesse sem certificado, e se viesse, o servidor deveria validar a CA usando o certificado que a gerencianet emitiu pra você, ai sim ele enviaria pro seu backend cardapio-api.heroku...

no Seu caso seria o mtls.pix.ae

Bom dia. Tudo bem com vocês?
Estou buscando uma solução alternativa para o mTLS de um backend hospedado no Heroku.
Uso o AdonisJS.
Um prefixo na webhookUrl => https://mtls.pix.ae/cardapioo-api.herokuapp.com/webhookpix
Mas não sei qual o fluxo nesse cenário. Eu imaginava que fosse assim:
1- O GN envia o primeiro request para a webhookUrl cadastrado pelo Postman, retorna com 403;
2- Faz um novo request em https://mtls.pix.ae/cardapioo-api.herokuapp.com/webhookpix junto com o certificado;
3- Ao bater no webhookUrl com o prefixo mtps.pix.ae é direcionado para a url respondida pelo meu backend;
4- Lá encontra a rota https://cardapioo-api.herokuapp.com/webhookpix POST já pronta;
5- Eu apresento ao GN a minha parte do certificado e pronto.

Mas o que acontece na verdade é => "nome": "webhook_invalido", "mensagem": "A requisição na URL informada falhou com o erro: HPE_INVALID_CONSTANT"

Alguém pode me ajudar por favor?

Usar como proxy um servidor que implemente mTLS. Pode ser o API Gateway do AWS, pode ser o mTLS proxy do pix.ae.

Um detalhe a lembrar é que se vc cadastra mtls.exemplo.com.br, a Gerencianet vai acionar mtls.exemplo.com.br/pix .

<@!780500321994539068> consegui executar a funcao de cadastrar o webhook.. mudei tudo para um outro servidor do zero e consegui fazer o mTLS funcionar lá.. porém, não chega nenhuma requisição.. tem alguma forma de saber o q tah acontecendo com as notificações, assim como a API de Boletos fornece?

quando mudo o SSLVerifyClient require para none, o erro que a API da gerencianet retorna é que nao posso usar a rota pq nao tem mTLS.. quando ativo, dá o erro 403 dizendo que não faz o hand-shake =/

João comigo ocorre o seguinte.. quando uso a função de cadastrar o webhook e não configuro o mTLS na rota para notificações, recebo o erro "A autenticação de TLS mútuo não está configurada na URL informada".. porém, quando mudo a configuração do Apache e ativo o mTLS na rota de notificações e uso novamente a função de cadastrar webhook recebo o erro "A URL informada respondeu com o código HTTP 403", e dá esse erro exatamente porque a rota está protegida pelo mTLS.. o certificado da gerencianet está corretamente configurado no Apache.. teria alguma dica do que pode ser?

Oi <@!177276428675448832> tudo bem? 🙂
O campo aceita ambos os valores, true e false.
Adição do header x-skip-mtls-checking no endpoint PUT /v2/webhook/:chave para permitir o cadastro de servidores webhooks sem validação de mTLS durante o consumo.
Regras explicadas:

Se o parâmetro não for enviado, iremos validar mTLS;
Se o parâmetro for enviado e valor igual à true, não validaremos mTLS ;
Se o parâmetro for enviado e valor diferente de true, validaremos mTLS;

Salientamos que a Gerencianet continuara a fornecer a comunicação com mTLS, ou seja, na comunicação da notificação nada mudou. O POST entre Gerencianet e EC continua enviando o certificado.

Para mais detalhes verifique o roadmap no link https://gnetbr.com/rke4baDVyd

Se tem, ninguém conseguiu achar e postar aqui. O que já foi mencionado é criar uma entrada DNS específica não passando no proxy reverso da Cloudflare, ex mtls.exemplo.com.br, apontando diretamente para um virtual host no seu servidor.

Sim, tem. Os planos não Enterprise da Cloudflare não tem como adicionar a CA privada da Gerencianet para o mTLS.

Boa tarde pessoal!

Alguem já configurou mTLS do Webhook via annotations do nginx no kubernetes?
Estou tentando aqui, mas sem sucesso.

nginx.ingress.kubernetes.io/auth-tls-verify-client: "optional"
nginx.ingress.kubernetes.io/auth-tls-secret: "gerencianet-ca-prod"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "3"

Pode ser a mesma máquina, só não pode ser o mesmo virtual server. Você vai precisar criar algo como mtls.exemplo.com.br.

Os relatos aqui no canal dizem que apenas com plano Enterprise da Cloudflare para colocar certificado mTLS com CA própria (Gerencianet) no caso.

O que ajuda mais para teste, pois requer que se faça controle na aplicação para garantir mTLS.

Passa o x-skip-mtls-checking como true

ah, o header:

Se você consegue acessar com o browser, já sabe que o mTLS não está legal.