Termos mais procurados:
Histórico de mensagens sobre mtls
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Conceito de Payload Locations no PIX
- Implementação do Módulo Gerencianet no Perfex CRM
- Repetição do Processo de Criação com txid
- Endpoint para Recuperar Saldo
- Configuração de URLs para Recebimento de Status
- Consulta de Chave PIX na API de Envio
- Problemas com Token em Ambiente de Homologação
- Utilização de Endpoints e Payload no Pix
- Implementação da SDK do Pix em Next.js ou React
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Recebimento de Pagamentos via QR Code e Arduino
- Cobrança em Período de Teste Grátis de 7 dias
- Cancelamento de Boleto e Remoção do DDA
- Integrações com o Laravel e SDK de PHP da EFI
- Atualização de informações no Retentiva de Cobrança
- Teste de Status de Pagamento em Ambiente de Homologação
- Autenticação com Certificado em NextJS
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
- Retenção de Pagamento no PIX em Marketplace
- Geração de payment_token pelo Postman e teste em homologação
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Integração da API do Pix em Sistema Próprio
- Especificação da URL do Webhook no Exemplo Pix
- Alternativas para Detalhar QR Code Pix
EXIBINDO CONVERSAS RECENTES:
Texto: mtls
é que o Cloudflare oferece o mTLS gratuitamente, mas o certificado precisa ser gerado do lado deles (com CSR gerado por eles mesmos ou com CSR fornecido)
somente a GN pode prover o certificado para o mTLS ou pode ser o oposto (nós provermos o certificado para a GN)?
import feign.Body;
import feign.Headers;
import feign.Param;
import feign.RequestLine;
public interface PixAPI {
@Headers({"x-client-cert-pem: {{X-Certificate-Pem}}", "Authorization: {authorization}", "Content-type: application/json"})
@RequestLine("POST /oauth/token")
@Body("{\"grant_type\":\"client_credentials\"}")
OAuthResponseDTO oauthToken(/ String cert, /@Param("authorization") String authorization);
@Headers({/ "x-client-cert-pem: {cert}", / "Authorization: {oauthToken}", "x-mtls-bypass: 1"})
@RequestLine("PUT /v2/webhook/{accountKey}")
@Body("%7B\"webhookUrl\": \"{webhookUrl}\"%7D")
PixWebhookResponseDTO configureWebhook(@Param("oauthToken") String oauthToken, @Param("webhookUrl") String webhookUrl, @Param("accountKey") String accountKey);
@Headers({/ "x-client-cert-pem: {cert}", / "Authorization: {oauthToken}", "x-mtls-bypass: 1"})
@RequestLine("DELETE /v2/webhook/{accountKey}")
void removeWebhook(@Param("oauthToken") String oauthToken, @Param("accountKey") String accountKey);
}
import feign.Headers;
import feign.Param;
import feign.RequestLine;
public interface PixAPI {
@Headers({"x-client-cert-pem: {{X-Certificate-Pem}}", "Authorization: {authorization}", "Content-type: application/json"})
@RequestLine("POST /oauth/token")
@Body("{\"grant_type\":\"client_credentials\"}")
OAuthResponseDTO oauthToken(/ String cert, /@Param("authorization") String authorization);
@Headers({/ "x-client-cert-pem: {cert}", / "Authorization: {oauthToken}", "x-mtls-bypass: 1"})
@RequestLine("PUT /v2/webhook/{accountKey}")
@Body("%7B\"webhookUrl\": \"{webhookUrl}\"%7D")
PixWebhookResponseDTO configureWebhook(@Param("oauthToken") String oauthToken, @Param("webhookUrl") String webhookUrl, @Param("accountKey") String accountKey);
@Headers({/ "x-client-cert-pem: {cert}", / "Authorization: {oauthToken}", "x-mtls-bypass: 1"})
@RequestLine("DELETE /v2/webhook/{accountKey}")
void removeWebhook(@Param("oauthToken") String oauthToken, @Param("accountKey") String accountKey);
}
o curl tem um parâmetro pra indicar o arquivo do certificado SSL. aí vc tem que pesquisar sobre SSL / mTLS em Java (não tem exemplos no site da GN)
esse serviço da AWS aparentemente é agnóstico em relação à tecnologia que vc usa. ele só vai receber o request https:// (fechando o canal mTLS com o seu certificado) e repassar a comunicação pro seu backend
sobre o mtls usando o gateway api na aws...cria um custom domain name (esse é o cara q vc vai registrar no webhook)...e ativa o mtls...o certificado que vc baixa no site da GN vc coloca no s3
Depois de estudar muito, finalmente passei de ano. Com a geração do certificado .pem (produção) efetuado com sucesso hoje . Agora a pouco consegui criar o token de produção com sucesso 🙌 . Na tentativa de gerar a primeira cobrança sem o bendito do postman ,que já tem mTLS nele, recebo = forbidden ao tentar criar a cobrança. Começa agora o quinto capítulo da mini-série "Indoidando com o PIX" 🤣 . Capítulo = mTLS.
Correto, se está retornando 200 ao associar o webhook a sua chave é porque você atendeu as configurações do mTLS.
Como eu estou recebendo a confirmação do registro do webhook, isso já garante que minha configuração do mtls está certa e deveria funcionar, certo?
Em relação a hospedagem compartilhada como mencionado por <@!440035527127990273> , não é possível configurar o mTLS, pois, você não tem acesso ao .conf do VirtualHost. Sugerimos que tentem um servidor dedicado ou entrem em contato para que a sua hospedagem forneça uma solução para estes casos.
Obrigado por colaborar com a comunidade! Vou inserir um exemplo de app route em node que em conjunto com o Apache realiza a configuração do mTLS.
Pode me ajudar Rafael com isso ? Tô sonhando com mTLS 🙂
Pessoal, quem quiser/precisar mtls o api gateway da aws da pra configurar em 5 min
ainda é possível usar um endereço de callback "externo" ao ambiente que lança as cobranças, mas sendo mTLS é mais seguro do que fazer o PSP enviar requests para qualquer destino desconhecido. o mTLS poderia não se justificar nos casos em que a iniciação é do PSP, mas na iniciação externa fica mais garantido que é intencional o uso de determinada URL para callback
estava refletindo e entendi porque os locations são abertos. para permitir a existência das soluções de "iniciação pix" por parte de empresas que não são instituição de pagamento ou instituição financeira. e aí até faz algum sentido o callback ser obrigatoriamente por um canal mTLS. dá mais controle ao processo, impedindo que eles sejam direcionados a destinos "selvagens" que não foram pre-acordados com o PSP recebedor quando a iniciação também não for via cobranças armazenadas no próprio PSP
a questão não é a "obtenção da URL". a questão é você precisa de mTLS para "injetar" uma cobrança no sistema da GN, vinculada à sua conta GN. por isso o nível de segurança maior.
o que eu achei errado foi justamente o location estar desprotegido de mTLS (deveria haver um ponto central de autoridade para obtenção dos dados de uma cobrança quando o QR é lido, para que apenas os PSPs pudessem obter esses dados, não qualquer pessoa com acesso ao QR, assim poderia implantar limitação de consumo, por exemplo) e o webhook estar protegido (esse, não deveria ter essa exigência de mTLS, já que é apenas meramente informativo, e quem define a URL de callback já fez uso das credenciais e do canal mTLS pra isso)
na verdade a exigência de mTLS me pareceu interessante para o fluxo de criação de cobrança. fica bem mais restritivo e difícil alguém criar as cobranças por você, mesmo que sua aplicação tenha uma brecha que permita a obtenção de suas credenciais, não tendo o certificado em si (que normalmente só o acesso root poderia dar)
a URL do callback também precisa mTLS. então estou planejando oferecer um facilitador pra quem está em hospedagem compartilhada e não tem como fechar o mTLS, como é o seu caso. mas pra isso, preciso fazer os QR dinâmicos funcionarem primeiro