Rejeição 290: como investigar um certificado de assinatura inválido

A rejeição 290 indica que o certificado apresentado na assinatura digital não atende à validação exigida. Identifique qual certificado foi incluído no XML efetivamente enviado e peça a conferência de sua presença, versão, perfil e finalidade de uso. O diagnóstico deve partir da assinatura rejeitada, mesmo que a tela de configuração mostre um certificado aparentemente correto.

Mensagem: “Rejeição: Certificado Assinatura inválido”.

Essa descrição não identifica uma única causa. Também não significa que qualquer problema de certificado deva ser tratado como 290: vencimento, revogação, cadeia de confiança e identificação fiscal têm verificações próprias.

O que a regra 290 verifica

A regra E01 do MOC pertence ao Grupo E, dedicado ao certificado digital da assinatura. Ela contempla certificado ausente na mensagem, versão diferente de 3 e incompatibilidades no perfil e nos usos da chave. A presença do certificado também pode ser verificada pelo schema, portanto a ordem em que uma falha é detectada pode mudar o retorno apresentado. MOC 7.0, Anexo I, seção 4.1.4.

O MOC, Visão Geral, seções 4.2.4 e 4.2.5 orienta incluir na assinatura o certificado do usuário final e verificar se ele é apropriado para assinatura digital. Um certificado de autoridade certificadora não deve ocupar esse lugar. A conferência das extensões é uma atividade técnica; o usuário não deve editá-las para tentar adequar o arquivo.

É útil separar os diagnósticos:

• 280 trata do certificado apresentado na conexão de transmissão

• 290 trata do certificado da assinatura da mensagem

• 291 trata de seu período de validade

• 292 trata da identificação CNPJ/CPF no certificado

• 297 trata de divergência no valor calculado da assinatura

Se o sistema reúne essas falhas sob um único aviso, solicite o código e a descrição completos devolvidos pelo serviço antes de escolher a correção.

Como verificar o certificado realmente utilizado

1. Registre se a tentativa era de emissão, inutilização ou evento, além de modelo, UF, ambiente, horário e autorizador.

2. Preserve a mensagem enviada e a resposta nos registros internos do sistema. Peça ao suporte uma análise segura do certificado incorporado à assinatura, sem publicar o XML fiscal em validadores desconhecidos.

3. Compare o número de série, o emissor e o titular desse certificado com a seleção prevista para a operação. O nome exibido na tela, sozinho, pode não distinguir arquivos diferentes.

4. Solicite a conferência da versão X.509, do perfil de usuário final e dos usos de chave previstos para assinatura. Se a configuração parece correta, o fornecedor deve verificar também como o componente assinador montou a mensagem.

5. Corrija a causa na configuração ou no gerador de assinatura. Se a certificadora confirmar que o certificado é inadequado, obtenha um certificado compatível pelo processo apropriado.

6. Para a mensagem rejeitada, use o fluxo do emissor para gerar uma assinatura válida e confira o resultado da nova tentativa. Não altere manualmente o XML assinado nem substitua somente o conteúdo do certificado dentro dele.

A InvoiSys recomenda conferir o certificado associado ao cadastro. Essa é uma verificação inicial: o que efetivamente saiu na assinatura precisa corresponder à configuração esperada.

O que fazer em cada cenário

O certificado correto está cadastrado, mas outro aparece no XML: peça a correção da seleção feita pelo componente assinador. Verifique serviços e integrações que podem manter configurações separadas. Alterar apenas a seleção da conexão TLS pode deixar a assinatura com o mesmo problema.

O XML não contém o certificado esperado: o fornecedor precisa avaliar a geração da assinatura e o arquivo realmente transmitido. Não basta copiar um certificado para dentro do XML; a assinatura deve ser produzida de forma consistente com a mensagem e com a chave correspondente.

A falha começou após atualização ou migração: confronte uma tentativa anterior válida com a rejeitada, por meio de análise técnica local e dos registros disponíveis. A comparação deve identificar mudanças no assinador e na seleção do certificado, sem presumir que o conteúdo fiscal esteja errado.

O certificado tem perfil inadequado: encaminhe a identificação e o diagnóstico à certificadora. Reinstalar o mesmo arquivo não muda sua versão, sua finalidade ou suas extensões. A TecnoSpeed indica verificar instalação e substituição; a escolha entre essas ações depende da causa confirmada.

A única irregularidade encontrada é vencimento: confira se o retorno recebido é realmente 290 ou 291. A Treeunfe oferece uma triagem de seleção e compatibilidade, mas a decisão técnica deve preservar a distinção entre as regras específicas do MOC.

Exemplo hipotético

Após uma atualização, uma empresa envia um evento cujo componente de assinatura passou a incorporar um certificado intermediário da certificadora, em vez do certificado do usuário final. A análise do retorno 290 aponta o perfil incompatível. O fornecedor corrige a seleção e gera novamente a assinatura do evento. A equipe então verifica a aceitação do pedido; não cancela nem recria a nota original por causa da falha desse envio.

O serviço e o autor fazem diferença

O Grupo E está previsto na autorização de NF-e, modelo 55, e NFC-e, modelo 65, em inutilização e na recepção de eventos. Cada evento precisa ser admitido para o modelo e assinado conforme a identidade exigida para seu autor. Na manifestação do destinatário, por exemplo, a assinatura é do destinatário, e não uma escolha automática pelo emitente da nota. NT 2020.001 v1.60.

Há ainda modalidades com regras específicas, como NFF e emissão por PAA. Elas não autorizam utilizar qualquer certificado de terceiro. Se o caso envolve uma dessas modalidades, o suporte deve conferir o fluxo e a norma aplicáveis antes de orientar a troca do certificado. A presença do código numa especificação também não comprova a disponibilidade de todos os eventos em qualquer UF ou ambiente.

Como confirmar a solução

Na nova tentativa, confira o certificado incorporado à assinatura e o resultado final do serviço. Emissão exige autorização e protocolo; evento exige a resposta correspondente. Passar pela E01 não garante aprovação nas demais verificações.

Se houver tentativa anterior sem resposta conclusiva, consulte a situação antes de retransmitir. Preserve os documentos e protocolos existentes. Uma nota já autorizada não deve ser editada ou assinada novamente para corrigir um evento posterior rejeitado.

No atendimento, não compartilhe senha, PIN, chave privada ou arquivo que a contenha. Não remova certificados indiscriminadamente e não desative validações de assinatura, cadeia ou revogação. Dúvidas sobre a configuração devem ser resolvidas com o fornecedor; dúvidas sobre o perfil do certificado, com a certificadora.

Revisão documental: 09/10/2026. Aplicação conforme o serviço, o ambiente e as ressalvas indicadas.

Referências complementares

• Pedido de prorrogação, NT 2015.001 v1.30, validação do certificado de assinatura: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT+2015.001+-+v+1.30.pdf

• EPEC NFC-e, NT 2014.003 v1.02, serviço de disponibilidade condicional: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=HYPw%2BDBncKo%3D

• NFF, NT 2021.002 v1.12: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT2021.002+v1.12+Nota+Fiscal+F%C3%A1cil.pdf

• PAA, NT 2026.001 v1.02b: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT_2026.001_v1.02b+-+PAA+NFe.pdf