Histórico de mensagens sobre an

Sim...observei que já estão disponíveis tanto o Client_ID como o Client_Secret que ambas as abas no site. Grato por seu esclarecimento meu amigo!!!

Não procede <@!921457394368790548>, o par de credenciais você consegue gerar e visualizar acessando diretamente a sua conta Gerencianet.

Olá <@!795645731385901076> recebi aqui sua comunicação. Pelo que havia recebido de informações anteriores através de amigos que utilizam o Gerencianet é que haveria a necessidade de uma confirmação via SMS para obtenção dessas chaves que viriam zipadas por email. Isso não procede?

Boa tarde a todos.
Estou iniciando um projeto e pretendo usar o Portal Gerencianet como administrador de recebíveis. Preciso de orientações para obtenção das chaves de Produção e Desenvolvimento. Alguém pode me ajudar?

ola boa tarde, estou com uma probleminha
estou realizando um pesquisa de carne pelo o id do carne e recebo a mensagem 'Unauthorized'
com as seguinte configurações de uso
sandbox: false,
client_id: secreto,
client_secret: secreto,
pathCertHomologacao: '',
validateMtls: false,

aplicação em javascript

estou querendo utilizar a base de dados real com os cliente cadastrados

Tranquilo, eu calculei a frequência dentro dos limites que mostra a documentação

Bom dia, <@!229769812740407296>! A exigência do mTLS hoje veio do próprio BACEN e para adequar as normas e requerimentos da API Pix realizamos tal exigência no cadastro do webhook. Você pode utilizar também o endpoint GET /v2/pix para consultar os Pix recebidos, no entanto, recomendamos que se atente a boas práticas de consumo e evite fazer um pooling de forma exacerbada, pois a nossa equipe de infraestrutura acompanha este tipo de consulta e pode levar a restrições no IP nestes casos.

Nós só temos 1 gateway no momento, a Gerencianet. O sistema está preparado para múltiplos, mas não estamos usando esse recurso no momento. Talvez quem faça milhões de transações por dia precise, nós só fazemos milhares de transações por dia.

Fato é que não obedecer ao padrão da API Pix era desqualificação imediata na seleção de PSPs que fizemos. E que hoje usamos Gerencianet, mas como é um padrão, temos liberdade para mudar se quisermos. Quem usa os não padrão, tem um custo de mudança elevado.

Mesmo com cronjob você está usando mTLS... tanto que você apresenta um client-certificate. Só é mais fácil de implementar do que a checagem server-side, mas é mTLS também.
E usar um gateway de pagamento que não segue padrões é pedir para se tornar escravo.

Ou só fazer como eu fiz, verificar os pagamentos com cronjob, ou usar um gateway de pagamento que não torture os devs como o MercadoPago. Afinal eu não estou fazendo integração de uma instituição financeira nem nada do tipo.

O IP da Gerencianet que testei está sim coberto por um objeto RPKI, mas que tem zero efeito em redes que não validam.
Backbones Internet variam muito de segurança e qualidade... os que já foram usados para hijack mostram que isso é um problema.
O ponto de mTLS é que você disse que filtro por IP resolve, quando não resolve. Eu mesmo já apontei que não é o único design possível, e que há outras arquiteturas que não mTLS que sobreviveriam a IP hijack.
Mas o mTLS foi o que o instituidor do arranjo escolheu... não quer usar, só não aceitar Pix.

1 e 2) Se a Gerencianet não usa RPKI, não serve pra mexer com dinheiro. Se minha infra não verificam rotas, não serve pra ser minha infra.
3) Exato, então é mais fácil alguém hackear o backbone Internet, do que a AWS ou a Gerencianet? Pq sempre vai existir um vetor de ataque enquanto existirem humanos nesse planeta. Se a discussão se resume em "Ah mTLS é necessário pq existe a possibilidade de ataque X acontecer", daria pra se dizer o mesmo de toda e qualquer prática de segurança por mais infuncional que seja.

1 e 2) Enquanto você discute de quem é o problema, o fraudador embolsou a sua grana e do seu cliente
3) Não, MITM de anúncio assinado você pega qualquer roteador que esteja na Internet, pega os anúncios e repassa. Aí você recebe o tráfego, muda o que você quer muda, devolve o que não vai mudar. Quem foi hackeado aí foi o backbone Internet, não a AWS ou a Gerencianet.

1) Problema de quem anuncia
2) Problema de quem não verifica
3) MITM de anúncios assinados não seria literalmente a definição de hackear?

Eu sei que existe, o meu empregador que assina os RPKI brasileiros... 😉
Mas se você sabe que existe RPKI, deveria saber também que:
1) Nem todos os blocos IP já estão assinados
2) Nem todos os roteadores já verificam RPKI
3) RPKI endereça apenas hijacking com ASN origem errado, ainda é possível fazer hijack usando MITM de anúncios assinados

Existe um negócio chamado RPKI. Então acho mais fácil hackearem a Gerencianet do que a AWS.

Veja como foi este caso de IP hijacking há alguns anos atrás:
https://www.zdnet.com/article/aws-traffic-hijack-users-sent-to-phishing-site-in-two-hour-cryptocurrency-heist/

IP hijacking não precisa de comprometimento da Gerencianet. Alguém anuncia a rede do AWS onde fica a Gerencianet e desvia o tráfego para o hijack.

Como complemento, ótimo... dá para fazer estas checagens hoje no webhook:
1) O IP é o da lista da Gerencianet
2) O certificado é assinado pela CA da Gerencianet
3) O certificado tem o CN gn-webhook-pix
4) A chave Pix é uma chave para qual você registrou webhook
5) A transação é uma que você criou