Termos mais procurados:
<@!798679248633856000> Não. O certificado p12/pem é para a autenticação do consumo da API.
Já para a configuração do mTLS, você irá utilizar o CA com a chave pública da Gerencianet, sendo uma para cada ambiente, segue link das chaves públicas:
Desenvolvimento: https://pix.gerencianet.com.br/webhooks/chain-pix-sandbox.crt
Produção: https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt
Isso renato, então eu preciso de outro certificado para o mTLS, eu gero ele ou a GN me fornece?
A pergunta ficou dúbia mas o que o @ribas2555 queria saber é se ele vai usar o mesmo certificado que a GN enviou (para consumir a API) na hora de validar os callbacks. Então a resposta é não. Mesmo que o certificado usado pela GN do lado dela seja o mesmo nos dois casos.
Não o da GN, mas o que o EC apresenta. mTLS tem dois certificados envolvidos.
Rubens, são certificados diferentes. O que consome a API é individual por cliente e ambiente (dev/produção). O que usamos pra validar o mTLS nos callbacks é diferente (separados apenas por ambiente dev/produção, sendo os mesmos dois para todos os clientes).
então se eu fizer a verificação do mTLS no nginx por exemplo, o certificado que vou usar é o mesmo p12/pem do auth?
Não é o BACEN que envia o certificado, é a Gerencianet. Mas sim a GN tem adotado o uso do mesmo certificado nos dois sentidos da API.
https://github.com/bacen/pix-api/issues/267
isso quer dizer que o certificado que o bacen vai me enviar pra ser feito a verificação do webhook é o mesmo que uso para gerar o token?
o certificado eo de produção
<@!664563985885954079> essa falha está associada ao uso de credenciais em ambientes diferentes do certificado, você está utilizando a rota, credenciais e certificado no mesmo ambiente?
curl_setopt_array($curl, array(
CURLOPT_URL => $_ENV["PIX_URL_AUTH"], // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS =>"{\r\n \"grant_type\": \"client_credentials\"\r\n}",
CURLOPT_SSLCERT => $arq_certificado, // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $authorization",
"Content-Type: application/json",
),
));
Olá, bom dia .. criei o ticket para criar os certificados no dia 18, mas ainda não recebi, podem verificar por favor...ticket 1795821
mas "não seguir" mTLS seria não enviar o certificado. se é o EC que valida, qual a responsabilidade do PSP? qual o critério pra saber que o EC não tá validando?
<@!780500321994539068> o manual de segurança diz que o callback deve ser enviado por canal mTLS. mas como o PSP pode garantir que o canal é mTLS? não existe isso. ele envia com certificado e o cliente verifica se ele quiser. não tem como a GN saber se o cliente tá validando.
não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").
essa opcao no header do webhook é para o ambiente dev? se sim, como eu consigo o certificado quando for pra prod?
A chave de um cliente é só desse cliente. Se você tem mais de um cliente usando sua integração, você vai precisar de algo para segmentar chaves e certificados.
e voce passa o a base64 no parametro do certificado no header?
headers: {
authorization: 'Bearer ' + token,
'x-client-cert-pem': base64,
},
chamei e peguei o token, mas no postman mostra que no headers é feita a importação do certificado pem no parametro 'x-client-cert-pem'
