Emissão de NFe com Certificado na Nuvem RemoteID

[tdpsistemas]

Boa tarde.

Um cliente nosso adquiriu um certificado A3 da Certisign na nuvem chamado RemoteID (https://www.certisign.com.br/certificado-digital/remoteid). Configuramos no sistema, ele consegue validar a NFe, porém ao transmitir ele retorna o seguinte erro: Rejeição: Assinatura difere do calculado. Cstat: 297

Em conversa com o suporte da Certisign, ele nos informaram que ele trabalha igual ao A3. Teoricamente era para funcionar normal no sistema com o Acbr.

Alguém já passou por isso? Alguma dica?

Obrigado.

[Breno Luiz]

Forneça para gente o XML da NF-e se possível. Esse erro pode ser ocasionado por espaço no início e ou fim de informações do XML, como por exemplo, espaço na razão social do cliente, ou na descrição do produto.

[Juliana Tamizou]

Bom dia.

Seu problema foi resolvido com o post do Breno?

Att.

[Marcelo Calvi Belanga]

Em 22/01/2019 at 16:52, tdpsistemas disse:

Boa tarde.

Um cliente nosso adquiriu um certificado A3 da Certisign na nuvem chamado RemoteID (https://www.certisign.com.br/certificado-digital/remoteid). Configuramos no sistema, ele consegue validar a NFe, porém ao transmitir ele retorna o seguinte erro: Rejeição: Assinatura difere do calculado. Cstat: 297

Em conversa com o suporte da Certisign, ele nos informaram que ele trabalha igual ao A3. Teoricamente era para funcionar normal no sistema com o Acbr.

Alguém já passou por isso? Alguma dica?

Obrigado.

Olá... estou com mesmo problema. Já verifique e removi tudo que poderia ocasionar o mesmo cstat.

Anexo todos os logs...

3-env-lot.xml

3-rec.xml

351005282376018-ped-rec.xml

351005282376018-pro-rec.xml

[BigWings]

2 horas atrás, Marcelo Calvi Belanga disse:

Olá... estou com mesmo problema. Já verifique e removi tudo que poderia ocasionar o mesmo cstat.

Também está usando o certificado digital "RemoteID"?

2 horas atrás, Marcelo Calvi Belanga disse:

3-env-lot.xml

O campo SignatureValue do XML está realmente estranho, com uma sequência gigante de "AAAAAAA...", estranho que removendo essa sequência o validador acusa a assinatura como válida.

[Marcelo Calvi Belanga]

Exatamente @BigWings. Por isso que escrevi neste post.

Verifiquei essa sequência gigante de AAAAA.

Não tenho ideia do que fazer! 

[Marcelo Calvi Belanga]

Bom dia....

Ainda estou com o problema.

Sistema é Windows 10 recém formatado e atualizado.

Ninguém mais com o mesmo problema?

[Breno Luiz]

Em 15/02/2019 at 18:14, Marcelo Calvi Belanga disse:

Olá... estou com mesmo problema. Já verifique e removi tudo que poderia ocasionar o mesmo cstat.

Anexo todos os logs...

3-env-lot.xml

3-rec.xml

351005282376018-ped-rec.xml

351005282376018-pro-rec.xml

Olá Marcelo. Antes de prosseguir com o problema, vamos corrigir alguns outros probleminhas da nota, ( que talvez possam ocasionar o erro de assinatura ). Veja que a finalidade da sua NF-e está como devolução, porém não foi referenciada nenhuma NF-e de devolução, e também não foi utilizado nenhum CFOP de devolução.

[Marcelo Calvi Belanga]

2 horas atrás, Breno Luiz disse:

Olá Marcelo. Antes de prosseguir com o problema, vamos corrigir alguns outros probleminhas da nota, ( que talvez possam ocasionar o erro de assinatura ). Veja que a finalidade da sua NF-e está como devolução, porém não foi referenciada nenhuma NF-e de devolução, e também não foi utilizado nenhum CFOP de devolução.

Eu já havia verificado isso, mas para tirarmos a dúvida, segue os novos XML com a emissão normal.

A rejeição 297 continua.

Não estou com o ACBr atualizado, a última atualização foi em 28/11/2018 15968, será que pode ser isso?

Estou protelando a atualização por causa dos refactorys que foram feitos, estou com tempo meio curto.

3-env-lot.xml

3-rec.xml

351005285224766-ped-rec.xml

351005285224766-pro-rec.xml

[Juliana Tamizou]

Boa tarde.

É interessante que você atualize seus fontes e  refaça o teste.

Att.

[tdpsistemas]

Boa tarde,

O cliente acabou trocando o certificado digital para A1 normal de arquivo. Com isso não consegui testar mais nada, se aparecer outro certificado deste tipo vamos testar, mas estamos orientando a não usar este modelo de certificado.

Obrigado. 

[Marcelo Calvi Belanga]

1 hora atrás, Juliana Tamizou disse:

Boa tarde.

É interessante que você atualize seus fontes e  refaça o teste.

Att.

Boa tarde Juliana.

Atualizado os fontes até a revisão atual 16570, ajustado todos os itens que foram refatorados.

E a rejeição 297, com certificado RemoteID continua.

Olha que estranho a assinatura em <SignatureValue>

3-env-lot.xml

3-rec.xml

351005285676938-ped-rec.xml

351005285676938-pro-rec.xml

1 hora atrás, tdpsistemas disse:

Boa tarde,

O cliente acabou trocando o certificado digital para A1 normal de arquivo. Com isso não consegui testar mais nada, se aparecer outro certificado deste tipo vamos testar, mas estamos orientando a não usar este modelo de certificado.

Obrigado. 

Vou propor para o cliente fazer isso também.

[Marcelo Calvi Belanga]

Boa tarde a todos!!!!

Devido a urgência do cliente, indiquei ao mesmo comprar o certificado A1 e no memo momento após a instalação, sem nenhuma configuração adicional a NFe foi transmitida e autorizada, ou seja, esse certificado RemoteID não funciona para emissão de NFe com ACBr pelo menos até o momento.

Se houver interesse por parte dos desenvolvedores (moderadores), posso doar o valor para aquisição do mesmo para testes e ajustes!

[Daniel Simoes]

Olá Marcelo,

Obrigado por se dispor a ajudar... vou analisar a questão...

[Daniel Simoes]

@Rafael Dias e @EMBarbosa... notaram que a existência de exatos 1024 bytes de "NUL",  no inicio da String da assinatura...  Pode ser algo no retorno do driver WinCrypt desse certificado...

Por favor substitua a Unit em Anexo, (rode novamente o ACBrInstall)... e verifique se a assinatura ficou correta  

Você pode gerar um XML e testar a assinatura do mesmo, usando o Demo do  ACBrNFe

 

ACBrDFeWinCrypt.pas

[Marcelo Calvi Belanga]

13 horas atrás, Daniel Simoes disse:

@Rafael Dias e @EMBarbosa... notaram que a existência de exatos 1024 bytes de "NUL",  no inicio da String da assinatura...  Pode ser algo no retorno do driver WinCrypt desse certificado...

Por favor substitua a Unit em Anexo, (rode novamente o ACBrInstall)... e verifique se a assinatura ficou correta  

Você pode gerar um XML e testar a assinatura do mesmo, usando o Demo do  ACBrNFe

 

ACBrDFeWinCrypt.pas 48 kB · 0 downloads

Olá @Daniel Simoes, vou verificar com o cliente se ainda está com o certificado em mãos, pois, o mesmo disse que havia conseguido estornar a compra.

Se estiver efetuarei o teste no Demo e em minha aplicação.

[Marcelo Calvi Belanga]

@Daniel Simoes, infelizmente meu cliente já cancelou o certificado.

Se forem prosseguir com os testes fim de homologar o ACBr nessa plataforma, estou à disposição para o investimento, seja a doação do valor para a compra ou a compra em meu nome para testes.

Aguardo um posicionamento.

[Daniel Simoes]

Eu acho que o problema foi sanado, com o ajustes proposto... pois removendo os 1024 bytes "NUL", no inicio da String da Assinatura, ela ficava válida... vou subir para o SVN...

[Daniel Simoes]

Creio que esse Bug foi morto...

[Marcelo Calvi Belanga]

Muito obrigado @Daniel Simoes, na minha pr´poxima renovação de certificado, farei esse RemoteID, ai vamos ter certeza.

Acredito que o post pode ser encerrado.

[Vinicius Rodrigues_28287]

Salvou meu dia , alterei o fonte e compilei resolveu.

Obrigado!

[Paulo R G Oliveira]

Bom dia Sr's,

Após a atualização dos fontes do ACBR no dia 21/02/2019 aleatoriamente meu sistema passou a apresentar a rejeição 297: Assinatura difere do calculado, como o cliente fatura a noite foi difícil simular a situação em um ambiente com o problema, porém após muitos testes nos deparamos com o cenário e podemos enfim debugar. Observamos que a rejeição se dava por ocorrência de problema na unit trunk2\Fontes\ACBrDFe\ACBrDFeWinCrypt.pas. Vimos no log de alteração do SVN, uma implementação para atender a este tópico, como antes nunca havia ocorrido isso, comentamos o código implementado e a nota parou de apresentar o problema. Aparentemente o problema se originou com a implementação  deste código:

  function TDFeWinCrypt.CalcHash(const AStream: TStream; const Digest: TSSLDgst;
  const Assina: Boolean): AnsiString;

        ...

        if Assina then
        begin
          if CryptSignHash(mHash, dwKeySpec, Nil, 0, @mHashBuffer, mBytesLen ) then
          begin
            // MS CryptoAPI retorna assinatura em "Little Endian bit string", invertendo...
            Result := '';
            {while (mBytesLen > 0) and (mHashBuffer[mBytesLen-1] = #0) do
              Dec(mBytesLen);} 

            for I := mBytesLen downto 1 do
              Result := Result + mHashBuffer[I-1];
          end
          else
            raise Exception.Create('CryptSignHash');
        end

Estou anexando o XML com o erro para mais detalhes. Se alguém tiver alguma ideia do porque do surgimento deste problema, favor nos ajudar.

Interagi neste tópico para evitar abrir outro visto que esta ainda está em aberto.

Desde já agradeço.

Assintaura.xml

[Daniel Simoes]

3 horas atrás, Paulo R G Oliveira disse:

Estou anexando o XML com o erro para mais detalhes. Se alguém tiver alguma ideia do porque do surgimento deste problema, favor nos ajudar.

Verificando...

[Daniel Simoes]

Apliquei um pequeno ajuste, para evitar que o Hash computado não fique com menos de 256 bytes

Rev. 16716, no SVN

[Paulo R G Oliveira]

Obrigado pela atenção.

 

Irei testar.

 

Editado 18 Março, 2019 por Paulo R G Oliveira