Assinatura difere do calculado

O que significa esta rejeição

A SEFAZ recalculou a assinatura digital do XML usando os dados recebidos e o resultado não bateu com o <SignatureValue> enviado. Isso pode acontecer em dois pontos:

1. DigestValue inválido: o resumo SHA-1 da infNFe recebida não bate com o <DigestValue> declarado.
2. SignatureValue inválido: o resumo bate, mas a cifra RSA dele com a chave pública do certificado não confere.

Em ambos os casos, alguma transformação no XML aconteceu entre assinatura e envio (ou a assinatura foi gerada errado desde o início).

Causas mais comuns

• Modificação do XML após a assinatura (mudança de espaço em branco, troca de encoding, reformatação).
• Canonicalização errada: o leiaute exige c14n (Canonical XML 1.0), e o software usou outro algoritmo.
• Algoritmo de digest declarado como SHA-256 quando o gerador usou SHA-1.
• Caracteres especiais (acentos, ç, ã) processados com encoding diferente (Latin-1 vs UTF-8) entre assinatura e envio.
• Re-serialização do DOM pelo middleware antes da transmissão.
• Cópia do XML assinado de um sistema para outro com alteração silenciosa de quebras de linha.

Regra de validação oficial

A SEFAZ aplica o procedimento descrito na NT 2018.005 e no XML Signature 1.0 (W3C): canonicaliza o infNFe referenciado, calcula SHA-1, compara com <DigestValue>. Depois descriptografa <SignatureValue> com a chave pública do certificado e compara com o digest da <SignedInfo> canonicalizada.

Exemplo XML, antes (errado)

<NFe>
  <infNFe versao="4.00" Id="NFe31250612345678000199550010000158421000123456">
    <ide>...</ide>
    <emit>...</emit>
  </infNFe>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <Reference URI="#NFe31250612345678000199550010000158421000123456">
        <DigestValue>AAAAAAAAAAAAAAAAAAAAAAAAAAA=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>BBBBBBBBBBBBBBBBBBBBBBBBBBBB</SignatureValue>
  </Signature>
</NFe>

(o digest foi calculado sobre uma versão do XML que foi alterada depois)

Exemplo XML, depois (correto)

<NFe>
  <infNFe versao="4.00" Id="NFe31250612345678000199550010000158421000123456">
    <ide>...</ide>
    <emit>...</emit>
  </infNFe>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <Reference URI="#NFe31250612345678000199550010000158421000123456">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <DigestValue>QkN+e8d3Yj3ZxR0iN8mF7tYqkLY=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>HvWZ...assinatura_valida...==</SignatureValue>
  </Signature>
</NFe>

Passo a passo para corrigir

1. Garanta que o XML não sofre nenhuma alteração após a assinatura: sem pretty-print, sem mudança de encoding, sem re-serialização.
2. Verifique que a canonicalização usada é http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (Canonical XML 1.0).
3. Confirme que o algoritmo de digest é SHA-1 (declarado como rsa-sha1 no <SignatureMethod>).
4. Em integração com middleware (Java, .NET, Node), desabilite qualquer "prettify" automático na serialização do XML.
5. Reassine e reenvie. Se o erro persistir, gere uma assinatura local e compare byte a byte com a versão enviada para identificar onde está a divergência.

Como o FazendaNota previne

O FazendaNota transmite exatamente o mesmo XML que foi assinado, sem nenhuma alteração entre a assinatura e o envio. A canonicalização segue o padrão exigido (Canonical XML 1.0) e o conteúdo não é reescrito depois de assinado, eliminando a divergência entre o que foi assinado e o que a SEFAZ recalcula.

Rejeições relacionadas

• Rejeição 215, Falha no Schema XML
• Rejeição 280, Certificado Transmissor inválido
• Rejeição 291, Certificado Assinatura difere do Transmissor

Referência oficial

Esta rejeição está descrita no Anexo I - Leiaute e Regra de Validação do Manual de Orientação do Contribuinte (MOC) v7.0 da NF-e, publicado pelo CONFAZ. Texto integral em https://www.confaz.fazenda.gov.br/legislacao/arquivo-manuais/moc7-visao-geral.pdf