KeyInfo de protNFe: chave pública da autoridade assinante
<KeyInfo>nfeProc › protNFe › ds:Signature › ds:KeyInfoRevisã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.
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.