Rejeição 290: certificado da assinatura XML inválido
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 290, regra E01, examina o certificado incorporado à assinatura XML. Ela pode ocorrer mesmo quando a conexão TLS foi estabelecida corretamente, porque o certificado usado para transmitir e o certificado usado para assinar cumprem funções distintas.
Nesta página:
- O que a regra E01 verifica?
- Como tratar Basic Constraints sem reproduzir uma instrução contraditória?
- Exemplo: certificado renovado, XML preparado antes da troca
- E01 pode ser dispensada por usar um intermediário?
O que a regra E01 verifica?
O quadro reúne certificado da assinatura inexistente na mensagem, versão X.509 diferente de 3 e finalidades de uso incompatíveis com assinatura digital e não recusa. A ausência do certificado também é verificada estruturalmente pelo schema. Confira o conteúdo de X509Certificate dentro de KeyInfo/X509Data da Signature.
A Visão Geral prevê incluir na assinatura o certificado do usuário final, não toda a cadeia. Ter um certificado correto no cadastro não comprova que ele foi incorporado ao documento rejeitado. Relacione o arquivo assinado com a configuração que o produziu.
Fontes: MOC Anexo I, regra E01.
Como tratar Basic Constraints sem reproduzir uma instrução contraditória?
E01 escreve “true” e, na mesma condição, diz que não pode ser certificado de AC. A Visão Geral exige usuário final; o DOC-ICP-04 consolidado apresenta cA=False nos perfis de usuário final. Essa divergência documental não autoriza ajustar extensões ou usar certificado de autoridade para assinar a nota.
A análise deve confirmar o perfil emitido e a finalidade legítima com a AC e o integrador. Certificado assinado não deve ser editado para alterar uma extensão. Registre a divergência quando ela for relevante ao diagnóstico.
Fontes: MOC Anexo I, regra E01; DOC-ICP-04 - Requisitos mínimos para políticas de certificado.
Exemplo: certificado renovado, XML preparado antes da troca
Suponha que a configuração atual mostre um certificado adequado, mas a mensagem rejeitada tenha sido gerada anteriormente com outro certificado ou sem sua inclusão. Validar somente a configuração de hoje deixa de examinar o objeto de E01.
Extraia a identificação técnica do certificado incorporado à assinatura em ambiente protegido e confronte-a com o processo de geração. Se houver falha comprovada de montagem, corrija o gerador e regenere pelo fluxo legítimo. Não cole certificado ou SignatureValue manualmente no arquivo.
Fontes: MOC Anexo I, regra E01.
E01 pode ser dispensada por usar um intermediário?
Não presuma isso. A NT 2026.001 descreve o PAA com uma assinatura avançada própria e uma assinatura qualificada ICP-Brasil do provedor; ela não elimina automaticamente as validações do certificado qualificado. O processo real de emissão deve ser identificado, sem trocar de modalidade para contornar E01.
A 280 verifica o certificado TLS, enquanto 291, 293 e 294 tratam de validade, cadeia e revogação da assinatura. Após reparar a causa, valide XSD e assinatura e esclareça qualquer tentativa incerta antes de novo envio.
Fontes: MOC Anexo I, regra E01; NT 2026.001 - Provedor de Assinatura e Autorização.
Limite do exemplo e preservação dos dados
A verificação exige o certificado incorporado e a assinatura originais em ambiente protegido. Não se fabrica X509Certificate, chave ou assinatura para ilustrar; o exemplo é uma comparação textual. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.
Fontes oficiais
- MOC 7.0 — Anexo I, versão 7.00. p. 73, regra E01, código 290; p. 74, regras próximas de assinatura.
- MOC 7.0 — Visão Geral, versão 7.00. pp. 52–56, §§4.2.3–4.2.6: certificado e assinatura, EndCertOnly, perfil XMLDSig, validação e LCR.
- DOC-ICP-04 - Requisitos mínimos para políticas de certificado, versão 8.3, consolidação com Resolução 215/2025. DOC-ICP-04 v. 8.3 consolidado, Anexo I, perfis de usuário final: Basic Constraints cA=False, Extended Key Usage e CRL Distribution Points; referência interna p. 47 e tabelas seguintes.
- NT 2026.001 - Provedor de Assinatura e Autorização, versão 1.02b. pp. 3–5, versão/cronograma e duas assinaturas; pp. 10–11, infPAA e F03; p. 14, ZG04-10 separado da Signature qualificada.