Rejeição 281 — Certificado Transmissor Data Validade
Motivo da rejeição
Certificado Transmissor Data Validade
O que é esta rejeição?#
A Rejeição 281 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a assinatura digital do documento. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.
Este código indica que rejeição: Certificado Transmissor Data Validade.
Os campos afetados estão na seção de certificado digital do XML.
Campos XML relacionados#
Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:
| Campo | XPath no XML | Descrição |
|---|---|---|
| X509Certificate | Signature/KeyInfo/X509Data/X509Certificate | Certificado digital X.509 |
Causas comuns#
- O certificado digital utilizado para assinar a NF-e pode estar expirado
- O certificado pode ter sido revogado pela autoridade certificadora
- O certificado não pertence ao CNPJ do emitente da NF-e
- O certificado não é do tipo e-CNPJ ou e-CPF válido na cadeia ICP-Brasil
- A assinatura digital do XML está corrompida ou foi gerada incorretamente
Como resolver#
- Verifique a data de validade do certificado digital — renove se estiver expirado
- Confirme que o certificado pertence ao mesmo CNPJ informado no campo <emit><CNPJ>
- Certifique-se de que o certificado é do tipo A1 ou A3 válido na cadeia ICP-Brasil
- Gere novamente a assinatura digital do XML usando o certificado correto
- Se o certificado foi revogado, solicite um novo à autoridade certificadora
Verificações analíticas#
- Se o campo <emit><CNPJ> diverge do CNPJ titular do certificado digital utilizado na assinatura do elemento <Signature> do XML, então o certificado não pertence ao emitente declarado na NF-e, causando rejeição 281: substitua o certificado pelo e-CNPJ vinculado exatamente ao CNPJ informado em <emit><CNPJ>.
- Se a data de emissão <dhEmi> é posterior à data de validade do certificado digital (campo NotAfter do X.509 extraído do <X509Certificate> embutido na <Signature>), então o documento foi assinado com certificado já expirado no momento da transmissão: renove o certificado junto à autoridade certificadora ICP-Brasil antes de gerar e assinar nova NF-e.
- Se o valor calculado do digest SHA-1 ou SHA-256 do elemento <infNFe> não coincide com o conteúdo de <DigestValue> presente na <Reference> da assinatura XML, então a assinatura digital está corrompida ou o XML foi alterado após a assinatura: regenere o arquivo XML, assine-o novamente com o certificado válido sem qualquer manipulação posterior dos bytes do documento.
- Se o atributo Id do elemento <infNFe> não corresponde exatamente à URI referenciada no atributo URI da <Reference> dentro da <SignedInfo> (por exemplo, <Reference URI="#NFe..."> aponta para Id diferente do declarado), então a cadeia de assinatura está quebrada estruturalmente e a SEFAZ rejeita o certificado como inválido para aquele documento: corrija a montagem do XML garantindo que o Id de <infNFe> e a URI da <Reference> sejam idênticos antes de assinar.
- Se o campo <tpEmis> indica emissão em contingência (valores 2, 3, 4, 5, 6 ou 7) e a <dhEmi> da NF-e de contingência está fora da janela de 168 horas permitida para transmissão posterior, então o certificado pode ser válido mas o evento de transmissão é rejeitado junto com o código 281 por inconsistência temporal da cadeia de autenticação: verifique se o certificado vigente na data de <dhEmi> original ainda está na cadeia ICP-Brasil e, se necessário, cancele a contingência e emita nova NF-e com certificado atualizado.
Consulte IEs e CNPJs antes de emitir NF-e
Muitas rejeições acontecem por dados cadastrais desatualizados. Com a FiscalAPI, consulte Inscrições Estaduais e CNPJs em tempo real direto da SEFAZ e Receita Federal.
Criar conta →