Rejeição 291: validade 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 291, regra E02, verifica início e fim da validade do certificado presente na assinatura XML. O certificado selecionado para a conexão TLS pode estar válido enquanto o documento preparado contém outro certificado, com validade inadequada.
Nesta página:
- Qual certificado e quais datas devem ser examinados?
- Exemplo: troca no transmissor sem regeneração do documento
- Por que não alterar relógio ou data fiscal?
- Qual a diferença entre 291, 281 e 294?
Qual certificado e quais datas devem ser examinados?
Identifique X509Certificate na assinatura da mensagem rejeitada e confira notBefore e notAfter, com as referências de tempo usadas na verificação. O MOC prevê a conferência do prazo de validade na validação da assinatura. A data de emissão fiscal da nota não substitui as datas do certificado.
Mantenha separados momento de geração, momento de envio e momento da conferência. Não conclua que uma assinatura preparada antes do vencimento será aceita depois dele apenas com base na data da nota. O retorno e o contexto da validação precisam ser preservados.
Fontes: MOC Anexo I, regra E02.
Exemplo: troca no transmissor sem regeneração do documento
Imagine que a aplicação renove o certificado do cliente TLS, mas mantenha em fila um XML cuja assinatura incorpora o certificado anterior. A conexão funciona e E02 ainda pode apontar problema de validade no documento. A renovação de uma configuração não reescreve assinaturas existentes.
Compare o certificado incorporado ao XML com aquele selecionado na conexão. Se for necessário corrigir um documento ainda sem autorização, faça isso pelo fluxo legítimo de geração e assinatura, após esclarecer seu estado. Não substitua somente o conteúdo de X509Certificate.
Fontes: MOC Anexo I, regra E02.
Por que não alterar relógio ou data fiscal?
Essas mudanças não corrigem a validade do certificado emitido pela AC e podem prejudicar outras validações. Se houver suspeita de relógio incorreto no ambiente, confronte sua sincronização com uma referência confiável e registre o erro; não ajuste o tempo para acomodar um certificado vencido.
O ITI orienta que o certificado tem período de validade e que a renovação deve ser tratada com a AC. Confirme a emissão legítima, a seleção pelo assinador e o carregamento efetivo da configuração.
Fontes: MOC Anexo I, regra E02.
Qual a diferença entre 291, 281 e 294?
A 291 trata de datas do certificado da assinatura; a 281, do certificado TLS; a 294, da revogação do certificado de assinatura. Datas aparentemente válidas não excluem revogação ou falha de cadeia.
Depois de corrigir a causa comprovada, valide estrutura e assinatura final. Não modifique XML já autorizado para atualizar certificado. Para tentativas sem resultado conclusivo, consulte a situação antes de nova ação; a correção local da assinatura não comprova autorização.
Fontes: MOC Anexo I, regra E02.
Limite do exemplo e preservação dos dados
A conferência exige o certificado e a assinatura presentes no XML original protegido, junto ao tempo da validação. O exemplo textual evita fabricar certificado ou assinatura operacional. 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 E02, código 291; 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.
- Certificação Digital - Perguntas frequentes, versão consulta 16/10/2026. perguntas 5, revogação e legitimados, e 21, período de validade e renovação.