Histórico de mensagens sobre certificado em sugestões

A gerencianet tem uma forma de receber pix sem usar certificado... Só usar bolix... Seria uma forma de "contornar" essa camada de segurança...

Detalhe q a versão mais nova da api do PagSeguro, pelo menos de pix, não sei se é toda... Já trabalha com certificado tbm...

Eu gasto menos de 70 linhas de código pra implementar cada API de pix pros meus clientes, é muito mais fácil do que ter que trabalhar com certificado, eu só faço uma abstração nos webhooks, e pronto.

Eu duvido bastante que todas as empresas que eu citei estariam arriscando tudo só pra ter uma API mais fácil e ser multados depois, acho que teve uma má interpretação do que realmente foi estabelecido, eu particularmente nunca li, mas já vi aquele protótipo horroroso com tudo em português, e vários sites divergem nos nomes dos campos mesmo assim, ex: Juno v.s PagSeguro, até mesmo os métodos de criação, que alguns usam PUT e outros POST, acho que era só um padrão recomendado, e não algo obrigatório, exigir certificado em todas as APIs só vai complicar e deixar o sistema mais inacessível.

É indiferente a separação do domínio, já que ambos exigem certificado pra serem acessados, ambos tem a mesma complexidade de autenticação, só é mais um pé no saco pra você criar outra instância do Guzzle/Axios

No caso da API Pix, ela é com certificados por exigência do Banco Central. Vários dos que você citou desobedecem regulamentação e eu mesmo já denunciei vários dos que você citou. Então a API pode parecer mais simples hoje, mas quando eles tiverem que mudar para não serem multados, vão descartar e vai ter que ser do jeito que o BACEN especificou.

Ajudaria muito as integrações se existisse o mesmo sistema de autenticação da Iugu, onde existe uma autenticação básica só para receber pagamentos, e uma mais complexa com os certificados para enviar pagamentos, assim não correria nenhum risco de compartilhar o token com algum serviço de terceiro, já que ele só poderia receber por você, e não enviar nenhum pagamento, sem contar que isso descomplicaria muito a API.

A maioria das empresas relevantes usam essa autenticação mais leve, de um token sem certificado, PagSeguro, MercadoPago, Juno, PicPay Ecommerce, PagHiper, Stripe, PayPal

A falta dessa autenticação mais simples pra receber pagamentos me afastou muito da gerencianet, e hoje só uso pra receber pagamentos manuais.

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

Esse primeiro deploy traz uma versão mais simples, na qual a Gerencianet resolve tudo. Isso atenderá a alguns perfis de clientes. Lembrando que nós não armazenamos a chave privada.

Mas a sugestão de aceitar um CSR é tão boa que já tá até no Roadmap, neste card: https://www.notion.so/Gera-o-de-certificados-API-Pix-a-partir-de-um-CSR-de6f5650a5d44ed092af81d6b830ed66

Foi colocado no sistema a geração de certificados, mas ela gera tanto a parte secreta quanto pública. O usual de CAs é que apenas o titular tenha a parte secreta, envia sua chave pública para a CA e essa assina a chave pública. Sugiro que seja alterado para usar um CSR e não gerar a chave.

No caso do callback, espera-se que o cliente valide o certificado: seja na camada de transporte ou aplicação. É isso que a gente quer permitir: deixar o cliente escolher. Entendemos que a validação do PUT está impedindo isso, ou pelo menos atrapalhando na fluidez.

a GN valida webhook sempre com o mesmo certificado. só precisa webhook e webhook-h

Na verdade, .webhook.pix.ae. Precisa do servername para decidir qual certificado apresentar.

hoje:
- GN envia "callback" simulado sem certificado (se for aceito pelo integrador, é uma falha; dá "break" aqui)
- GN envia "callback" simulado com certificado (que deve retornar 200)

poderia ficar assim:
- GN envia "callback" simuilado sem certificado:
--> se receber de volta 200 + um header x-mtls-bypass: true, tá ok e dá break;
--> se receber de volta 200 sem o header, é falha e dá break;
--> se receber de volta 4xx, segue adiante
- GN envia "callback" simulado com certificado (que deve retornar 200)

Pelo que entendi o fluxo seria:
PUT /webhook
Headers:["x-mtls-check": false]
----
Webhook de teste é enviado sem certificado e configurado normalmente.
---
Webhook normal é enviado com o certificado.

Mas ai eles enviariam o webhook de teste com o certificado...

Espera-se que sim. Ele vai conseguir cadastrar a URL. Quando for notificado, nós enviaremos o certificado. Isso abre caminhos para que o integador decida como validar que a requisição que está chegando é realmente da Gerencianet. Talvez ele não possa alterar uma configuração do nginx por estar sendo compartilhado com outras aplicações, porém talvez ele possa "ensinar" o nginx a repassar essa informação pra dentro da aplicação e validar manualmente via código.

A ideia da validação durante o PUT é pra ajudar a validar o ambiente mTLS, não seria, digamos, mandatória.

Somente a parte de solicitar o certificado que ficaria a cargo do titular da conta, mas podemos debater sobre isso também

A respeito do discutido em https://discord.com/channels/775322853884821504/775328670784159744/796748024566120519:

A GN poderia oferecer na parte de API > Aplicações, uma opção para compartillhar os direitos de acesso à essa aplicação com um integrador parceiro por dentro da plataforma da GN, que poderia ver o client_id e client_secret e solicitar certificados.

Assim não dependeria do cliente fazer o processo de obtenção de credenciais, solicitar certificado, receber senha por SMS (que tem período de validade relativamente curto - 4 horas) e depois encaminhar tudo isso pro integrador por fora do sistema.

Report de bug:

Os payloads de cobrança pagas estão retornando um JSON contendo erro: "status_cobranca_invalido", mensagem: "A cobrança não está mais com o status ATIVA". Assim, os apps dos PSPs pagadores estão apresentando "erro ao ler o QR".

O payload deveria continuar sendo retornado no padrão JOSE (com certificado e assinatura, igual as cobrança ativas), com o status alterado para CONCLUIDA, para tratamento adequado, conforme status + possível presença do template 01 com valor 12 (qr code de apresentação única).

O link para abertura de ticket (para solicitar certificado API Pix) na página https://dev.gerencianet.com.br/docs aponta para https://gerencianet.com.br/fale-conosco/ quando ele poderia apontar para https://sistema.gerencianet.com.br/tickets/criar (os tickets abertos pelo link apontado atualmente não ficam vinculados à conta dentro do sistema).