NF-e e NFC-e
Como verificar a assinatura digital do XML da NF-e
Se uma mensagem de NF-e (55) ou NFC-e (65) falha na assinatura, preserve o arquivo enviado e peça uma verificação que separe referência, resumo do conteúdo, valor da assinatura e certificado. Essa sequência permite localizar o problema no assinador ou em uma etapa posterior, sem alterar dados fiscais por tentativa.
Se uma mensagem de NF-e (55) ou NFC-e (65) falha na assinatura, preserve o arquivo enviado e peça uma verificação que separe referência, resumo do conteúdo, valor da assinatura e certificado. Essa sequência permite localizar o problema no assinador ou em uma etapa posterior, sem alterar dados fiscais por tentativa.
Este guia orienta a investigação em qualquer emissor. A conferência criptográfica deve ser feita por ferramenta compatível com o perfil da NF-e e por suporte autorizado. Uma mensagem de assinatura, sozinha, não demonstra que o certificado venceu nem que a SEFAZ está indisponível.
Reconheça o objeto que foi assinado
A assinatura fiscal é uma estrutura XMLDSig com elementos que cumprem funções distintas. Na nota, o MOC define como alvo o grupo infNFe, identificado pelo atributo Id. Reference URI deve apontar para esse identificador dentro do documento, usando o prefixo “#”. Nos eventos e na inutilização, o alvo segue o leiaute da respectiva mensagem.
Não assuma que a assinatura recai sobre todo o lote ou sobre o envelope de comunicação. Primeiro determine se a tentativa envolveu autorização, inutilização ou um evento. Se o erro surgiu ao enviar um evento de uma nota autorizada, examine a mensagem do evento e preserve a nota original. MOC 7.0, Visão Geral, seções 4.2.4 e 5.
Separe digest e valor da assinatura
DigestValue é o resumo do conteúdo referenciado, calculado depois das transformações previstas. SignedInfo reúne essa referência, seu resumo e os métodos. SignatureValue contém a assinatura criptográfica da forma canonicalizada de SignedInfo. X509Certificate contém o certificado público do assinante; não é a chave privada.
A validação completa exige conferir tanto o resumo da referência quanto a assinatura de SignedInfo. Se apenas o conteúdo referenciado mudar, o digest pode falhar mesmo que a verificação isolada de SignatureValue ainda passe. A assinatura XML, como conjunto, não passou na validação. W3C, XML Signature, seção 3.2.
Canonicalização é a representação padronizada usada no cálculo. Nem toda diferença visual ou de serialização altera essa representação; por outro lado, uma mudança aparentemente pequena pode afetar o conteúdo validado. Comparar os arquivos a olho não substitui o teste criptográfico.
Guarde as cópias certas antes de mudar o processo
Registre código, mensagem, horário, serviço, modelo, ambiente, autorizador e versão do emissor. Informe se houve troca de certificado, biblioteca, integração ou atualização recente.
Solicite, quando disponíveis, a saída do assinador e a mensagem efetivamente transmitida. Preserve ambas sem regravar. Um XML regenerado depois do erro não comprova o que ocorreu naquela tentativa. O suporte pode comparar as etapas em ambiente controlado e registrar exatamente onde o resultado da validação mudou.
A Dynamicca explica os componentes da assinatura e a importância de preservar o conteúdo assinado. A TecnoSpeed também cita a manipulação posterior entre os pontos a investigar. Isso deve orientar a coleta de evidência, sem transformar qualquer caractere especial em causa presumida.
Organize a conferência técnica
Referência e estrutura
Confirme a existência do elemento esperado, a correspondência exata entre seu Id e Reference URI e as transformações exigidas. Um assinador XML genérico pode produzir uma assinatura válida segundo suas próprias opções e, ainda assim, incompatível com o subconjunto usado pela NF-e.
O artigo da rejeição 298 detalha o perfil: a regra F01 inclui ausência da referência e das transformações C14N e Enveloped. Valide a estrutura da mensagem e a assinatura com os schemas e a especificação do serviço utilizado. MOC, Anexo I, grupo F.
Conteúdo referenciado
Verifique se o resumo recalculado, depois das transformações aplicáveis, confere com DigestValue. Se falhar, investigue dados alterados, conteúdo perdido, seleção do elemento errado ou tratamento incompatível do XML.
Se o arquivo passa ao sair do assinador e falha depois, examine o percurso entre essas etapas: serialização, conversão de caracteres, preenchimento tardio e rotinas que reescrevem o documento. O objetivo é corrigir o processo que modificou o conteúdo, sem colar um novo digest no arquivo.
Valor da assinatura e certificado
Confira SignatureValue sobre SignedInfo canonicalizado, com a chave pública do certificado correspondente. A regra F02 do MOC trata da divergência desse valor e retorna 297. O artigo específico aprofunda essa rejeição; ela não deve ser descrita simplesmente como outro nome para DigestValue inválido.
Verifique também a confiança, o período de validade e as demais exigências do certificado. As rejeições 290 a 296 e o guia de certificados tratam dessa parte. O certificado de transmissão TLS participa de outra função, ainda que o sistema use o mesmo certificado para ambas.
Confira o perfil sem enfraquecer a segurança
O MOC 7 documenta RSA-SHA1, SHA-1 e as transformações próprias da assinatura fiscal. Essa descrição não é uma recomendação geral de criptografia. Não mude algoritmos por tentativa, não habilite algoritmos antigos globalmente e não reduza a proteção TLS. Uma incompatibilidade com a política de segurança deve ser encaminhada ao fornecedor para uma solução compatível com o serviço e sua versão.
A inclusão do certificado segue EndCertOnly: somente o certificado do usuário final na assinatura. Não acrescente a cadeia completa ou a LCR ao XML. Tampouco substitua manualmente X509Certificate por um certificado renovado; a assinatura precisa ser produzida de modo consistente pelo assinador.
Nos regimes específicos, identifique a assinatura correta. A NFF usa certificado da SVRS. O PAA acrescenta PAASignature, distinta da Signature fiscal, e exige assinatura qualificada ICP-Brasil do provedor. A NT 2026.001 v1.02b delimita o fluxo à NF-e modelo 55 com autorização centralizada na SVRS. Seu cronograma prevê produção em 05/10/2026, sem comprovar a habilitação de um usuário específico.
Exemplo hipotético
Uma integração assina corretamente uma NF-e, mas outra rotina completa a observação comercial dentro de infNFe depois da assinatura. Na cópia final, a verificação do conteúdo referenciado falha. A equipe identifica o preenchimento tardio e move essa etapa para antes da assinatura.
O emissor gera e assina novamente a mensagem rejeitada com os dados corretos. Não se recalcula apenas DigestValue: ele está dentro de SignedInfo, que também participa da assinatura. Se a forma canonicalizada de SignedInfo fosse alterada, a verificação de SignatureValue também falharia. O exemplo distingue os testes; não presume qual cStat toda implementação retornará primeiro.
Como encerrar a investigação
Peça um resultado que informe o arquivo testado, o perfil usado e qual etapa passou ou falhou. A Omie documenta a ocorrência de 297 também na CC-e; confirme sempre o serviço e o modelo, sem generalizar esse evento à NFC-e.
Depois da correção, valide a mensagem final e confira o retorno oficial da operação. Assinatura íntegra não garante aprovação nas demais regras. Se uma tentativa ficou sem resposta, consulte sua situação antes de reenviar. Preserve XMLs e protocolos já autorizados.
Não reformate, limpe caracteres ou repare manualmente um XML assinado. Use canais autorizados para dados fiscais e não envie senha, PIN, chave privada ou certificado com chave privada em mensagens de suporte.
Revisão documental: 09/10/2026. Orientação baseada em documentos, sem certificado real nem transmissão de teste. Algoritmos, serviços e fluxos especiais devem acompanhar futuras revisões oficiais.