Histórico de mensagens sobre webhook

Perfeito, já é um bom começo.
Fiz o teste tentando registrar o webhook e recebo A URL informada respondeu com o código HTTP 300, é como se tivesse um redireiconamento.

O que postei acima foi pelo browser, Google Chrome. A partir daí para testar só vendo a mensagem de erro que o cadastro de webhook gera, pq aí a Gerencianet tenta com o certificado apropriado.

Ao acessar o dominio pelo browser tenho esse retorno

Ocorreu um erro durante uma conexão com webhookyoudo.cloudns.nz. O sistema remoto SSL não conseguiu negociar um conjunto aceitável de parâmetros de segurança.

Código do erro: SSL_ERROR_HANDSHAKE_FAILURE_ALERT

Isto aqui é o esperado mesmo com mTLS:

Deu erro aqui
HTTP Requests
1 https://webhookyoudo.cloudns.nz/ (Request failed)

Multiviews desligado, mas sem efeito, continua com erro 300
Fiz o teste em https://www.ssllabs.com/ssltest/analyze.html?d=webhookyoudo.cloudns.nz e não está mais gerando aquele erro de anterioremente, já é um progresso, rs

Pelo menos para o virtual server do webhook.

Boa tarde gente, gostaria de saber se é possível checar os webhooks mandados para o sistema. Creio que recebemos um de venda reembolsada, porém não acho o comprovante do reembolso para enviar para a cliente.

saída do meu apachectl -S
VirtualHost configuration:
:80 ip-172-31-31-61.ec2.internal (/etc/apache2/sites-enabled/000-default.conf:1)
:443 webhookyoudo.cloudns.nz (/etc/apache2/sites-enabled/webhookyoudo.conf:2)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: MODSEC_2.5
Define: MODSEC_2.9
User: name="www-data" id=33
Group: name="www-data" id=33

@fabianoyoudo a configuração do webhook foi removida dos outros arquivos?
Nesse exemplo que citei, é importante que somente o arquivo personalizado tenha as configurações do webhook senão pode ocorrer conflito

Segui sua sugestão, agora mudou o ero, rs

{
"nome": "webhook_invalido",
"mensagem": "A URL informada respondeu com o código HTTP 300"
}

O que o SSLTest sugere é que a configuração que você está alterando não seja a configuração em uso:
https://www.ssllabs.com/ssltest/analyze.html?d=webhookyoudo.cloudns.nz

ServerAdmin webmaster@localhost
ServerName webhookyoudo.cloudns.nz
ServerAlias www.webhookyoudo.cloudns.nz
DocumentRoot /home/ubuntu/www


ErrorLog ${APACHE_LOG_DIR}/webhook.error.log
CustomLog ${APACHE_LOG_DIR}/webhook.access.log combined

SSLEngine on
SSLProtocol -all +TLSv1.2

SSLCertificateFile /etc/letsencrypt/live/webhookyoudo.cloudns.nz/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/webhookyoudo.cloudns.nz/privkey.pem

#Chave pública da Gerencianet
SSLCACertificateFile /home/ubuntu/www/cert/chain-pix-prod.crt

# mTLS Gerencianet
SSLVerifyClient require
SSLVerifyDepth 3

# Tratando o /pix, redirecionando as requisições sempre para /webhook
Alias "/pix/" "/home/ubuntu/www/index.php"
Alias "/pix" "/home/ubuntu/www/index.php

Boa tarde, por gentileza, alguem da GN poderia me dar algumas orientações?
Estou tendo o seguinte erro ao tentar registrar o webhook
{
"nome": "webhook_invalido",
"mensagem": "A requisição na URL informada falhou com o erro: EPROTO"
}

nao vejo log da gerencianet chegando no servidor como o webhook

Boa tarde @thalesmatoso tudo bem? 🙂
Até o momento não tivemos relatos de falha relacionado ao envio de confirmações para os webhooks.
Consultando a cobrança, conforme sugerido pelo @rubenskuhl , acredito que retorne as informações que você precisa também.

Só ressaltando alguns pontos:
- Atualmente o Histórico de Notificações e o Histórico de Requisições no painel da Gerencianet ainda não exibem informações referentes ao Pix.

- O envio das confirmações de pagamento de cobranças PIX são feitas via webhok, e já as confirmações de pagamento referentes ao BOLIX são um fluxo de notificações diferente (links abaixo)
Webhook Pix: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-webhooks
Notificações Bolix: https://dev.gerencianet.com.br/docs/notificacoes-recebendo

Alguem mais sem receber as webhook do PIX ou somente eu?

O ponto ideal para o script de recuperação é o GET em /pix. É o primeiro objeto que a GN atualiza. O /cob e o webhook são atualizados só depois.

Nem o webhook do bolix que passa por outro meio de pagamento esta chegando

nao mostra os registro de webhook do pix