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

KeyInfo de protNFe: chave pública da autoridade assinante

<KeyInfo>nfeProc › protNFe › 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 dentro de protNFe/Signature apresenta o certificado público usado para verificar a assinatura da resposta. Esse ramo pertence à assinatura da autoridade responsável pelo protocolo, quando ela assina a mensagem.

Caminho desta página: /nfeProc/protNFe/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.

Quando KeyInfo precisa estar presente?

A Signature do protocolo é opcional, mas, se existir, o tipo SignatureType exige KeyInfo depois de SignatureValue. KeyInfo contém um X509Data com um X509Certificate e admite Id opcional. Não se cria um KeyInfo vazio quando a autoridade optou por não assinar.

O tipo fiscal reduzido não permite transportar aqui todas as formas alternativas do XMLDSig geral. A cadeia KeyInfo → X509Data → X509Certificate fornece o certificado final; a cadeia de confiança é analisada pelo verificador.

Declaração XSD do contexto.

De quem é a chave pública e o que ela verifica?

A chave pública vem do certificado da autoridade que produziu essa assinatura e deve verificar o SignatureValue associado ao SignedInfo do protocolo. O alvo é o infProt referenciado. A assinatura da nota usa outro ramo, outro alvo e pode usar outro certificado.

Não aplique automaticamente ao protocolo a comparação entre CNPJ-base/CPF do emitente e certificado que se usa no contexto da nota. Também não confunda o certificado do servidor TLS com este certificado de assinatura. A confiança exige confirmar a identidade e cadeia apropriadas ao serviço/autoridade.

XMLDSig: processamento e elementos.

Como analisar certificado ausente ou divergente?

Cenário: o XML contém assinatura de protocolo, mas falta KeyInfo. Isso é diferente de protocolo sem Signature: no primeiro caso o grupo presente está incompleto. Em outro cenário, um importador compara esse certificado com o do emitente e acusa divergência. Verifique se ele está usando a regra da assinatura da nota no ramo errado.

Não há XML completo com certificado fictício da SEFAZ. Preserve a resposta, confira estrutura, verificação criptográfica e confiança em etapas separadas, além da chave/ambiente/status. Não transplante o KeyInfo da nota para “consertar” o protocolo: o certificado precisa corresponder à assinatura original da autoridade.

MOC: resposta e protocolo, pp. 76–77.

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; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013.

Referência técnica para integração

XPath completo
/nfeProc/protNFe/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
Condicional

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.