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

KeyInfo da NF-e: de onde vem a chave pública da assinatura

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

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

KeyInfo é o grupo da assinatura da NF-e que apresenta o certificado do assinante. O verificador extrai dele a chave pública para testar SignatureValue. Encontrar esse grupo não prova, por si só, quem assinou nem se o certificado é confiável.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:KeyInfo. 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.

Que estrutura o perfil NF-e exige?

No schema específico, KeyInfo ocorre uma vez, depois de SignatureValue. Ele contém um X509Data, que contém um X509Certificate. Seu atributo Id é opcional. A especificação geral XMLDSig permite outras formas de informação de chave; isso não libera KeyName, KeyValue ou RetrievalMethod no tipo reduzido usado pela NF-e.

O MOC orienta incluir apenas o certificado do usuário final, o padrão EndCertOnly. A cadeia de certificação precisa ser construída e validada; não se deve colocar certificados adicionais dentro desse grupo para contornar uma falha de confiança.

Declaração XSD do contexto.

Como distinguir certificado público de segredo e transporte?

X509Certificate representa o certificado público X.509 codificado em Base64. Ele não é um arquivo A1/PFX completo, uma senha nem a chave privada. A chave privada permanece no ambiente de assinatura ou no dispositivo próprio; o XML precisa apenas das informações públicas para verificar o resultado.

Também não se deve extrair o certificado da conexão TLS e supor que ele é o assinante do documento. A transmissão é outra etapa e pode ser realizada por responsável distinto. Para o XML assinado, compare a chave pública do certificado embutido com a assinatura e analise o vínculo exigido para o processo de emissão, inclusive PAA quando aplicável.

XMLDSig: processamento e elementos.

O grupo existe, mas a validação falha: qual a próxima conferência?

Cenário de integração: KeyInfo é lido e o certificado decodifica, mas a assinatura não confere. Teste o SignatureValue com a chave pública obtida e examine separadamente a referência e a canonicalização. Em outro cenário, a matemática confere, mas a cadeia não é confiável: o problema exige verificar a autoridade emissora, certificados de cadeia, validade e revogação, não trocar o conteúdo da nota.

Não há um XML completo desse grupo com certificado fictício. A estrutura necessária é KeyInfo → X509Data → X509Certificate, e o conteúdo operacional vem do certificado real utilizado. Uma string Base64 qualquer pode passar pela checagem de tipo e falhar no parser de certificados. Preserve o XML original e os resultados de cada etapa; a autorização de uso precisa ser conferida separadamente.

MOC: perfil de assinatura, pp. 53–56.

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; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013; Provedor de Assinatura e Autorização — NT 2026.001 v1.02b.

Referência técnica para integração

XPath completo
/nfeProc/NFe/ds:Signature/ds:KeyInfo
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:KeyInfoType
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.