NF-e e NFC-e
Rejeição 295: como conferir a origem ICP-Brasil do certificado da assinatura
A rejeição 295 aponta que a raiz da cadeia do certificado usado na assinatura difere da ICP-Brasil. Confira o certificado realmente incluído no XML rejeitado e peça à certificadora a verificação de sua origem. Se o assinador selecionou um certificado de teste ou incompatível, corrija essa seleção e gere a assinatura…
A rejeição 295 aponta que a raiz da cadeia do certificado usado na assinatura difere da ICP-Brasil. Confira o certificado realmente incluído no XML rejeitado e peça à certificadora a verificação de sua origem. Se o assinador selecionou um certificado de teste ou incompatível, corrija essa seleção e gere a assinatura pelo emissor com um certificado adequado à operação.
Mensagem: “Rejeição: Certificado Assinatura difere ICP-Brasil”.
O que está sendo verificado
A regra E07 do MOC verifica se a raiz do certificado difere da ICP-Brasil. Ela pertence ao grupo de validação do certificado digital da assinatura. Não é uma exigência para modificar o texto da nota, seu enquadramento tributário ou o conteúdo dos produtos. MOC 7.0, Anexo I, seção 4.1.4.
A ICP-Brasil organiza uma cadeia de confiança supervisionada pelo ITI. Ter um certificado instalado e reconhecido pelo computador não basta para demonstrar que sua cadeia atende ao padrão fiscal. Um certificado interno, autoassinado ou emitido fora dessa infraestrutura não passa a ser ICP-Brasil por ser adicionado ao repositório local. ITI: estrutura da ICP-Brasil.
O MOC separa a assinatura da mensagem e a identificação da conexão TLS. A rejeição 295 trata do certificado da assinatura; a 285 trata do certificado transmissor. Portanto, conseguir estabelecer conexão com a SEFAZ não confirma a conformidade do certificado que assinou o XML. MOC, Visão Geral, seção 4.2.3.
Como investigar
Registre o retorno completo, o horário, o serviço, o modelo, o ambiente e o autorizador. Verifique se a ocorrência começou após troca de certificado, instalação de integração ou migração de servidor.
Peça ao suporte que identifique o certificado presente na assinatura da mensagem rejeitada. Compare número de série, emissor e titular com o certificado que deveria ser utilizado. O nome do arquivo cadastrado, sozinho, não comprova qual certificado assinou.
Solicite a conferência da cadeia até a raiz e da vinculação à ICP-Brasil. A Alterdata descreve essa vinculação como parte do diagnóstico. A raiz deve ser identificada tecnicamente, sem confiar apenas em um nome exibido pelo sistema.
Se o certificado for incompatível, use outro que cumpra os requisitos do serviço e da autoria. A Mainô recomenda envolver a certificadora para obter um certificado compatível quando necessário.
Se o certificado adequado já existe, ajuste a seleção do componente que assina. Não compre um substituto antes de verificar se o problema era o uso de outro certificado. A InvoiSys também orienta conferir o certificado com a certificadora e atualizar sua associação no emissor.
Persistindo a rejeição com a origem confirmada, encaminhe ao suporte e ao autorizador a identificação do certificado, da cadeia, os horários e o retorno. Uma avaliação local favorável não demonstra, sozinha, como o autorizador processou a mensagem.
Para conferir fontes oficiais da cadeia, a equipe técnica pode consultar o Repositório AC-Raiz do ITI. A página reúne versões e situações distintas; não é uma orientação para instalar indiscriminadamente todos os certificados disponíveis.
O que fazer em cada cenário
Foi usado um certificado criado para desenvolvimento: configure o assinador para o certificado fiscal adequado. Homologação é ambiente de testes fiscais e não deve ser tratada como dispensa geral dos requisitos de certificado e assinatura.
A empresa já possui certificado ICP-Brasil: confira se ele é o que aparece na assinatura rejeitada. Em integrações com processos separados, a transmissão pode usar o certificado correto enquanto a assinatura usa outro.
O certificado foi renovado recentemente: peça a identificação da nova cadeia à certificadora e verifique a seleção no assinador. Não altere algoritmos, reduza verificações ou troque certificados da cadeia por tentativa.
O certificado está vencido ou revogado: essas condições têm regras próprias, 291 e 294. Elas não transformam automaticamente a origem da cadeia em uma infraestrutura diferente. Consulte o código original para não tratar toda falha de certificado como 295.
A cadeia apresenta outro erro: a 293 contempla problemas como cadastro da AC na SEFAZ e revogação de uma autoridade da cadeia. Se o retorno for 293, siga esse diagnóstico. Os códigos próximos não são intercambiáveis.
E se a emissão usa e-CPF, NFF ou PAA?
O e-CPF é admitido nos fluxos previstos para emitente pessoa física. Para NFC-e de produtor rural com CPF e inscrição estadual, a NT 2023.002 estabelece condições específicas, inclusive assinatura pelo e-CPF do emitente quando usa software próprio. Isso não dispensa a origem ICP-Brasil nem a habilitação aplicável à UF. NT 2023.002 v1.01, seção 2.1.
Na Nota Fiscal Fácil, o certificado de assinatura é o da SVRS, conforme a regra do regime. No PAA, há uma assinatura avançada específica no fluxo, mas a NT exige também assinatura fiscal qualificada com certificado ICP-Brasil do provedor. Uma não substitui a outra. A especificação do PAA examinada é para NF-e, modelo 55, com autorização centralizada na SVRS; não autoriza estender esse procedimento à NFC-e. NT NFF 2021.002 v1.12, regra F03 e NT PAA 2026.001 v1.02b, seção 1.1 e regra B07-10.
Exemplo hipotético
Uma empresa investiga uma tentativa que recebeu 295 durante o teste de uma nova integração. O certificado de conexão está correto, mas o suporte identifica que o serviço de assinatura ainda seleciona um certificado de desenvolvimento cuja raiz não pertence à ICP-Brasil. O exemplo parte do retorno recebido; não define qual rejeição apareceria primeiro se houvesse várias falhas no mesmo certificado.
O suporte identifica o certificado no XML rejeitado e ajusta o assinador para o certificado ICP-Brasil previsto para a operação. A mensagem rejeitada é novamente preparada e assinada pelo emissor. O arquivo já assinado não é editado manualmente e os dados fiscais permanecem fiéis à operação.
Onde se aplica e como confirmar a solução
A validação é prevista nos serviços de autorização de NF-e e NFC-e, inutilização e recepção de eventos. Há registros expressos também nas especificações do pedido de prorrogação da NF-e e do EPEC da NFC-e. Cada evento tem escopo, autoria e disponibilidade próprios; a existência da regra não comprova oferta do serviço em todas as UFs e ambientes. MOC, Visão Geral, tabelas 5-3, 5-11 e 5-34.
Confirme o certificado usado na nova assinatura e o resultado definitivo da operação. Para a nota, confira autorização e protocolo; para inutilização ou evento, o retorno correspondente. Se uma tentativa anterior ficou sem resposta, consulte sua situação antes de repetir o envio. Não altere número, série, valores ou tributos para tentar superar a 295.
Nunca envie senha, PIN, chave privada ou arquivo com chave privada por mensagens. Não desative a validação da cadeia e não substitua manualmente o certificado dentro do XML assinado.
Revisão documental: 09/10/2026. Disponibilidade e habilitação precisam ser confirmadas no serviço, UF e ambiente do caso concreto.
Referências complementares
Pedido de prorrogação, NT 2015.001 v1.30, seções 6.7 e 7.7: 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, seção 03.8; adoção a critério da UF: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=HYPw%2BDBncKo%3D