Certificado digital de assinatura inválido ou ausente no XML

A rejeição 290 ocorre quando o certificado digital usado para assinar o XML da NF-e é inválido ou está ausente no elemento <Signature>. Isso bloqueia a transmissão imediatamente: nenhuma nota pode ser processada sem assinatura válida. A solução passa por verificar se o certificado A1 está corretamente instalado, dentro da validade e selecionado no sistema emissor.

O que significa esta rejeição

O elemento <Signature> do XML da NF-e contém, na tag <X509Certificate>, o certificado digital do emitente que assina o documento. A rejeição 290 é disparada pela regra E01 do Anexo I: o certificado presente nesse elemento é inválido, está ausente ou não pode ser interpretado pela SEFAZ.

É importante distinguir a 290 da rejeição 280, que trata do certificado da conexão TLS/transmissão (o certificado usado para estabelecer o canal HTTPS com o webservice). A 290 é o certificado que ASSINA o conteúdo do XML, não o que autentica a conexão. Ambas envolvem certificado, mas em camadas diferentes: a 280 impede o envio do lote e a 290 rejeita o documento já recebido pela SEFAZ.

Causas mais comuns

• Certificado A1 com arquivo .pfx/.p12 corrompido ou importado com senha errada, resultando em certificado ilegível no elemento <Signature>.
• Certificado expirado que foi mantido configurado no sistema emissor após o vencimento (nesse caso a SEFAZ dispara a 291, mas a 290 pode aparecer dependendo da versão do webservice).
• Certificado de uma empresa diferente configurado no sistema, causando incompatibilidade entre o CNPJ do emitente e o CNPJ do certificado.
• Assinatura gerada com biblioteca desatualizada que produz um <X509Certificate> malformado ou com encoding incorreto.
• Certificado recém-renovado mas ainda não substituído no sistema emissor, deixando o arquivo anterior (já inválido) em uso.

Regra de validação oficial

A regra E01 do Anexo I do MOC verifica, no processamento do lote, se o elemento <X509Certificate> dentro de <Signature> contém um certificado ICP-Brasil válido e interpretável. Se o certificado estiver ausente, corrompido ou não corresponder a um certificado emitido por autoridade certificadora reconhecida, a SEFAZ devolve o código 290.

Exemplo XML, antes (errado)

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#NFe43260512345678000195550010000001231000001230">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>VALOR_INVALIDO</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate></X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

(o elemento <X509Certificate> está vazio, certificado ausente)

Exemplo XML, depois (correto)

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#NFe43260512345678000195550010000001231000001230">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue>3g7hBmQxK2...base64hash...</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>MIIFgTC...valor base64 longo...</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate>MIIFgTC...certificado base64 completo...</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

(certificado ICP-Brasil válido presente em <X509Certificate>, assinatura gerada com a chave privada correspondente)

Passo a passo para corrigir

1. Acesse as configurações do sistema emissor e verifique qual certificado A1 está selecionado. Abra o arquivo .pfx/.p12 e confirme que ele abre com a senha configurada, sem erros.
2. Verifique a data de validade do certificado. Se já expirou, adquira um novo certificado A1 junto à sua autoridade certificadora e faça a troca no sistema antes de reenviar.
3. Confirme que o CNPJ inscrito no certificado é o mesmo do emitente da NF-e. Certificados para pessoas físicas (produtor rural com CPF) devem ter o CPF do titular.
4. Após confirmar o certificado correto, gere novamente o XML da NF-e (a assinatura precisa ser refeita com o certificado atualizado) e retransmita.

Como o FazendaNota previne

O FazendaNota valida o certificado A1 no momento do cadastro e antes de cada transmissão: verifica se o arquivo .pfx abre corretamente com a senha informada e se a data de validade está no futuro. Se o certificado estiver vencido ou ilegível, a plataforma bloqueia o envio e orienta a fazer a substituição antes de tentar transmitir, evitando que o lote chegue à SEFAZ com assinatura inválida.

Rejeições relacionadas

• Rejeição 291, Certificado de Assinatura com data de validade vencida
• Rejeição 297, Assinatura difere do calculado
• Rejeição 280, Certificado de transmissão inválido

Referência oficial

Esta rejeição está descrita no Anexo I - Leiaute e Regra de Validação do Manual de Orientação do Contribuinte (MOC) v7.0 da NF-e, publicado pelo CONFAZ. Texto integral em https://www.confaz.fazenda.gov.br/legislacao/arquivo-manuais/moc7-visao-geral.pdf