Rejeição 297: assinatura XML difere do valor calculado

A rejeição 297, regra F02, informa que o valor de SignatureValue difere do calculado na verificação. A estrutura pode estar presente e o certificado pode ser reconhecido, mas a conferência criptográfica não fecha para o conteúdo e a assinatura recebidos.

Nesta página:

• Quais partes precisam ser verificadas juntas?
• Exemplo: conteúdo alterado depois de assinado
• Toda diferença de escrita invalida a assinatura?
• Como distinguir 297, 298 e o SignatureValue de infPAA?

Quais partes precisam ser verificadas juntas?

A assinatura relaciona o elemento referenciado, suas transformações, DigestValue, SignedInfo, SignatureValue e a chave pública do certificado incorporado. Validar apenas a sintaxe Base64 de SignatureValue não comprova sua integridade.

Use um verificador compatível com o perfil fiscal, sobre a mensagem exata enviada. Confira a referência ao Id correto e a validade do digest e da assinatura. Preserve os resultados dessas etapas separadamente; o código 297 não identifica sozinho qual rotina ou alteração causou a divergência.

Fontes: MOC Anexo I, regra F02.

Exemplo: conteúdo alterado depois de assinado

Imagine que a aplicação assine a nota e, depois, uma rotina acrescente ou altere uma informação dentro do elemento assinado. A tela pode mostrar o valor final, enquanto a assinatura foi calculada sobre outra versão. Compare a saída da assinatura e a entrada efetiva da transmissão, em ambiente protegido.

Outro cenário é incorporar um certificado cuja chave pública não corresponde à chave que produziu a assinatura. A investigação deve provar a relação correta, sem copiar certificados ou valores entre arquivos. Corrija a etapa responsável e regenere pelo fluxo legítimo.

Fontes: MOC Anexo I, regra F02.

Toda diferença de escrita invalida a assinatura?

Não se deve generalizar. A canonicalização existe para estabelecer uma representação de conferência. Algumas diferenças de escrita podem ser normalizadas; alterações no texto e em outros conteúdos relevantes podem permanecer e mudar o resultado. Um formatador que insere espaços entre elementos pode modificar nós de texto.

Compare as representações e o resultado do verificador, em vez de adivinhar pelo aspecto visual. Não reserialize ou compacte um XML já assinado como tentativa de correção. A geração final precisa obedecer ao perfil e manter o conteúdo protegido pela assinatura.

Fontes: MOC Anexo I, regra F02.

Como distinguir 297, 298 e o SignatureValue de infPAA?

A 298 verifica o padrão da assinatura, incluindo Reference e transformações; a 297 verifica seu valor calculado. A NT 2026.001 inclui no processo PAA uma assinatura avançada em infPAA, além da Signature qualificada. O nome SignatureValue em dois contextos não torna as regras intercambiáveis.

Após corrigir a causa, valide schema e criptografia sobre os bytes finais. Não reescreva documento autorizado e não deduza rejeição definitiva de uma tentativa anterior sem resposta. Consulte sua situação antes de repetir o envio. Verificação local bem-sucedida ainda não comprova autorização fiscal.

Fontes: MOC Anexo I, regra F02; NT 2026.001 - Provedor de Assinatura e Autorização.

Limite do exemplo e preservação dos dados

A reprodução criptográfica requer o XML assinado original, seu certificado e a identidade do documento em ambiente protegido. Não se fabrica assinatura operacional; os cenários textuais mostram como localizar a divergência. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.

Fontes oficiais

• MOC 7.0 — Anexo I, versão 7.00. p. 74, regra F02, código 297; p. 74, regras próximas de assinatura.
• MOC 7.0 — Visão Geral, versão 7.00. pp. 52–56, §§4.2.3–4.2.6: certificado e assinatura, EndCertOnly, perfil XMLDSig, validação e LCR.
• NT 2026.001 - Provedor de Assinatura e Autorização, versão 1.02b. pp. 3–5, versão/cronograma e duas assinaturas; pp. 10–11, infPAA e F03; p. 14, ZG04-10 separado da Signature qualificada.