Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Suplemento, assinatura e protocolo

SignatureValue da NF-e: valor da assinatura e divergência do calculado

<SignatureValue>nfeProc › NFe › ds:Signature › ds:SignatureValue

Revisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

SignatureValue guarda em Base64 o resultado da assinatura criptográfica de SignedInfo canonicalizado. É gerado pelo mecanismo de assinatura com a chave privada correspondente ao certificado; não é um código preenchido manualmente.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignatureValue. O alias ds neste XPath representa o namespace http://www.w3.org/2000/09/xmldsig#; ele permite localizar o elemento, mas não exige esse prefixo na serialização fiscal.

O que é assinado para formar esse valor?

A referência de SignedInfo identifica infNFe; os dados referenciados passam pelas transformações e por SHA-1, formando DigestValue. Esse resumo integra SignedInfo. A assinatura RSA-SHA1 é aplicada sobre a representação canonicalizada de SignedInfo, e seu resultado binário é representado em SignatureValue.

Por isso o resumo do conteúdo e o valor da assinatura são diferentes. X509Certificate transporta a chave pública/certificado, enquanto SignatureValue contém o resultado criptográfico. Nenhum deles é o número de protocolo emitido pela SEFAZ.

Declaração XSD do contexto.

Como ler a estrutura sem simular uma assinatura?

No tipo fiscal, há um SignatureValue obrigatório depois de SignedInfo, com conteúdo base64Binary e Id opcional. O schema não assegura que os bytes representam uma assinatura válida para aquela chave e mensagem.

Não há neste artigo XML completo nem assinatura operacional sintética. Uma cadeia Base64 escolhida arbitrariamente poderia satisfazer o tipo e ainda ser rejeitada pelo verificador. O resultado correto só pode ser produzido pelo processo criptográfico sobre os dados efetivamente assinados.

XMLDSig: processamento e elementos.

Como investigar a rejeição 297 ou uma falha local?

A regra F02 do MOC descreve a rejeição 297 quando SignatureValue difere do valor calculado. Para investigar, preserve o XML transmitido e o assinado, identifique o certificado realmente inserido e verifique primeiro cada referência. Depois confira a canonicalização de SignedInfo, o método declarado e o resultado de verificação com a chave pública.

Cenário 1: o digest da referência já difere. Há um problema anterior à verificação final, como alteração dos dados referenciados ou transformação incompatível. Cenário 2: o digest confere, mas SignatureValue falha. Examine diferenças de SignedInfo, chave/certificado e saída do assinador. Não “corrija” colando outro valor ou substituindo certificado no arquivo recebido. Depois de ajustar um gerador, valide em cenário controlado; arquivo autorizado deve permanecer preservado.

MOC: validações de assinatura.

Fontes e contexto

Schema específico XMLDSig da NF-e — PL_010f_v1.04 / xmldsig-core-schema_v1.01.xsd; MOC — Visão Geral — 7.0; MOC — Anexo I, Leiaute e Regras de Validação — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013.

Referência técnica para integração

XPath completo
/nfeProc/NFe/ds:Signature/ds:SignatureValue
Namespace
http://www.w3.org/2000/09/xmldsig#
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
ds:SignatureValueType · base64Binary
Preenchimento no catálogo
Obrigatório

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.