Boa tarde, @artesa.maluca!
Parece ser uma questão da versão do servidor utilizada. Ao manter a URL o mTLS consegue prosseguir normalmente?
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
- Recebimento de Pagamentos via QR Code e Arduino
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Cobrança em Período de Teste Grátis de 7 dias
- Cancelamento de Boleto e Remoção do DDA
- Teste de Status de Pagamento em Ambiente de Homologação
- Integrações com o Laravel e SDK de PHP da EFI
- Atualização de informações no Retentiva de Cobrança
- Autenticação com Certificado em NextJS
- Alternativas para Detalhar QR Code Pix
- 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
EXIBINDO CONVERSAS RECENTES:
Texto: mtls
Boa tarde, estou tentando configurar o mTLS para cadastrar o wwebhook da chave pix, estou usando nginx com PHP, ja configurei o .cong do nginx e está da seguinte forma
server {
server_name {URL_BASE};
root /var/www/html/public;
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/privkey.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_client_certificate /etc/nginx/ssl/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
ssl_verify_depth 3;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
index index.html index.htm index.php;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\.(?!well-known). {
deny all;
}
location /api/webhook/efi/pix {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass {URL_BASE}/api/webhooks/efi/pix;
}
}
Ao tentar deixar o proxy_pass sem a url junto, ele da erro ao tentar iniciar o nginxserver_name {URL_BASE};
root /var/www/html/public;
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/privkey.pem;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_client_certificate /etc/nginx/ssl/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
ssl_verify_depth 3;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
index index.html index.htm index.php;
charset utf-8;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\.(?!well-known). {
deny all;
}
location /api/webhook/efi/pix {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
proxy_pass {URL_BASE}/api/webhooks/efi/pix;
}
}
Jan 02 19:01:22 ip-172-31-42-174 nginx[3444869]: nginx: [emerg] invalid URL prefix in /etc/nginx/sites-enabled/default:86
Jan 02 19:01:22 ip-172-31-42-174 nginx[3444869]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jan 02 19:01:22 ip-172-31-42-174 nginx[3444869]: nginx: configuration file /etc/nginx/nginx.conf test failed
Não. Por isso que o mTLS seria a opção superior.
Multi-tenancy não é problema pro mTLS, pq as chamadas para todos os clientes Efí usam a mesma CA (CA privada da Efí) e mesmo CN (gn-webhook-pix), etão você pode usar a mesma configuração para todos.
No webhook vem a chave Pix, e cada chave Pix é de um client... então você já tem uma informação para diferenciar os tenants, e pode usar até mesmo a exata mesma URL para tudo. Agora, dá para adicionar um parâmetro do webhook que vc configura em cada chave Pix para ter um double check. Poderia ser por exemplo:
"https://webhookefi.zonkof.com.br/?tenant-id=xxxxxx&ignorar="
O ignorar= é pq a Efí vai adicionar um /pix no final.
Galera, minha API utiliza uma abordagem multi-tenancy, ou seja, é uma unica API que atende a vários bancos de dados, cada banco de dados (Entenda cada banco de dados, como uma empresa que contrata o meu sistema.)
Estou utilizando o cloud run do GCP para hospedar a API, e quero configurar o webhook de pix, porém vi que precisa adicionar uns certificados na configuração do nginx/apach/express etc.. e tem que fazer algo relacionado aos certificados ssl da API e tal.. porém, como está no gcp, isso ficaria dificil. Entao gostaria de utilizar a abordage do Skip-mTLS...
Como mencionei acima, minha aplicação é multi-tenancy, e existe um middleware na minha API que recebe na requisição um parametro chamado "x-tenant-id" (atualmente é um header, mas pode ser qualquer coisa que funcione kk). Então gostaria de saber como eu poderia proceder para que em todas as requisições do webhook que a EFI mandará para a minha API, tenha algum identificador para que possa fazer a orquestração de qual banco de dados realizarei as consultas aqui.. Poderiam me ajudar com isso?
Bom dia, @helderandre! Como vai?
Como o @alexandrer85 mencionou, você pode usar o atributo x-skip-mtls-checking = true. Assim, a API do Efí vai continuar enviando o certificado mTLS na requisição, mas seu servidor irá ignorá-lo.
Nesse caso, é importante encontrar uma forma de garantir que é o Efí quem está enviando a notificação. Sem o mTLS configurado, não há o "handshake". Uma sugestão é verificar o IP de origem da notificação, já que o Efí utiliza o IP 34.193.116.226 para comunicação dos webhooks. Além disso, é interessante cadastrar a URL com uma hash conhecida apenas pelo seu sistema.
coloque x-skip-mtls-checking = true
isso, com o skip-mTLS você nao precisa do CA
Isso, neste caso você pode manter o x-skip-mtls-checking = true no Header da requisição 🙂
eu uso Skip-mTLS dai?