Histórico de mensagens sobre certificado

dá pra colocar o certificado da GN lá?

Resolvi aqui, era um problema no meu server com certificado

não da, por causa do certificado CA do servidor

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...

Outra coisa que eu já vi é o Apache dar problema quando vc usa um certificado que inclui a cadeia como SSLCertificateFile e tenta usar um SSLCACertificateFile ao mesmo tempo. Se limitar o TLS a 1.2+ não resolver, tenta usar o certificado sem a cadeia do Let's Encrypt (em vez do fullchain.pem, deve ter um outro arquivo que é só o certificado, cert.pem), e criar um arquivo unindo o ca.pem do Lets Encrypt + o .crt da GN pra usar como SSLCACertificateFile (não jogue o crt da GN dentro do ca.pem, pois esse ca.pem é sobrescrito a cada 2-3 meses quando o LE do domínio se renova). edit: ver meu outro comentário abaixo.

As configurações do VirtualHost aparentemente estão corretas, só para fins de testes insira os paths dos certificados dentro do Location

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.

oi <@!671762828046106646> . Pois é. já me certifiquei disso. Inclusive testei removendo-os e recebi o erro específico para o cenário em que esses certificados não existem.

<@!704694550631022592> Bom dia!
Não se preocupe, este canal é mesmo para tirar suas dúvidas! 😉
Primeiramente, para quaisquer consumo dos endpoints do Pix, é necessário realizar uma autenticação com suas credenciais client_id, client_secret e certificado. Para isso, seu primeiro consumo será na rota POST /oauth/token. Segue exemplos em algumas linguagens: https://dev.gerencianet.com.br/docs/api-pix#section-exemplos-de-autentica-o-utilizando-o-certificado-p12

Após a autenticação, você utilizará o endpoint para criar uma cobrança PUT /v2/cob/{txid}. Documentação: https://dev.gerencianet.com.br/docs/api-pix#section-criar-cobran-a-

Para acompanhar as mudanças de status de um pix, você pode configurar um webhook, que reúne endpoints para gerenciamento destas notificações. https://dev.gerencianet.com.br/docs/api-pix#section-webhook

Utilize também nossa Collection da Gerencianet com todos os endpoints já configurados para o consumo (https://dev.gerencianet.com.br/docs#section-collection-postman-gerencianet-api-pix).
A respeito do seu certificado, logo lhe retornaremos através do ticket.

Para utilizarem a API PIX Gerencianet, precisará de um certificado gerado por nós.
Para isso acesse nosso site em sua conta, no menu API > Minhas aplicações você criará uma aplicação que são gerados 2 pares de chaves Client_Id e Client_Secret, sendo um par para utilização em ambiente de Produção e outro para Homologação.

Então abra um ticket acessando https://sistema.gerencianet.com.br/tickets/criar, e solicite o certificado para integração nos informando:
-Número da sua conta:
-Nome da aplicação criada:
-Ambiente: Produção/Homologação

Em nossa documentação(https://dev.gerencianet.com.br/docs) você encontra os nossos endpoints com explicações detalhadas, você pode verificar também a Collection da Gerencianet com todos os endpoints já configurados para o consumo (https://dev.gerencianet.com.br/docs#section-collection-postman-gerencianet-api-pix).

Para você que iniciará com PHP, possuímos uma SDK com os principais endpoints para a utilização do Pix, disponível em nosso GitHub. https://github.com/gerencianet/gn-pix-sdk-php-exemplo

Ok. <@!790400805303746571> no atributo nome_certificado, insira somente o nome do certificado. Ele deve estar contido na pasta certificado

{
"sandbox": true,
"chave": "[email protected]",
"recebedor": "Guilherme Menegussi",
"homologacao": {
"nome_certificado": "https://www.eyhe.com.br/3.0/painel/enginePIX/direct_api/certificado.pem",
"client_id": "xxx",
"client_secret": "xxx",
"pix_url_auth": "https://api-pix-h.gerencianet.com.br/oauth/token",
"pix_url_cob": "https://api-pix-h.gerencianet.com.br/v2/cob",
"pix_url": "https://api-pix-h.gerencianet.com.br/v2/pix"
},
"producao": {
"nome_certificado": "productionCertificate.pem",
"client_id": "xxx",
"client_secret": "xxx",
"pix_url_auth": "https://api-pix.gerencianet.com.br/oauth/token",
"pix_url_cob": "https://api-pix.gerencianet.com.br/v2/cob",
"pix_url": "https://api-pix.gerencianet.com.br/v2/pix"
}
}

já estou com certificado .pem

O privkey.pem e o fullchain.pem do meu certificado são gerados pelos Letsencrypt, somente informei o diretório onde estão localizados

Como está o meu, utilizo certificado Letsencrypt