Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mais uma vez... "erro Hash está Errado" #195

Closed
batalhadematos opened this issue Dec 28, 2021 · 2 comments
Closed

Mais uma vez... "erro Hash está Errado" #195

batalhadematos opened this issue Dec 28, 2021 · 2 comments
Labels
question Further information is requested

Comments

@batalhadematos
Copy link

Estimados,
Boa tarde a todos.

Hoje o dia foi mesmo por causa deste issue estranho que estou a ter no hash code de uma factura.

Já revi tudo:

  • Verifiquei os hash gerados com o openssl e tudo me parece ok (verificados com sucesso);
  • Revi os elementos usados para a assinar o documento (data, data/hora, número do documento, gross total, etc.)
  • Revi o tamanho de cada hash para garantir que por qualquer motivo algum não tenha passado com menos de 172 caracteres;

Tudo me parece funcional ...excepto mesmo no portal do produtor.

Anexo alguns ficheiros para quem poder testar e ajudar.

Ao passar o ficheiro "original.xml", obtenho o erro no hash da factura com o número FT 2021/18.

Depois de rever tudo, resolvi "eliminar alguns documentos do ficheiro saft", gerar o ficheiro "alterado.xml" e deixar apenas aqueles documentos que formam a cadeia de verificação do hash dessa factura.

No caso deixei apenas as facturas:

  • "FT 2021/17";
  • "FT 2021/18" (a que tem o problema);
  • e apenas para testar a "FT 2021/19";
  • Ajustei manualmente os elementos NumberOfEntries, TotalDebit e TotalCredit para reflectir esta alteração.

O conteúdo dos nós de cada factura são exactamente iguais ao que está no ficheiro "original.xml" e acontece que, com esta alteração, não existe mais o erro do hash...

...e como resultado, perdi-me!

Algumas notas:

  • Pelo entendimento da cadeia de assinaturas, o erro deveria estar na mensagem usada para assinar a FT 2021/18, mas acontece que a mensagem a assinar foi igual nos dois ficheiros;
  • O hash da FT 2021/17 é o início da cadeia no ficheiro "alterado.xml" e é normal que este não seja testado;
  • Sendo que este mesmo hash existe no ficheiro "original.xml" e é usado para assinar a factura "FT 2021/18" nos dois ficheiros, o erro deveria existir nos dois ficheiros;
  • Ao testar gerar os hash com o openssl, obtenho o mesmo resultado e estas são verificadas com sucesso.

Preciso entender o porquê que no ficheiro original o erro permanece e no ficheiro alterado passa tudo bem...

Alguém pode testar por favor e olhar para ver se me passou alguma coisa?

Anexo:

  • original.xml: Ficheiro com o erro;
  • alterado.xml: ficheiro manualmente alterado para efeitos de testes;
  • chavepublica.txt: Chave pública para quem fizer o favor de testar;
  • sha_hash.sign.txt: Exemplo do hash gerado pelo openssl e que foi bem validado;
  • sha_hash.b64.txt: Conteúdo legível do ficheiro já em base64 (que é igual ao da FT 2021/18);

Agradeço a todos

Abraço

original.xml.txt
alterado.xml.txt
chavepublica.txt
sha_hash.sign.txt
sha_hash.b64.txt

@batalhadematos batalhadematos added the question Further information is requested label Dec 28, 2021
@sofiamribeiro
Copy link

A fatura 17 tem source billing I
As restantes têm source billing P
Como no ficheiro alterado a 17 é a 1ª provavelmente esta diferença é ignorada durante a validação do hash.
Se colocar source billing P na 17 no ficheiro original já não dá erro.
Espero que seja esta a razão 😔

@batalhadematos
Copy link
Author

@sofiamribeiro,
Genial.
Salvou a minha noite e esse "I" esteve aí o dia todo.
Realmente o cliente esteve a fazer umas recuperações de documentos emitidos manualmente e existe um diário/série para este efeito. Com certeza este ficou como "I", mas no diário errado...

O meu muito obrigado

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants