Certificados para mTLS nos callbacks (webhook)

[renatofrota]

@dmkamers , @ninrod

No manual de iniciação, na seção 3.1 Requisitos de segurança obrigatórios, itens 2 e 9:

2. O PSP deve implementar o framework OAuth 2.0 (RFC6749) com TLS mútuo (mTLS - RFC 870582) para autenticação na API, conforme especificações abaixo:
   a. Os certificados digitais dos clientes da API poderão ser emitidos pelo próprio PSP ou por ACs externas, conforme definido por cada PSP. Não deverão ser aceitos certificados auto-assinados pelo cliente.
   (... outras exigências até alínea 'f')

9. Para a funcionalidade de webhooks, as notificações oriundas do PSP recebedor ao usuário recebedor trafegarão utilizando um canal mTLS.

Como redigido, a alínea a é específica ao item 2. e não se aplica ao item 9 (as exigências de b. a f., inclusive, nem poderiam ser aplicadas ao item 9 (webhooks), somente ao consumo da API).

Podem confirmar, por gentileza, se procede (o cliente pode determinar o certificado do seu interesse para que o PSP envie os callbacks ao webhook) ou se, na prática, há qualquer exigência a respeito de quais certificados são exigidos no canal mTLS dos webhooks, assim como no consumo da API (e, neste caso, caberia esclarecimento em versão posterior do documento em relação ao item 9)?

Obrigado.

[flaviolenz]

Ja argumentei em outros Posts, mas acho que tanto na autenticacao do cliente como do servidor, deveria ser aceito (alem de outros, se assim o PSP achar) certificados ICP-Brasil.
Simples de implementar do lado dos servidores, e simples do lado do cliente se ele optar por A1 (se optar por A3, problema dele lidar com os problemas, mas nao interefere do lado dos servidores).

[rubenskuhl]

Ja argumentei em outros Posts, mas acho que tanto na autenticacao do cliente como do servidor, deveria ser aceito (alem de outros, se assim o PSP achar) certificados ICP-Brasil.
Simples de implementar do lado dos servidores, e simples do lado do cliente se ele optar por A1 (se optar por A3, problema dele lidar com os problemas, mas nao interefere do lado dos servidores).

Uma utilidade disso que eu não tinha imaginado é para gateways multi-PSPs. Quem tem que lidar com muitos PSPs por enquanto tem que adicionar uma raiz de CA interna para cada PSP com que lide... já com uma CA que seja um fator comum entre PSPs, ele poderia adicionar apenas essa CA. E enquanto uns usam Globalsign, outros Digicert, outros Godaddy etc. etc., a ICP-Brasil tem mais chance de ser uma CA em comum entre todos os PSPs.

[ninrod]

@renatofrota , bom dia.

Como redigido, a alínea a é específica ao item 2. e não se aplica ao item 9 (as exigências de b. a f., inclusive, nem poderiam ser aplicadas ao item 9 (webhooks), somente ao consumo da API).

Podem confirmar, por gentileza, se procede (o cliente pode determinar o certificado do seu interesse para que o PSP envie os callbacks ao webhook) ou se, na prática, há qualquer exigência a respeito de quais certificados são exigidos no canal mTLS dos webhooks, assim como no consumo da API (e, neste caso, caberia esclarecimento em versão posterior do documento em relação ao item 9)?

De fato, a especificação não detalha sobre os certificados digitais utilizados no mTLS dos webhooks. Vamos analisar sua contribuição e provavelmente incorporar esse detalhamento no Manual de Iniciação do Pix. De todo modo, sugere-se que o cliente (que vai disponibilizar o webhook) utilize o mesmo certificado utilizado no mTLS com a API Pix, assim como o PSP.

[rturk]

@flaviolenz discordo da sua recomendação quanto ao uso da cadeia ICP-Brasil como mecanismo de autenticação mTLS, isto não é o objetivo do ICP-Brasil.

O objetivo do ICP-Brasil é certificar um Empresa ou Pessoa. Desta forma quem tem de posse de um certificado ICP-Brasil, pode assinar contratos, acessar e acionar poder publico, em nome da Empresa.
Logo um certificado A1 (que é um arquivo) ou A3 literalmente representam uma empresa. Quem tem posse do arquivo pode atuar em nome de uma Empresa.

De forma resumida: Certificado A1 deve ser visto como uma chave privada e não pública de uma Empresa, logo não é a melhor forma de se validar se a mensagem envida de uma empresa é válida.

Outro potencial problema: Esta proposta tornaria o servidor de webhooks um alvo em potencial de ataques. Inclusive você mesmo cita isto com o problema de lidar com A3.

Em uma escala menor: Qualquer empresa com vários desenvolvedores, ou programadores, internos ou externos teria que se certificar que nenhuma pessoa teve acesso ao arquivos do ICP-Brasil, já que no momento que vc tem acesso ao arquivo pode atuar em nome da empresa.

