Rejeição 293: cadeia do certificado da assinatura XML
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 293, regra E04, aponta falha na cadeia de certificação do certificado usado na assinatura XML. A investigação deve partir do certificado incorporado ao documento rejeitado. Reinstalar um certificado no computador ou renovar a conexão TLS pode não alterar essa assinatura.
Nesta página:
- Quais causas estão previstas em E04?
- Como separar problema local e problema no autorizador?
- Exemplo: configuração nova e XML antigo na fila
- O que distingue 293, 283, 294 e 295?
Quais causas estão previstas em E04?
O MOC enumera certificado da AC emissora não cadastrado na SEFAZ, certificado de AC revogado e certificado não assinado pela AC indicada como emissora. Essas condições envolvem objetos e responsabilidades distintos; a mensagem resumida não revela qual deles falhou.
Identifique o certificado final presente em X509Certificate e monte sua cadeia pública, conferindo assinaturas, validade e revogação. A Visão Geral exige incluir na assinatura somente o certificado de usuário final; não se deve tentar resolver a cadeia colando todas as intermediárias no XML.
Fontes: MOC Anexo I, regra E04.
Como separar problema local e problema no autorizador?
Use material público oficial do ITI e da AC para conferir a cadeia correspondente. Uma cadeia completa e válida no cliente não comprova o cadastro da AC no repositório da SEFAZ. Se a validação local está correta e a falha permanece em um ambiente específico, reúna o retorno, o horário, o serviço e as versões para esclarecimento técnico com a AC e o autorizador.
Não desative confiança ou revogação, nem troque a empresa do documento. A correção deve corresponder à causa comprovada e preservar o certificado e a chave privada em canal protegido.
Fontes: MOC Anexo I, regra E04.
Exemplo: configuração nova e XML antigo na fila
Suponha que o cadastro tenha um certificado novo, mas o documento aguardando transmissão tenha sido assinado antes da atualização. A conferência do cadastro atual não examina o certificado que E04 encontrou.
Compare a identidade técnica do certificado incorporado com a geração da mensagem. Verifique sua cadeia original e a situação do documento antes de regenerar qualquer assinatura. Um XML autorizado deve permanecer íntegro; sua assinatura faz parte do histórico e não deve ser substituída para refletir a configuração atual.
Fontes: MOC Anexo I, regra E04.
O que distingue 293, 283, 294 e 295?
A 293 verifica a cadeia da assinatura; a 283, a cadeia do transmissor TLS. A 294 trata do certificado de assinatura revogado e a 295 de raiz fora da ICP-Brasil. Um certificado final dentro da validade ainda pode falhar em cadeia ou revogação.
Depois de reparar a origem, valide XSD e assinatura do arquivo final. Em processos especiais, como PAA, identifique qual certificado qualificado está sendo validado; não presuma dispensa de cadeia. Esclareça tentativas com resultado desconhecido antes de novo envio.
Fontes: MOC Anexo I, regra E04.
Limite do exemplo e preservação dos dados
A prova exige o certificado incorporado e sua cadeia original. Não se publicam certificado, chave ou assinatura operacional; o exemplo textual distingue configuração atual e arquivo assinado. 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 E04, código 293; 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.
- Cadeias da ICP-Brasil, versão consulta 16/10/2026. página completa, cabeçalho e relação oficial de cadeias por autoridade certificadora.
- 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.