Signature da NF-e: estrutura, certificado e validação da assinatura

Signature, filha de NFe, reúne a assinatura digital XML da NF-e/NFC-e. Sua referência identifica infNFe, onde estão os dados fiscais assinados. No XML processado, ela permanece dentro de NFe; o protocolo fica em outro ramo, protNFe.

Caminho desta página: /nfeProc/NFe/ds:Signature. 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 precisa existir dentro de Signature?

O tipo TNFe exige uma assinatura. O schema específico exige, nesta ordem, um SignedInfo, um SignatureValue e um KeyInfo. SignedInfo contém o método de canonicalização, o método de assinatura e uma referência; esta contém transformações, método de resumo e valor do resumo. KeyInfo/X509Data/X509Certificate transporta o certificado público usado na verificação. O atributo Signature/@Id é opcional e não é a chave de acesso.

A nota é assinada em infNFe, identificado por seu Id; a Reference/@URI deve corresponder a esse identificador precedido por #. A localização de Signature fora de infNFe não muda o alvo. O envelope nfeProc inteiro e o protocolo não ficam automaticamente cobertos por essa referência.

Declaração XSD do contexto.

Como os componentes produzem verificações diferentes?

Primeiro, o verificador resolve a referência ao infNFe correto e aplica as transformações previstas: enveloped-signature e Canonical XML 1.0. Em seguida calcula SHA-1 desses dados e compara o resultado com DigestValue, codificado em Base64. Separadamente, canonicaliza SignedInfo e verifica SignatureValue segundo RSA-SHA1 com a chave pública do certificado. Não se compara SignatureValue diretamente com DigestValue.

O certificado precisa ser analisado quanto à cadeia de confiança, período de validade, revogação e vínculo aplicável. O certificado de transmissão TLS identifica a conexão e pode representar outro responsável; ele não substitui o certificado contido na assinatura. Na emissão por PAA, a NT 2026.001 v1.02b prevê assinatura qualificada do provedor e a assinatura avançada do emitente em infPAA; não se deve aplicar a comparação comum de CNPJ ao PAA ignorando a exceção F03 para SVRS com infPAA.

XMLDSig: processamento e elementos.

Como investigar uma falha sem modificar o original?

Exemplo de diagnóstico: a referência encontra um único infNFe, os algoritmos correspondem ao perfil, mas o resumo recalculado difere. Isso exige comparar o XML preservado no momento da assinatura com o recebido: textos, espaços em conteúdo, namespaces e serialização podem explicar mudança nos bytes canonicalizados. Não basta trocar o certificado.

Em outro cenário, o resumo confere, mas a verificação de SignatureValue falha. Investigue a canonicalização de SignedInfo, o certificado selecionado e o valor efetivamente gravado. F01/298 identifica divergência do padrão e F02/297 divergência da assinatura calculada no processamento fiscal; o código e a mensagem originais devem guiar a triagem. Validade XSD não executa essas verificações.

Não há neste artigo um XML completo de assinatura: ele exigiria dados originais, certificado e operação criptográfica correspondente. Preserve o arquivo autorizado; a correção de um gerador deve ocorrer em um cenário controlado, sem substituir partes de um documento emitido. A autorização e a situação atual também precisam de comprovação própria na resposta e consulta oficial.

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; Leiaute da NF-e e protocolo — PL_010f_v1.04 / leiauteNFe_v4.00.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; Provedor de Assinatura e Autorização — NT 2026.001 v1.02b; Portal Nacional — Notas Técnicas vigentes — captura 15/10/2026.