Lembrando que o mTLs , inclusive descrito na RFC 8705, prevê que somente as partes sejam conhecedoras dos seus certificados, logo cada parte gera seu certificado, como achar melhor, a assina suas mensagens os quais podem e devem ser trocados a qualquer tempo, diferente de um certificado A1 ou até mesmo A3 que precisam de papelada e ida presencial a um certificador.

[flaviolenz]

Desculpe Amigo,

Sugiro vc estudar um pouco melhor como funciona essa questao dos certificados.
Espero que vc nao cause confusao na cabeça de quem nao entende bem, afinal, ninguem precisa mesmo dominar tudo.

@flaviolenz discordo da sua recomendação quanto ao uso da cadeia ICP-Brasil como mecanismo de autenticação mTLS, isto não é o objetivo do ICP-Brasil.

O objetivo do ICP-Brasil é certificar um Empresa ou Pessoa. Desta forma quem tem de posse de um certificado ICP-Brasil, pode assinar contratos, acessar e acionar poder publico, em nome da Empresa.
Logo um certificado A1 (que é um arquivo) ou A3 literalmente representam uma empresa. Quem tem posse do arquivo pode atuar em nome de uma Empresa.

Objetivo da ICP-Brasil eh ser uma AC raiz, assim como Verisign, por exemplo, so que acreditada como certificadora para servicos publicos.
Ate ai nao ha nenhum conflito para usar como autenticação de cliente.

De forma resumida: Certificado A1 deve ser visto como uma chave privada e não pública de uma Empresa, logo não é a melhor forma de se validar se a mensagem envida de uma empresa é válida.

Qq certificado, em algum momento, eh chave privada + publica... nao existe isso que vc falou.
A parte da chave publica, inclusive, eh pública e vai na assinatura de toda NFe emitida pela empresa. Tá lá no XML, disponível pra qualquer um que compre uma mercadoria da empresa.

Outro potencial problema: Esta proposta tornaria o servidor de webhooks um alvo em potencial de ataques. Inclusive você mesmo cita isto com o problema de lidar com A3.

Os webhook serao normalmente nos servidores do ERP, que ja têm os certificados ICPBrasil pra emitir NFe ou NFCe, entao, nao vejo risco adicional.
Inclusive, em teoria, só quem sabe do endereco de meu webhook sou eu e meu PSP (fui eu quem fiz a chamada ao entrypoint /webhook). Não tenho motivo pra divulgar isso pra qq hacker.

Mas, se isso eh realmente uma issue pra empresa, esta faria a opcao por um certificado assinado pelo PSP, que parece ser a unica pratica adotada hoje.

Em uma escala menor: Qualquer empresa com vários desenvolvedores, ou programadores, internos ou externos teria que se certificar que nenhuma pessoa teve acesso ao arquivos do ICP-Brasil, já que no momento que vc tem acesso ao arquivo pode atuar em nome da empresa.

Vale a mesma pro argumento anterior.
Se seu programador já tem acesso a chave pra emitir NFe, nenhum risco adicional.

Lembrando que o mTLs , inclusive descrito na RFC 8705, prevê que somente as partes sejam conhecedoras dos seus certificados, logo cada parte gera seu certificado, como achar melhor, a assina suas mensagens os quais podem e devem ser trocados a qualquer tempo, diferente de um certificado A1 ou até mesmo A3 que precisam de papelada e ida presencial a um certificador.

Aqui nao entendi nada... mTLS eh pra garantir sigilo e autenticidade dos dois lados. Sigilo vc garante com qualquer CA, inclusive self-signed. Mas, no Brasil, nada mais garantido como autêntico do que comprovado pela ICP-Br.

Chave privada do A1 e A3, em teoria, só eh conhecido pela empresa (a nao ser que a propria Entidade Certificadora esteja trapaceando na hora de gerar o par de chaves nos softwares que elas exigem pra emitir o certificado).

Enfim... nenhum risco adicional em FRANQUEAR o correntista/plataforma/integrador/gateway a usar seu certificado ICPBrasil.

[renatofrota]

Aqui nao entendi nada... mTLS eh pra garantir sigilo e autenticidade dos dois lados. Sigilo vc garante com qualquer CA, inclusive self-signed.

Concordo 100%. A exigência de CA "publicamente reconhecida" só faz sentido numa comunicação TLS padrão, onde A precisa que C (a CA) "avalize" que B é quem ele diz ser. Se Ae B trocaram chaves entre si em acordo mútuo, a figura de C é totalmente desnecessária. Não importa nada quem assinou os certificados.

[lfabiotargino]

Ola, estou precisando implementar essa autenticação com mTLS e um certificado ICP Brasil para um webhook do pix. Alguem estaria disponível para freelancer?