Histórico de mensagens sobre certificado em pix

@Efí, o erro “A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID” parece estar relacionado com o certificado da Amazon.

Ele ocorre para os dois cenários a seguir:

Webhook COM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.menur.app/vbeta1/establishments/mana/pix

Webhook SEM mTLS hospedado na Amazon, com certificado HTTPS emitido pela Amazon:
https://mtls.api.menur.app/vbeta1/establishments/mana/pix

Entretanto se acessar SEM mTLS com hospedagem no Heroku e certificado Let’s Encrypt o erro que dá é esperado:
https://api.menur.app/vbeta1/establishments/mana/pix

"A autenticação de TLS mútuo não está configurada na URL informada"

E agora? Vocês poderiam verificar o motivo? Obrigado!

Um deles (final gn) é o CRT baixado e com a extensão modificada para PEM. O outro (final cacerts) é produto de um procedimento que fiz com o Key Store Explorer: criei a TS e importei a cadeia do CRT (3 certificados) e depois converti a TS PKCS12 para o formato PEM usando o openssl.

<@!620895261568401428> Você precisa gerar um certificado válido para

o CNAME tava apontando para o host q a AWS associou ao certificado padrão. Mudei o CNAME para apontar para o host que gerei o cert com ACME.

Common Name é o CN do certificado, que não é a mesma coisa que CNAME de DNS que é o Canonical Name.

Olá, @Efí

Ainda na labuta do Webhook em ambiente PaaS. Fiz os seguintes passos e creio estar quase lá:

- Criei uma conta na Amazon para o projeto
- Cadastrei o cartão de crédito
- Provisionei o Amazon API Gateway
- Configurei um custom domain nele
- Configurei o domínio no meu Registrar
- Habilitei o custom domain no API Gateway
- Criei certificado e habilitei o HTTPS
- Baixei o cert webhook da Gerencianet
- Criei uma Trust Store PKCS12
- Coloquei a cadeia da GN lá
- Converti a TS para o formato PEM
- Provisionei um armazenamento Amazon S3
- Subi a TS.pem
- Finalizei a configuração do custom domain
- Ativei o mTLS neste domínio
- Criei uma rota de API para o meu server
- Associei a rota ao custom domain com mTLS

Fui configurando e testando a cada passo. Quase tudo funcionando. A única coisa que não consigo é fazer uma requisição client para testar o mTLS já que não tenho o cert client do webhook.

Então…

- Invoquei o serviço PUT /webhook/{chave} passando no body a url e recebi o seguinte body com o status 400:

{
"nome": "webhook_invalido",
"mensagem": "A requisição na URL informada falhou com o erro: ERR_TLS_CERT_ALTNAME_INVALID"
}

Supus ser algum erro no pem que usei para configurar o mTLS. E já experimentei o seguinte:

- Usei exatamente o CRT que baixei das docs da GN
- Fiz a conversão como citei acima (criando a TS)

Se vocês puderem fazer uma requisição mTLS com o certificado client correto para testar, a UTR é esta:

POST https://mtls.menur.app/vbeta1/establishments/mana/pix

O serviço está retornando 204 fixo para qualquer body json (não obrigatório).

Alguma luz? 🙏

Em relação à emissão de certificado, ainda não foi disponibilizada essa ferramenta, mas já esta próximo de concluir. Assim que estiver disponível, iremos avisar vocês.

Bom dia, tudo bom @Efí?
Em um pagamento pix, como eu vejo no painel da GN se me enviou o post da confirmação do pagamento?
Outra dúvida, sobre o certificado, haviam dito que estavam desenvolvendo algo
para conseguirmos pegar o certificado de uma forma mais fácil, já foi feito a ferramenta?

O PSP não precisa de um certificado oficial, ele pode gerar um certificado sem problemas.

No servidor onde está a minha aplicação temos o certificado Cerbot

Já vai pedindo via ticket o certificado de produção para agilizar...

A vantagem de par chave pública/chave privada, como se faz nos certs, é ter uma prova de autoria que só pode ser gerada por uma das partes. Um shared secret pode sofrer replay attack. O certificado é apenas uma forma padronizada e usual de usar criptografia assimétrica, que é a raiz desse processo.

Sim. Mas o client cert não garante, na prática, neste cenário, nenhuma segurança a mais do que usar um secret, por exemplo. Todos os dados são tunelados com SSL da mesma forma. Só comentei mesmo pelo fato do tabu que existe quando se fala de certificado. Neste caso, ao meu ver, acaba sendo apenas burocracia.

Muitas vezes "apelam" pelo uso de certificados se valendo equivocadamente de proteções jurídicas referentes ao não repúdio. Mas que não se aplica em casos como este e em muitos outros que usam certificado sem tanta necessidade.

Na verdade a solução seria a mesma. Tanto é que, atualmente, é preciso que seja feita uma requisição antes sem o certificado onde o erro é esperado. Para só então repetir a requisição com os dados corretos. O mesmo poderia ser feito com o secret. A primeira sem o secret e esperar o erro. Depois repetir. Só seria MUITO mais simples de configurar, de implementar, de manter, além de ser mais compatível por ser menos dependente de configuração de ambiente.

O mTLS aí está servindo para "garantir" para o meu back-end que quem está chamando e mandando as requisições para meu webhook é um certificado gerado pela CA que está naquele cert disponibilizado no site da Gerencianet. O que estou "propondo", é que não houvesse essa restrição na chamada do webhook. Logo, o payload da requisição poderia não ser de confiança. Por isso, a chamada ao webhook seria apenas como um ping, como um push notification, contendo uma chave para que só então o webhook fosse, ativamente, buscar pela informação. É uma arquitetura diferente da que está. É como o Pag Seguro faz, por exemplo. E é tão seguro quanto, só que menos dependente de configuração junto à infra. Enfim... é só um pensamento. Vou ver como resolver de outra forma.

Ou seja, tenho que gerar outros certificados só pra ter dentro da máquina e poder receber os callbacks da GN?

Neste caso, não preciso declarar os certificados no apache, é isso?

Ter os certificados no LB para os acessos públicos.

Como eu faria isso? Até porque os certificados SSL do meu domínio vem do LoadBalance, eles não ficam armazenados na máquina.