X509Certificate da NF-e: certificado público em Base64

X509Certificate contém o certificado público X.509 do assinante, codificado em Base64. Ele é encontrado dentro de Signature/KeyInfo/X509Data da NF-e. Sua função é fornecer material público para verificar a assinatura, e não guardar a chave privada.

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

Base64 válido já é um certificado válido?

Não. O tipo XSD é base64Binary: ele verifica a representação binária, sem interpretar a estrutura de um certificado X.509. Depois da decodificação, os bytes precisam ser analisados como certificado, cuja chave pública deve servir à verificação de SignatureValue. Titular, emissor, período de validade, usos permitidos e cadeia exigem etapas próprias.

Como contraexemplo didático, a sequência textual AA== representa apenas um byte zero. Ela não é certificado X.509 e não pode ser usada como certificado de uma NF-e. O fato de ser Base64 não cria titular, cadeia ou assinatura.

Declaração XSD do contexto.

De onde vem o conteúdo e que dados não pertencem ao campo?

O software de assinatura usa o certificado associado à chave privada autorizada para assinar. No XML entra apenas o certificado público em sua codificação apropriada, sem cabeçalhos PEM, senha ou arquivo PFX/P12 inteiro. A chave privada não é publicada aqui. O perfil do MOC inclui apenas o certificado final; não é uma lista de toda a cadeia.

O certificado da conexão TLS pode representar o transmissor e ser diferente do assinante. Na emissão normal, o vínculo CNPJ-base/CPF deve respeitar as regras aplicáveis. Na emissão por PAA, a NT 2026.001 v1.02b prevê certificado ICP-Brasil do provedor na assinatura qualificada, com exceção F03 na SVRS quando há infPAA; não se trata de substituir o certificado do emitente por tentativa.

XMLDSig: processamento e elementos.

Como separar as causas de erro?

Se a decodificação falha, examine truncamento, caracteres e origem da exportação. Se Base64 decodifica mas não forma certificado, investigue o dado inserido e o parser. Se a assinatura matemática confere, porém a cadeia, validade ou revogação falham, registre cada resultado separadamente: trocar o texto do certificado no XML não resolve essas verificações.

O MOC separa os grupos A, do transmissor TLS, E, do certificado de assinatura, e F, da assinatura digital. Preserve a mensagem original para saber qual camada falhou. Não se oferece XML completo com certificado inventado; use uma cópia controlada do original e evite divulgar dados desnecessários do titular. Um resultado criptográfico favorável ainda não comprova autorização ou situação atual.

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; 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; XML Schema Part 2: Datatypes — Second Edition, 28/10/2004; Provedor de Assinatura e Autorização — NT 2026.001 v1.02b; Portal Nacional — Notas Técnicas vigentes — captura 15/10/2026.